Rendered at 21:23:15 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
jsiepkes 6 hours ago [-]
Dear diary, the year is 2094, 10 years since society collapsed. The neighbors went scavenging for food and I haven't seen them in 4 days. I fear the worst. Meanwhile, JEP 533 – Structured Concurrency still hasn't been declared stable, and it has entered its five-hundredth preview release in OpenJDK 136.
Alifatisk 9 hours ago [-]
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.
MYEUHD 9 hours ago [-]
Since 2018 they've been making two releases per year. One in March and one in September.
5 hours ago [-]
tpoacher 9 hours ago [-]
would you mind linking to the channel? not sure which one you mean
Give us some break we just recently migrated to Java 11 from Java 8
nitwit005 55 minutes ago [-]
You've probably done most of the work if you've already made that jump, as that's often the hardest transition.
ivanjermakov 8 hours ago [-]
Don't be scared of a big number, since 2018 they do 2 releases each year.
exabrial 6 hours ago [-]
I laughed. Jump straight to 25 next! It's awesome!
samus 8 hours ago [-]
Just one more push to Java 17; from there on it should be smooth sailing. I hope you have built up a comprehensive regression test suite as part of the migration.
exabrial 6 hours ago [-]
> On the performance side, I noted two interesting improvements:
> 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!
nerdile 8 hours ago [-]
> tests showed that for environments with one CPU (or fewer)
Article seems AI generated. Is there an official announcement we could be discussing instead?
stanac 8 hours ago [-]
It's probably comment on shared CPUs. Like in kubernetes where you can assign 300 milliCPUs.
I didn't read the article, it doesn't open for me (HN hug?).
atomicnumber3 8 hours ago [-]
I wonder if it's a joke about oversubscribed environments (cloud VPS) or a real remark about fractional CPU budgets in container environments
mountainriver 8 hours ago [-]
The best thing to ever happen to the software world was Oracle buying Sun and consequently Java.
Java was great at its time but then had to go. Oracle gaining control over them sped up this process.
Poor Android got caught up and now half our phones don’t work
UltraSane 8 hours ago [-]
What are you trying to say?
stanac 8 hours ago [-]
I think they are saying Java is dead?! Not sure how else to interpret the comment. If that's the case I have to disagree. There are probably billions of lines of Java in enterprise, it will never die.
chasd00 8 hours ago [-]
my standard Java analogy is it's like a garbage truck. Java is out there every day doing a job that's absolutely critical but rarely, if ever, in the lime light.
re-thc 8 hours ago [-]
> but rarely, if ever, in the lime light
I disagree. The open web likes bashing it as a scrape goat. Reddit, X/Twitter, etc. It's died down some lately but there were at least a couple a years when this was very out there.
UltraSane 8 hours ago [-]
Java is still very popular and even being used for new projects.
11 hours ago [-]
8 hours ago [-]
robmccoll 8 hours ago [-]
Non-nullable reference types at the language level? Null coalescing operator? Safe navigation accessors? Record composition?
zelphirkalt 9 hours ago [-]
Is it just my personal feeling, or are Java version numbers becoming as inflationary as browser version numbers?
doikor 9 hours ago [-]
They moved to a schedule instead of waiting for features to be finished.
Basically we get a new major version release on a schedule. Everything that is finished gets packaged in and everything else pushed to the next release.
The issue before was that they marked beforehand "version X will contain feature Y" and then feature Y got delayed by 3 years which means everything else in version X also got delayed by 3 years even though they were done 6 months ago.
this_user 9 hours ago [-]
It's too many releases now. At some points, the numbers just become noise. I think most people will stick to the LTS releases, but even those come out every two years.
bmacho 9 hours ago [-]
The numbers have become meaningless noise already. This release should've been called 26.1, then 27.0, 27.1, 28.0 and so on. Year.version. How Canonical does it with Ubuntu.
The current numbering scheme is annoying and distracting, bears no information yet is still error prone.
the-smug-one 8 hours ago [-]
I don't see the point, just increment it every release. Don't see what errors are prone either
samus 8 hours ago [-]
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.
bmacho 8 hours ago [-]
> 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 and Ubuntu).
Their current versioning system doesn't help anyone in any imaginale circumstance.
samus 16 minutes ago [-]
The official guidance is very simple and straightforward: upgrade regularly and keep eyes open for the actual things that could cause trouble. If a project cannot keep up it can always stick to LTS versions. That's it.
re-thc 6 hours ago [-]
> If they'd just put the date in the version field, people would know how old the software is
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.
doodpants 7 hours ago [-]
> Year.version
I think you mean "(Year % 100).version". Or is it "(Year - 2000).version"? Pardon me for being overly pedantic, but ever since Y2K it really bugs me when someone refers to a 2-digit number as "the year".
re-thc 8 hours ago [-]
> 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?
bmacho 7 hours ago [-]
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 any case. It's just... there. A noise.
E.g. just this article title on HN: "Java 27: What's New?" doesn't tell you whether Java 27 is old or new. "Java 26.1: What's New?" would.
re-thc 6 hours ago [-]
> doesn't tell you whether Java 27 is old or new. "Java 26.1: What's New?" would
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?
the-smug-one 8 hours ago [-]
Why? Just upgrade. Make it so that your org can deal with it.
OtomotO 9 hours ago [-]
Unless you're forced at gunpoint, how can there be too many releases?
Rust releases every 6 weeks, since 2016...
If you don't want to update, just don't?
If you feel (!) pressured, you should work on that.
ptx 8 hours ago [-]
With each new Java release the previous one becomes instantly unsupported (meaning that it receives no security updates), unless you pay Oracle (or another vendor). So you are forced to update if you want security updates (or run only LTS releases, or pay a vendor).
pgwhalen 8 hours ago [-]
So if the matters to you, run the LTS release, right? I'm not sure I follow the concern.
robertjpayne 8 hours ago [-]
Rust releases are just compiler toolchain, maybe some new syntax features. Java includes the JVM which is subject to way more security issues and needs much more frequent updating.
wtetzner 8 hours ago [-]
But can't you continue to run older bytecode versions on newer JVMs? I think you can also specify the source version separately.
samus 8 hours ago [-]
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.
doikor 3 hours ago [-]
There are some actual removal of feature too (breaking backwards compatibility on purpose). But those come with deprecation warnings for years before the actual feature is removed. And even then quite often it is still possible to enable with some feature flag for a version or two.
OtomotO 8 hours ago [-]
> Java includes the JVM which is subject to way more security issues and needs much more frequent updating.
Then releasing more often is better, because the security fixes get out of the door faster?!
If previously a Java Update took 3 years, then the corresponding JVM version would be 3 years old as well.
If there were patch release in between, I see no difference to now.
samus 8 hours ago [-]
Patches are released continuously. The upstream versions get them immediately and they are then backported to LTS versions. Whether the patches actually become available simultaneously I cannot say without.
ivan_gammel 9 hours ago [-]
[dead]
mountainriver 8 hours ago [-]
Do they have backwards compatibility guarantees?
Otherwise what are we doing here?
cogman10 8 hours ago [-]
They do, some of the best of any language.
That said backwards compatibility problems still hit as some libraries enjoy using internal APIs.
It's not an every time thing and it's been easier and easier with updates.
collabs 8 hours ago [-]
I work with dotnet but my understanding is that some applications/ teams are still on java 8 with spring boot or whatever so it isn't like they aren't modernizing but they are choosing to do so at their own time which is fine I think
mkurz 9 hours ago [-]
Its just your personal feeling.
StefanBatory 9 hours ago [-]
Does the website have geoblocking or did HN gave it a hug of death?
Java is swell and all, but having seen how the vendor treats even their large customers, I could never in good conscience recommend them to anyone I do business with. Better to miss out on the latest features and work with more respectful vendors IMO.
speed_spread 8 hours ago [-]
What vendor? OpenJDK is free and libre. If you mean Oracle, then that's a choice your employer made and yeah, you're SoL, especially for working in such a place.
This is the official Java channel.
https://www.youtube.com/@java
> 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!
Article seems AI generated. Is there an official announcement we could be discussing instead?
I didn't read the article, it doesn't open for me (HN hug?).
Java was great at its time but then had to go. Oracle gaining control over them sped up this process.
Poor Android got caught up and now half our phones don’t work
I disagree. The open web likes bashing it as a scrape goat. Reddit, X/Twitter, etc. It's died down some lately but there were at least a couple a years when this was very out there.
Basically we get a new major version release on a schedule. Everything that is finished gets packaged in and everything else pushed to the next release.
The issue before was that they marked beforehand "version X will contain feature Y" and then feature Y got delayed by 3 years which means everything else in version X also got delayed by 3 years even though they were done 6 months ago.
The current numbering scheme is annoying and distracting, bears no information yet is still error prone.
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'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 and Ubuntu).
Their current versioning system doesn't help anyone in any imaginale circumstance.
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.
I think you mean "(Year % 100).version". Or is it "(Year - 2000).version"? Pardon me for being overly pedantic, but ever since Y2K it really bugs me when someone refers to a 2-digit number as "the year".
> 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?
E.g. just this article title on HN: "Java 27: What's New?" doesn't tell you whether Java 27 is old or new. "Java 26.1: What's New?" would.
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?
Rust releases every 6 weeks, since 2016...
If you don't want to update, just don't?
If you feel (!) pressured, you should work on that.
Maintaining binary compatibility is a principal goal of the platform which continues to constrain design decisions for all future changes.
Then releasing more often is better, because the security fixes get out of the door faster?!
If previously a Java Update took 3 years, then the corresponding JVM version would be 3 years old as well.
If there were patch release in between, I see no difference to now.
Otherwise what are we doing here?
That said backwards compatibility problems still hit as some libraries enjoy using internal APIs.
It's not an every time thing and it's been easier and easier with updates.