51–60 of 64 posts
Java 27 already? I just learned about Java 26. But I’m not complaining, the JEPs that is getting introduced on every release are quite exciting features. I highly recommend following the Java official YouTube channel, they publish entertaining, yet informative videos/shorts about tips/tricks/features.
would you mind linking to the channel? not sure which one you mean
Earlier quoted context omitted.
> The current numbering scheme is annoying and distracting, bears no information yet is still error prone. > This release should've been called 26.1, then 27.0, 27.1, 28.0 and so on. And how does that bear any information any differently?
When I encounter a version number I mostly want to know either: - what are the major characteristics of the program - how old is the program Traditional software versioning helps in the first case: they bump version after a big event (new feature, rewrite, etc). Date based versioning helps in the second case. (I prefer date based versioning over traditional or semver.) Their numbering system doesn't help anyone in an…
How does 26.1 tell you that? Because you "assume" it is a date? It also still doesn't? How do you know the new 1 isn't 26.100?
> Traditional software versioning helps in the first case: they bump version after a big event
They pretend to. It's given most developers headaches in terms of you have to have something to bump the version so either they make something up or never do it and so fails your test either way.
At the end of the day either:
You care: a quick check won't hurt. It's twice a year.
You don't care: what difference does it make?
Earlier quoted context omitted.
I believe that's by design: applications are encouraged to upgrade often. That's usually a smooth process for standard-conforming applications. Applications that need to move slower can stick to LTS versions. LTS hopping has become a little bit more viable since the interval has been shortened to two years, i.e., four major versions.
> I believe that's by design: applications are encouraged to upgrade often. I'm not sure what's your thought process here. I'm not saying they should have a release every 2 years instead of every half a year, but that their numbering scheme is bad . It makes upgrading harder. If they'd just put the date in the version field, people would know how old the software is (this applies to every software btw not just Java a…
Does it tell you anything? If this "software" just bumps the date and never provides anything meaningful it is useful to you? It's about the substance.
> HashMap.putAll() now has a fast-path when the Map is a HashMap, which directly calls putHashMapEntries(), resulting in a 66-86% improvement (PR #28243);
> A new intrinsic for the AVX2 architecture has been added for binary search, resulting in a 1.5x to 2.35x improvement for arrays above a certain threshold (int=256, long=768, short=512, char=512) (PR #30612).
Ok THIS is impressive!
Give us some break we just recently migrated to Java 11 from Java 8
Java 27 already? I just learned about Java 26. But I’m not complaining, the JEPs that is getting introduced on every release are quite exciting features. I highly recommend following the Java official YouTube channel, they publish entertaining, yet informative videos/shorts about tips/tricks/features.
Since 2018 they've been making two releases per year. One in March and one in September.
Earlier quoted context omitted.
But can't you continue to run older bytecode versions on newer JVMs? I think you can also specify the source version separately.
Yes, you can. There is no need to recompile, unless you're interested in new language features. Maintaining binary compatibility is a principal goal of the platform which continues to constrain design decisions for all future changes.
Give us some break we just recently migrated to Java 11 from Java 8
Earlier quoted context omitted.
I believe that's by design: applications are encouraged to upgrade often. That's usually a smooth process for standard-conforming applications. Applications that need to move slower can stick to LTS versions. LTS hopping has become a little bit more viable since the interval has been shortened to two years, i.e., four major versions.
> I believe that's by design: applications are encouraged to upgrade often. I'm not sure what's your thought process here. I'm not saying they should have a release every 2 years instead of every half a year, but that their numbering scheme is bad . It makes upgrading harder. If they'd just put the date in the version field, people would know how old the software is (this applies to every software btw not just Java a…