Most of the reasons Java dropped out of popularity no longer apply, and at this point it is an incredibly stable and mature ecosystem.
I can come back to a Clojure program I wrote ten years ago and it runs great, meanwhile a TypeScript program I write 6 months ago requires a bunch of updating and cleanup.
I don't know how to use java and not violate one of Oracle's EULAs. I could read about it and figure out how to do it safely, or I could just not use java. Java isn't essential (for greenfield projects). There's lots of good alternatives, so I'd rather do that.
If you use Oracle's distribution of the JDK then you are an enterprise customer and should have the resources to deal with their license terms.
Hey! I work at Microsoft and helped us launch the Microsoft Build of OpenJDK.
I can categorically say that yes you can use Java without worrying. As long as you don't use a commercial binary from a vendor that has certain licensing restrictions.
Our build of OpenJDK is free for any use, and comes with commercial support (you know, the one you can open a ticket and ask us to look into the issue) at no extra cost for workloads on Azure.
Is Microsoft really better than Oracle in that regard?
The multi-year Google vs Oracle lawsuit put the likes of Amazon and Facebook to unease. And meanwhile there was this safe and performant language with no strings attached under a nice Apache license. They quickly made a Foundation around it as a 501(c)(6) - trade association, and not a "public good"-kind of a non-profit. This essentially means that as long as you're a member and pay the fees you won't be sued - exactly what all these companies wanted. So now they all keep up the funding and employ some of the compiler developers to keep the lights on for next 20 years or longer.
The fact that the language itself is really good for what they need it for is obviously the major reason why they support it, but the legal side of things definitely helped with adoption.
Especially now that hardware architectures are getting fragmented again, I hope it becomes more relevant.
I think Springframework is dragging Java's reputation down. I know Spring boot is better but it's such a monstrosity.
I feel like sadly Python has won the war, though. Good enough for most things even though it is pretty rubbish.
I see people trying to use Rust now for prod AI systems.
With this in context...
> I think Springframework is dragging Java's reputation down. I know Spring boot is better but it's such a monstrosity.
Is that really so? Spring's not the best, but it's definitely better in medium / large environments than a lot of other 1s. There are way more train wrecks to maintain that especially don't have any documentation or the libraries have gone dead.
It's an uphill battle, but it might just climb the hill because it's still such a behemoth.
And now let’s talk about .collect(toList())…
And records which look like ugly beans…
Java is the land of the verbose. But it can probably be solved with 9 extra characters on every line.
These days I don't see those as significant issues, tbh.
I would prefer a Clojure program, but I'll take Java over Typescript at this point.
Python code that follows traditional Python paradigms is called "Pythonic".
Java code that follows Java paradigms is called "awful".
To be fully transparent, I've never written Java professionally, only for a couple small hobby projects 10 years ago, plus some while in school, so my opinion isn't worth the pixels you're reading it on, but I look at most Java code with abject horror.
Endless levels of abstraction. The apparent inability to write a simple function and instead creating a "ThingDoer" class with a single function called "doThing". Run-time introspection and reflection EVERYWHERE. Stack traces that are just an endless stack of calls to functions like ".invoke" and ".run".
I've been under the impression that all of that is a by-product of Java's strict type system, but someone please correct me. Why do Java paradigms seem so awful?
Is that thanks to JVM or due to the way how Clojure works? Because I can share the same anecdotes for my Clojurescript projects. I can grab any old nbb script and things just work off the bat - sometimes I have to update some npm dependency, but most of the time, things simply aren't horribly broken. Meanwhile, I just spent half a day jumping around for weird Python dependency and venv magic dance, just for the sake of running five interdependent scripts.
In any case, the dominant way people build Clojure has changed. Ten years ago it probably used lein. Nowadays a new project will probably use deps.edn.
Java has the additional issue of being object-oriented, which leads to spaghetti parent-child relationships under stress.
In Java a lot of code looks like this
void foo(Bar bar);
void foo(new Bar { @override boolean baz(Fish fish) { return false; } });
foo((Fish fish) -> false);
foo(this::fries);
saveMenuItem.registerMenuClickListener(myMenuClickHandler);
saveButton.registerClickListener(myMenuClickHandler::onMenuClick);
1. No unsigned integers. "byte" is -127 to 128. I believe this means it's not straightforward to make a 32-bit RGBA structure since you options are either using a signed "red" or using a 16-bit integer to store the 8-bit values. by the way I tried to benchmark how slow Java was compared to C in a simple test (I had arr1[] with indexes of arr2[] which contained values and I created arr3[] by resolving them) and it seems to be only half the speed of C which is probably fast enough for some basic low-level 2D graphics.
2. String.split takes a regex argument and there is no standard way to split without a regex. This was really confusing to me, but fortunately it's very easy to write your own .split, so it's not that much of a big deal.
3. You can call a different constructor with this(), but it has to be the first statement in the constructor. This one is pretty crazy! It would make sense if you couldn't access member fields before calling the constructor, but having to be first statement means if you want to calculate the argument for one constructor based on an argument passed to another constructor you need to do it inside the parentheses.
So far there is only 2 things I wish Java had. First the ability to implement methods in interfaces so you could use them if you have an interface instead of using a static method. Second I wish @NotNull was the default. This is a problem that Kotlin fixes so I think if you like Typescript for tis type-safety learning Kotlin would be a good idea.
3 is not an issue anymore since java 22 https://blog.jetbrains.com/idea/2024/02/constructor-makeover...
Java 25 is an LTS release.
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.
From what I've seen, most people only care about the LTS versions of Java. Which means that after Java 21 LTS comes Java 25 LTS. The same happens with Ubuntu (after 22.04 LTS comes 24.04 LTS).
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`
No, I don't.
For some reason there exists a group of programmers that refuse to acknowledge use cases like "let me write a small program in nano over SSH" or "let me change one hardcoded variable and recompile the project and never touch its source code again". If your code is unreadable without IDE, it means that either IDE should be shipped with the compiler because it's an essential part of the language, or the language is garbage because its designers literally admit "we're too stupid to figure out how to solve this issue, hope that IDE does something smart because we can't".
In small codebases anything would work.
PS: why do you even look at imports? Any decent editor just hides it, you never need it, you navigate just by clicking/hotkeys on names directly from code.
I think a lot of what turns people off to the C# developer experience is not using full-blown Visual Studio. VSCode is great but I would never open csproj or sln files using it unless I needed to manually edit their actual XML contents.
It's not broadly advertised that you can buy a perpetual & fully licensed copy for $500 [0]. No subscription or other cloudy scam stuff is required, although Microsoft's product pages will initially lead you to believe it is.
[0] https://www.microsoft.com/en-us/d/visual-studio-professional...
using Project = PC.MyCompany.Project;
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.
However, you still have concurrent code. The example given uses futures rather than async/await, and so the thread blocks waiting for these other threads to complete.
The Java alternative to async/await is the virtual threads. Since they are not GC roots and the stack is a chain of heap-allocated objects, the idea is that they can have significantly lower overhead in terms of memory usage for small tasks. Rather than the compiler generating heap objects to store intermediate state, it just uses a virtual thread's stack.
However, even without async/await syntax you still have equivalent concepts. Since the compiler doesn't have native structured concurrency, it is emulated by putting tasks in lambdas. You fork off subtasks, and do a blocking get() to resolve the futures for their results. Heavy use of fork(), run() and get() aren't necessarily better than async and await keywords.
One concern I have is that Java virtual threads are supposedly preemptive, not cooperative. This means you will have less guarantees around concurrent modification than you would with a typical async/await system running cooperatively on an executor. Several languages willing to make more core changes around adding async/await have gone as far as to also integrate actor functionality to help developers write concurrency-safe code. I don't see Java being able to provide developer help/diagnostics here like other languages can.
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)
If you could get through that, you’re golden. From what I’ve seen going to 21 or 25 look easy. They’re just adding features, the big upheavals of doing the long needed cleanup are over.
I expect keeping up to date to be far easier from now on.
AFAIK, these libraries did so because there was no alternative, and some of the changes in Java 9 and later were done to provide them with an alternative. The only thing left is Signal/SignalHandler, which AFAIK still has no alternative outside the sun.* packages.
Java's from the era [1] of virtualization : machines, languages, web (with applets, flash etc) where you focus on writing code once, and delegate the running to a VM, reaching an ever growing list of platforms/devices the VM knew.
But then came Steve book of Jobs and vajazzled so-called phones and desktops, far better than Bill electronic Gates. Why write an App in java and have that run [2] on Phones, Web, Desktop and Server when you can create N-code bases, one for each platform and device?? Oh and why would you want games in Flash [3] when you could be saving your battery to watch a cat tumble over a dog in 8K definition???
Seriously though, I think, the vm era is going to come back in the next few years, and expand into new areas, such as UI vm to deal with os/platform specifics. A healthy-level of tech decoupling is a good strategy, for everyone, but not full isolation. The vm model is much better for consumers and devs - far less lock-in, more future-proof [4], more freedom to innovate and try new markets. Usually, the vast majority of consumers and most devs have ordinary / run-of-the-mill issues. Most popular apps/sites are about shopping, basic entertainment, library-functions (search, referencing, reading), and chatting.
[1] 80s/90s [2] with slight platform variations [3] Flash or some alternatives. Jobs banned Flash for security+energy consumption reasons. [4] abstract/wrap intricacies of lower layers
This is cool: https://openjdk.org/jeps/512 (JEP 512: Compact Source Files and Instance Main Methods). It will allow beginners to progressively ease into the language and remove arbitrary gatekeeping from the language itself.
I also went down the rabbit hole on the Shenandoah GC JEP and learned that it was actually named after the Shenandoah Valley. Super cool.
If you don't like Oracle (and I wouldn't blame you), there are alternatives from parties ranging from the Eclipse Foundation to Microsoft and Amazon that will do the same thing.
As for new projects, Java is here to stay. It's longevity is part of why companies are still using Java 8/11; once you write it, it'll run pretty much forever.
The language lags behind in terms of features compared to pretty much any competitor, but it's functional enough to get anything important done.
I'd personally go Kotlin if you were to rely on the JVM (almost entirely because Java still lacks nullable types which means nullpointerexceptions are _everywhere_) or C# if you don't like the Kotlin syntax, but Java is Good Enough.
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.
[1] https://www.oracle.com/uk/java/technologies/downloads/#java2...
The UPL is an OSI-approved open source license. It shouldn't be a problem to use in any setting, but you should check with your legal team to see what licenses are approved.
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.
Why is that a language problem as opposed to an IDE problem?
Taken from: https://blogs.oracle.com/java/post/detaching-graalvm-from-th...