javanonymous

There are several open source tools for Java (Eclipse, Visual Studio plugins, Netbeans and others).

The reason I don't use them is not because they are bad, but because IntelliJ is so much better.

I even use IntelliJ Ultimate for non Java code like React, even though Visual Studio Code seems to be de-facto standard for React developers and guides.

> why would we ever want in Java to hold a variable that you can't read immediately what is the type

I can use my IDE to see the type if necessary.

> Everything that came after isn't really memorable nor helpful,

There are several improvements that are very helpful

One example is how multi line strings help me to read more clearly without the unnecessary string concatenations:

   var sql = """
             SELECT foo
             FROM bar
             WHERE last_updated > :lastUpdated
             """;

Another example is how switch statements have improved code readability, at least from my personal subjective viewpoint.

   String dayName = switch (day) {
      case 1 -> "Monday";
      case 2 -> "Tuesday";
      case 3, 4, 5 -> "Other day";
      default -> "Weekend";
   };

I think it has a lot to do with work culture. Many tend to mimic what others are doing in order to not stick out.

At my previous job some were able to change that by consistently using "modern" features of Java. It inspired others to change and eventually we ended up with a good code base.

Be the one to start the change by implementing new features using good code. This will give others "permission" to do the same. Also try to give soft suggestions in code reviews or pair programming of simpler ways to do it (don't push too hard)

At my current job all of us were eager to try the latest features from the start, so we never had to convince new hires.

The JVM tends to use as much memory as it can for performance reasons. It is not a reliable indicator of how much memory it actually needs. Why spend resources on clearing memory if there's still unused memory left?

If memory is an issue, you can set a limit and the JVM will probably still work fine

> It sounds good but in reality people end up spending time messing around with config files and annotations.

I use Spring Boot at my day job and write mostly web services. I don't spend time messing around with config files and annotations. When I create a service class, I annotate it with @Service, and that is mostly what I need.

Example:

   @Service
   public record ItemsService(ItemsRepository repo) {

      public void doStuff(String country) {
         var items = repo.findByCountry(country);
         // do stuff with items
         
      }
   }

Later versions of Spring Boot has reduced a lot of the annotations necessary, like @Inject if you use constructors etc. There are of course other annotations and configurations, but 90% of what I do is similar to the example I gave above. Things may have changed since last you used it, but the amount of "magic" and annotations is often much less than what is posted in these types of discussions.

> which is something that I would have said would never happen if you had asked me five years ago.

I think a lot of people are noticing the changes Java has had in the previous years. The language has made a lot of improvements, and I feel that the mind set of the community has changed. The old enterprise way of factories and unnecessary abstractions have lost a lot of popularity, and is mostly still alive in legacy software/teams and universities who have not yet caught up.

Even Spring Boot is now a valid approach for getting sh*t done for startups. There are of course frameworks that are more light weight, or you can start from scratch and choose your own libraries to keep the size down. But SB is simply good enough for most use cases, and even supports native compilation now.

I think named parameters would be a great addition

For now, I use Lombok's @Builder annotation. It makes it much easier to create and copy a record, where non-assigned attributes are set to default.

Example:

   var bmw = Car.builder().make("BMW").build()

It also has a practical toBuilder() syntax that creates a copy of the original record, with some attributes changed

   var other = bmw.toBuilder().year(2024).build()

That's why moduliths are becoming more popular. These are basically monoliths that enforce structure. The other advantage is that each "module" can be extracted as a micro-service later without much work.

The Java library actually supports this case.

It may not have the convenient "years" method directly, but you can add an arbitrary unit of time quite easily

Example with duration:

    Duration.of(1, ChronoUnit.YEARS)

Example with datetime:

    today.plus(2, ChronoUnit.YEARS)

It even supports decades, centuries, eras and half days :-)

For those curious about how it handles leap years:

    var leapDay = LocalDate.of(2024, 2, 29)
    leapDay.plus(1, ChronoUnit.YEARS);
   
    // ==> 2025-02-28

    var lastYear = LocalDate.of(2023, 3, 1);
    lastYear.plus(1, ChronoUnit.YEARS);

    // ==> 2024-03-01

    var lastFeb = LocalDate.of(2023, 2, 28);
    lastFeb.plus(1, ChronoUnit.YEARS);

    // ==> 2024-02-28

    var firstFeb = LocalDate.of(2024, 2, 1);
    leapDay.with(TemporalAdjusters.lastDayOfMonth());

    // ==> 2024-02-29