I'm not sure I like the module import system very much. I think `import *`-like constructions make code a bit easier to write, but much harder to read, especially for developers new to the language / codebase.
C# and Nim love that style, and it makes them almost unreadable without a good IDE.
Personally, I much prefer Python's "short aliases" style, e.g. `import torch.nn.functional as F`
dionian 11 minutes ago [-]
so module imports looks to be different from normal imports and actually helps reduce the number of imports the developer needs to write. FWIW Scala (which runs on java) does have import renaming and also type aliases which can do what you mentioned.
BlindEyeHalo 1 hours ago [-]
Crazy that it took this long to allow parameter validation and transformation before calling super in the constructor.
That was something that always bothered me because it felt so counterintuitive.
PaulHoule 17 minutes ago [-]
I've been programming in Java since before JDK 1.0 and that was one misfeature that bothered me then but that I've long since learned to work around.
delusional 59 minutes ago [-]
Especially because you were always able to bypass it by declaring a `static` function and calling that as part of the parameters to `super`:
public Foo(int x) {
super(validate(x));
}
validate would run before super, even though super was technically the first statement in the constructor, and the compiler was happy.
bootman 2 hours ago [-]
Java has been such an amazingly solid technological foundation... and for a long, long time! It may not be the most sexy language but it's been a stable one. We have applications created with Java 1.4 running happily on Java 21 LTS and expect to upgrade to this latest LTS (Java 25) soon. Java for the win!
ivanjermakov 21 minutes ago [-]
I wonder where Java would be today without superb tooling and smart student programs from JetBrains.
ilt 38 minutes ago [-]
Kind of tangential, I still remember Gmail app created in Java which used to run on my touch Symbian phone in 2009. It was cute as hell and got the work done.
freedomben 32 minutes ago [-]
Neat, I wrote some swing apps back in the day that I've thought about resurrecting, but didn't want to have to do much modifying since they are mostly toys, though useful to me. I'm gonna give it a try!
ameliaquining 24 minutes ago [-]
Is Swing good now? Usually when people say Java is good now I assume they're not talking about Swing.
whartung 12 minutes ago [-]
Swing is swing, it's as good as it's always been (eye of the beholder). As I understand it, it hasn't completely rotted on the shelf, they've made updates to the rendering to better leverage modern hardware, but it's not a modern toolkit by any means. But it is maintained, it still works.
JavaFX is good (I really like FX), and maintained, and portable. They just came out with 25 I think. But it's a completely different model than Swing.
freedomben 16 minutes ago [-]
No, swing is pretty out of fashion if not deprecated. I know it pretty well, but still wouldn't choose it if starting a new project today.
I'd use Qt, though if you're not comfortable with C++ I've been told JavaFX is pretty good
dionian 10 minutes ago [-]
ive tried javafx but its always easier to me to go back to swing, if it aint broke dont fix it.
dionian 10 minutes ago [-]
The JVM and its ecosystem can be used from other languages too like Scala which has all the sexy stuff, also clojure et al
Can't wait to have a job migrating an application from 17 to java 25 in 10 years!
gunnarmorling 13 minutes ago [-]
I wouldn't expect migrating from 17 to 25 to be an awful lot of work. The hard bump was moving from Java 8 to 9+ (11, typically), due to the introduction of the module system, removal of APIs previously shipped with the JDK (e.g. JAXB), etc. Things get much easier once you've passed this hurdle. Adopting 17 posed another, usually smaller, challenge due to reflection not working OOTB like before, but I'm not aware of other, equally disruptive changes after 17.
thewisenerd 15 minutes ago [-]
recently pulled the trigger on a migration out of jdk8
we decided to bite the bullet and do 21 instead of 17; one of the reasons being 25 being just around the corner.
as far as i can tell, the biggest hurdle is 8 to 11 (with the new modules system); but it's smooth sailing from there. the proof-of-concept was done with jdk17, but it worked as-is with jdk21 (except guice which needed a major version bump).
(of course being with a jvm language instead of java itself also probably helped)
What is the current situation of using Java (from legal standpoint)? In open source and in commercial setting? Oracle has a lot of fantastic technology locked up in Java (things like Truffle), how reasonable it is for new projects?
whartung 7 minutes ago [-]
The only real nut right now is, if you're using the Oracle distributions, only the latest LTS is, essentially, free to do anything with.
Older releases are under their OTN license, which is only for personal and development, but not production.
Again, this only matters if you want an Oracle sticker on your runtime, OpenJDK and the other projects are full boat "do whateva" JDKs.
exabrial 1 hours ago [-]
There is literally 0 worry. OpenJDK is fully open source.
deepsun 39 minutes ago [-]
It's only a consideration if you are going to write your own Java implementation and distribute it.
piva00 1 hours ago [-]
Use OpenJDK (or similar) and you are free from any Oracle shenanigans.
ffsm8 1 hours ago [-]
I don't disagree (it is gpl licenced after all)- but it's worth keeping in mind that openjdk is still provided by oracle, too.
And all the other variants ultimately just repackage it. So if oracle doesn't care about destroying the Java IP, it definitely could cut everyone off from updates going forward.
I don't think they'll do so however, MySQL is still freely usable too, right? And that's oracle IP too.
Might change if they ever get into financial troubles, but that's the same issue with all languages and frameworks.
thuridas 51 minutes ago [-]
And there is Amazon Correcto, Eclipse Temurin...
Sure, that could stop to maintain it, but would put the power immediately in the hands of other companies with a fork
That said, you always have oracle's greediness...
giancarlostoro 25 minutes ago [-]
> Sure, that could stop to maintain it, but would put the power immediately in the hands of other companies with a fork
I have a feeling all those companies / orgs would band together to maintain it.
miki123211 20 minutes ago [-]
Honestly, Java is one of those technologies I would never worry about in this way.
It is used everywhere. Just among the faang companies, Apple, Amazon, Netflix and Google definitely use it at scale, and they're just the tip of the iceberg. Taking away JVM updates would almost be a company-ending event for them, and they definitely have the resources to keep it alive if Oracle ever dies.
mrsilencedogood 2 hours ago [-]
Damn, still not structured concurrency full release. Really looking forward to that one.
Happy to see Scoped Values here though. That'll be big for writing what I'll call "rails-like" things in Java without it just being a big "static final" soup in a god-class, or having a god object passed around everywhere.
pjmlp 2 hours ago [-]
Much better this way with previews, than the mess C++ is having nowadays with standardising features without implementations.
jayd16 2 hours ago [-]
I hope structured concurrency ends up feeling better than async/await with less sugar. The examples do not instill confidence, but we shall see.
pjmlp 2 hours ago [-]
Unfortunately on .NET side, TPL Dataflow doesn't get enough love.
jayd16 1 hours ago [-]
They added an async Channel and its actually pretty nice to work with, at least.
dionian 2 hours ago [-]
I would be shocked if they came up with something that made me want to move away from ZIO.
I'm not sure I like the module import system very much. I think `import *`-like constructions make code a bit easier to write, but much harder to read, especially for developers new to the language / codebase.
C# and Nim love that style, and it makes them almost unreadable without a good IDE.
Personally, I much prefer Python's "short aliases" style, e.g. `import torch.nn.functional as F`
That was something that always bothered me because it felt so counterintuitive.
public Foo(int x) { super(validate(x)); }
validate would run before super, even though super was technically the first statement in the constructor, and the compiler was happy.
JavaFX is good (I really like FX), and maintained, and portable. They just came out with 25 I think. But it's a completely different model than Swing.
I'd use Qt, though if you're not comfortable with C++ I've been told JavaFX is pretty good
Java 25 is an LTS release.
we decided to bite the bullet and do 21 instead of 17; one of the reasons being 25 being just around the corner.
as far as i can tell, the biggest hurdle is 8 to 11 (with the new modules system); but it's smooth sailing from there. the proof-of-concept was done with jdk17, but it worked as-is with jdk21 (except guice which needed a major version bump).
(of course being with a jvm language instead of java itself also probably helped)
Older releases are under their OTN license, which is only for personal and development, but not production.
Again, this only matters if you want an Oracle sticker on your runtime, OpenJDK and the other projects are full boat "do whateva" JDKs.
And all the other variants ultimately just repackage it. So if oracle doesn't care about destroying the Java IP, it definitely could cut everyone off from updates going forward.
I don't think they'll do so however, MySQL is still freely usable too, right? And that's oracle IP too.
Might change if they ever get into financial troubles, but that's the same issue with all languages and frameworks.
Sure, that could stop to maintain it, but would put the power immediately in the hands of other companies with a fork
That said, you always have oracle's greediness...
I have a feeling all those companies / orgs would band together to maintain it.
It is used everywhere. Just among the faang companies, Apple, Amazon, Netflix and Google definitely use it at scale, and they're just the tip of the iceberg. Taking away JVM updates would almost be a company-ending event for them, and they definitely have the resources to keep it alive if Oracle ever dies.
Happy to see Scoped Values here though. That'll be big for writing what I'll call "rails-like" things in Java without it just being a big "static final" soup in a god-class, or having a god object passed around everywhere.