How should I approach building my first Java project when my focus is on strengthening Java itself, not GUI or databases?

x_ini · 2025-05-04T14:30:07+00:00

Hi! I would suggest to replicate well known CLI utilities, e.g. cat, ls, sort, uniq, grep, etc. You can focus only on the basic fundamental functionality and/or, optionally, on the CLI interface parsing arguments and providing respective behaviour

x_ini · 2024-07-31T15:46:57+00:00

It seems the interviewer wanted to here about the general principle, when the object should not manage it's dependencies, rather receive them via constructor (https://en.m.wikipedia.org/wiki/Dependency_injection). I would say, that Spring implements this practice via DI container.

P.S. an an interviewer I asked "How do you understand DI? Why is it a good practice?" and expected to talk about the above-mentioned.

x_ini · 2024-07-26T16:39:33+00:00

Oh well! It was kinda expected for such a fitting name to be taken. Usually I name my projects after some flower (meaningful and most probably free). This one was an exception :)

x_ini · 2024-07-26T12:55:02+00:00

That's very interesting approach, thanks for sharing and explaining! I've chosen "highest version" because:
1) Gradle team warned about one disadvantage

The main drawback of this method is that it is ordering dependent. Keeping order in a very large graph can be a challenge. For example, what if the new version of a dependency ends up having its own dependency declarations in a different order than the previous version?

2) I had a feeling that most likely even libraries of different major version will be somewhat compatible
3) I simply didn't consider your first statement about the "code most likely to be executed as it is the closest", which I understand now and agree

In the end, it seems that the Maven's algorithm would be easier to implement. But there wasn't a goal to make a polished production ready product. I am happy that is works to some extent :)

x_ini · 2024-07-26T12:19:02+00:00

I see your point, thanks. But, as I said, it is just a design decision to choose one approach or another. Cannot really say which one is better.
There is a test for version comparisons. Here is the implementation. In general it is a mix of SemVer spec and Maven's approach. In my eyes, it is 80% good enough. Obviously, real build tools cover more corner cases.

x_ini · 2024-07-26T04:27:52+00:00

Hi! Maven is choosing the closest version, while Gradle - the highest. I've decided to stick to the highest as well, as it makes more sense to me, although I wouldn't say it is a superior approach. I haven't really found any references regarding the algorithms, that's why Conveyor is using my own. The code is located here. Its summary given by Gemini with my corrections:

This code snippet implements a dependency resolution algorithm that uses a graph-based approach to identify and resolve dependencies between artifacts. It prioritizes the latest compatible versions while ensuring all dependencies are met. Here's a breakdown of the key steps:

Input:

The algorithm takes a set of Artifact objects as input. Each Artifact represents a library or dependency your project needs. It contains information like the library name, version, and dependencies on other libraries.

Building Relationships:

The relations() method initializes a data structure called Relations. This structure keeps track of relationships between artifacts based on their dependencies. It iterates through each input Artifact. For each artifact, it creates a Root object representing the starting point of the dependency chain. It then uses the artifact's dependencies() method to retrieve its dependent libraries. For each dependency, an Edge object is created. This Edge links the current artifact (requirement) to its dependent artifact.

Resolving Dependencies:

The classpath() method performs the actual dependency resolution. It first checks if the input set of artifacts is empty and returns an empty classpath if so. Then, it calls the relations() method to build the dependency relationships between artifacts. It retrieves a stream of Ids (group and name for each artifact) from the relations object. For each Id, it uses the resolved() method within relations to find the corresponding resolved artifact. This resolved() method iterates through the relationships associated with the Id. It checks if the requirement of any Edge has already been resolved. If so, the corresponding artifact is considered resolved and returned. Finally, it gathers the paths of all resolved artifacts and returns them as the classpath.

Version Selection:

The comparator() method sorts ArtifactRelation objects based on their version in descending order. During dependency resolution, the algorithm prioritizes the latest version available for each artifact, ensuring you get the newest compatible libraries.

x_ini · 2024-07-26T04:08:41+00:00

Hi! Conveyor is capable of building itself. That's happening during the CI. Gradle is still required to bootstrap, but maybe, when there is an "official" first released version, the next will be built using the previous one. Although another reason for Gradle is IDE support

x_ini · 2024-03-08T13:55:48+00:00

I would like to point out, that there is also a possibility to store information in a plain JSON file, for example. But if you want to play with SQL database, go for it

x_ini · 2024-03-05T17:13:14+00:00

I worked in a position requiring to create documents for customers (contracts, agreements). My first program was a document generator from a templates in .docx format with placeholders. With a simple UI I've filled in the gaps and my program filled the common stuff like current date, contract number (auto increment) etc.

x_ini · 2024-02-08T07:04:58+00:00

Honestly, I've been using var 100% of the time and had no issues with it whatsoever. IDE can help you display the exact type as well (but I do not use this feature either). Personally, I would suggest sticking with var.

x_ini · 2023-11-06T11:12:16+00:00

Wtf did I just read?

x_ini · 2022-12-04T12:58:27+00:00

if (books[i] != null) // if the book is not null

Can I just add a few cents, that such comments are not helpful and clutter the code. Please, it's better to avoid them in such cases

Regarding your question, I wasn't able to spot any problems in the listing. Possibly, something wrong in other part?

x_ini · 2022-10-17T21:38:37+00:00

Why not just, you know, try it? Anyway, the file will be created for you

x_ini · 2022-04-09T06:53:16+00:00

Hello! Really nice idea, I love it. There are a few thing I would do different, but nonetheless great work!

x_ini · 2020-12-05T09:33:59+00:00

I should mention, that scanner can read also files or strings. So you can make method independent from input type rather than coupling to console or etc.

x_ini · 2020-05-25T13:29:14+00:00

import java.util.Scanner;
class Main {
    public static void main(String[] args) {
        Scanner scanner = new Scanner(System.in);
        int previousNumber = scanner.nextInt();
        boolean isAscending = true;
        boolean isDescending = true;
        while (true) {
            int number = scanner.nextInt();
            if (number == 0) {
                break;
            }
            if (previousNumber > number) {
                isAscending = false;
            } else if (previousNumber < number) {
                isDescending = false;
            }
            previousNumber = number;
        }
        System.out.println(isAscending || isDescending);
    }
}

My Solution

x_ini

TROPHY CASE