More new programs should be written in Java/on the JVM.
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.
Oracle makes me too uneasy. Can I use Java without the worry of incurring Oracle's wrath? Maybe, if I make sure I use openjdk/jump through some hoops I'll be fine. Or, I could just use any other language and not have that worry looming over me. C# is right there if I want a java-like experience without the anxiety of Oracle breaking my kneecaps.
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.
Just use OpenJDK (only downside is you have to upgrade every half year) or a distribution of another vendor (most people use Eclipse, or Red Hat if they already are Red Hats customers). It's really not as difficult as it is made out to be.
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.
"Am I using the correct language runtime distribution (or version thereof) so I don't get into legal trouble?" Is a question none of Java's competitors have to ask.
Even using OpenJDK is a sword of damocles waiting to fall. If I forget to update OpenJDK, Oracle could come after me. It's just risk that I don't have to worry about by choosing not to go with Java. It's probably not a lot of risk, but it's risk nonetheless that doesn't exist with Java's competitors.
Competition is so fierce in the language space and there are so many good options that java can't afford to have any friction points like this.
EDIT: I got oracle openjdk and oracle jdk mixed up. They're different things. It looks like the oracle openjdk does not have its license change, the oracle jdk does. This is a problem/risk I don't have to worry about with any other language, but getting the two mixed up is on me.
> If I forget to update OpenJDK, Oracle could come after me
I must have missed that section of the GPLv2.
Oracle does distribute a different (not OpenJDK) Java distribution under a special not-open-source no-cost license, which includes a stipulation that you can't use updates after the next LTS release. This only adds to the confusion: you really only need Oracle's special distribution if you want paid Oracle support for it or their stuff that requires it.
>Even using OpenJDK is a sword of damocles waiting to fall.
No, it really isn't. Honestly, people seem to go to great lengths of talking nonsense to discredit Java. There are many reasons to not like a language, and that is absolutely fine. But there is no point talking nonsense about it when you could just... not use it.
I was under the impression that openjdk changes licenses once a new version comes out. That's why the parent comment said "the only downside to openjdk is you have to upgrade every half year", right?
This coming from a big Oracle skeptic. None of this is true. There is no practical friction left if you're using OpenJDK. And from the parent comment, you do not need to upgrade every 6 months. Most people just work with the LTS version.
> "Am I using the correct language runtime distribution (or version thereof) so I don't get into legal trouble?" Is a question none of Java's competitors have to ask.
I am not sure this is 100% true. I think that if you download a specific binary of Anaconda (for Python), you may get into a situation where you have to pay.
For example, at Anaconda.com, one can download their distribution (their build) but the fine print says: "Use of Anaconda’s offerings at an organization of more than 200 employees/contractors requires a paid business license unless your organization is eligible for discounted or free use."
I think that PSF License is permissive and allows binary versions of Python without the maker having to release the source code.
So, downloading Anaconda as a Python distribution (build) is analogous to downloading Oracle JDK (a commercial build of OpenJDK, from Oracle).
That's because none of Java's competitors have commercial support offerings to begin with, as far as I know?
It's the same situation as with Linux. Red Hat Enterprise Linux isn't free. But it'd be weird if you said you're afraid of using Linux because the licensing is too complicated.
> "Am I using the correct language runtime distribution (or version thereof) so I don't get into legal trouble?" Is a question none of Java's competitors have to ask.
Umm..sorry, but this is just sheer nonsense. There are many commercial Python distributions like ActiveState ActivePython, Anaconda Enterprise, etc that you need to pay for.
If you download and use their prebuilt ActivePython installer without a proper license in a commercial setting, you’re breaching a contract and will get into legal trouble.
> This is a problem/risk I don't have to worry about with any other language,
No, you most certainly DO have to worry about this in many other languages which offer commercial support offerings. (Python/C++/Perl/NodeJS,etc)
> Even using OpenJDK is a sword of damocles waiting to fall.
Licensing for OpenJDK is non trivial. Look at the large table and various bullet points Oracle had to make to tell you the license. https://www.oracle.com/java/technologies/javase/jdk-faqs.htm...
(open the first dropdown on their FAQ page to open up their "licensing matrix")
This is a mess, and is the license going to change again while I'm locked in the java ecosystem?
Edit: It looks like the openjdk is consistently under the gplv2, I don't know why it has so many different entries in their table. I think I probably got opendjk and oracle jdk mixed up. I think the person I was replying to who said openjdk needs to be updated every half year got confused as well. It's so hard to even talk about all the different jdks without getting them mixed up or confused. Again, no other java competitors have this problem.
Licensing for OpenJDK is trivial (GPLv2+Classpath). Just like gcc/g++ and its runtime library exception.
Licensing for Oracle JDK is more complicated. This is the one where you can use it for free, but after the next LTS you either have to move to the LTS or pay for updates. There's no reason to use Oracle JDK unless you want to pay for support from Oracle, or if your applications specifically require Oracle JDK. Oracle JDK is built from the same source as OpenJDK.
What is even the benefit to using Oracle JDK at this point? Years ago, I saw that some jetbrains IDEs said to use it instead of openJDK, but I haven't seen anything else like that.
Oracle JDK offers LTS support with regular security patches and critical bug fixes, even for older LTS releases. (More than a decade plus, I believe, but need to check)
OpenJDK community builds usually only provide updates until the next release (6 months).
Oracle offers paid commercial support contracts: guaranteed patch timelines, 24/7 enterprise support, performance issue troubleshooting, and compliance assurance.
You can also built features atop the Oracle JDK and still get support. SAPJVM does this for instance - hot debugging as a feature.
What, exactly, are the JVM's competitors (not Java, btw)? You can always use Kotlin or Scala if they take your fancy. They both interop fantastically with 20+ years of the Java ecosystem.
EDIT: The only remotely competitive ecosystem is JS/TS (because billions of pre-installs) and C#.
> Even using OpenJDK is a sword of damocles waiting to fall. If I forget to update OpenJDK, Oracle could come after me. It's just risk that I don't have to worry about by choosing not to go with Java. It's probably not a lot of risk, but it's risk nonetheless that doesn't exist with Java's competitors.
Can you explain what the friction is ? If you download and install the ActiveState Python distribution in a commercial setting and accept the license agreement without reading and get sued legally at a later point, will you say Python has too much friction ?
Just go to https://openjdk.org/ and click "Download". Or say `brew install openjdk` (macOS) / `apt install openjdk` (linux).
> Oracle makes me too uneasy. Can I use Java without the worry of incurring Oracle's wrath?
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.
If we look at .NET vs Java, then yes, Microsoft is better. Microsoft may charge for some of its dev tools (Visual Studio etc), but .NET itself is and was always totally free.
Now, don't get me wrong: I have grave suspicions there is currently only one actual implementation of them (I don't count hobby, or abandonware, ones) but IMHO "actual standard" combined with "for real reference implementation" is way better than just reference implementation
---
since I'm still within the edit window, the MAUI referenced by the sibling comment is MIT licensed https://github.com/dotnet/maui
Isn't the official MAUI still basically "everything but Linux"? I haven't been keeping up with that the last 2 or so years and I just remember there being an unofficial GTK implementation somewhere in the interwebs, but nothing being officially supported on Linux.
Linux desktop has a tiny market share. No reason to invest significant resources for that. Also, by supporting MAUI on Linux, Microsoft would feed their own competition in desktop area, and it's crucial for them to maintain dominance in that area. I think this is why they did not port the great WPF to Linux as well.
And besides, Linux desktop is a mess. I never learned details on how Wayland / X11 / KDE / Gnome etc. work, which is for what. All I know is that some distros switch from one to another, that one is declared the best, and another the worst, and all of it changes regularly. I'm glad someone in Canonical made the desktop mostly working for me in Ubuntu, although it still lacks a lot compared to Windows.
I think when you need that level of cross platform support to cover Windows, Linux, macOS, maybe mobiles, and you do a serious project, you use Qt.
Depends. If you were there during the Steve Ballmer time then you know that Microsoft will absolutely betray you on almost every dev tech they roll out.
Otherwise C# and .NET have had a pretty solid track record.
You don't have to jump through any hoops. If you don't want to deal with Oracle, don't be an enterprise customer of Oracle and instead just get some openjdk distribution.
- Oracle themselves, at jdk.java.net
- Microsoft, at microsoft.com/openjdk
- Red Hat ...
- Azul Systems ...
- Amazon
- Bell Soft
- Canonical (Ubuntu ships OpenJDK binaries built by them)
- build yourself?
My semi-conspiracy theory is that the success of Rust is partially due to BigTech companies searching for a "legally-safe" alternative to Java.
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.
I'm not sure where things fall on your timeline, but in case you missed it, Amazon has their own Java distribution called Corretto. It was first publicly released in 2018:
This conspiracy theory would explain not only success of Rust, but also Go language and C#/.NET, and any other Java competitor.
I'd say it's 90% because of Oracle and its lawyer-driven business, and 10% because the language is just ugly, and existing libraries are super-ugly and unreadable, with all these Factories and AbstractFactories, and all design patterns forced like a religion whether they're useful or not in a specific context.
Java is hugely popular and widely used on large backend systems. I guess a lot of people here don't work on such systems? I'm always surprised when I see comments like the parent, since in my career exposure to Java is near-ubiquitous.
There has been a move in the past 8 years away from Java on the back end, notably to Go, by several large engineering organizations, which made the move, "motivated" by the example of companies like Google or by projects like Kubernetes, and seduced by the promises of a language simple to learn, build, and deploy.
> seduced by the promises of a language simple to learn, build, and deploy
That's actually quite correct and I'm saying this as someone that does Java on daily basis. Go is in fact superior in terms of deployment. I would rather deploy a Go-written service than a Spring Boot one. That being said, I love using Java for monoliths - large code bases crammed with business logic. I personally don't see Go doing very well in that direction.
Businesses often deal with old databases, message queues, SOAP services, legacy systems. Java has a truckload of well-established connectors (Even more than Python!), well-supported JDBC drivers, and vendor-supported SDKs.
Also features like transaction management, dependency injection, validation frameworks, AOP-style cross-cutting concerns are better addressed in Java.
Java has collection streams with great customizability (filter/map/reduce/etc). Far better writing your 10,000th for-loop in Go. You can also get automatic parallel streams without writing any extra code.
Go's profiling tools (esp memory) are very primitive, sorry. JVM profiling tools beat Go's by orders of magnitude. So does the other tooling - GC tuning, monitoring, etc. Java flight recorder and VisualVM are gorgeous.
That said, Go is still better at memory efficient, tight network software like lean k8s controllers. Though frankly, Rust is encroaching into this space.
I'm not them, but there are few things better for operational insight than the JVM. It has a boatload of tuneables, it has a very rich dynamic code load mechanism (Reflection, ClassLoaders, the new Modules system, and it used to have a strong sandboxing system but they killed that), and at the intersection of those two things is JMX, which is dynamically tuneable deployments via API. It's like having JVM-local feature-flags that one can twiddle without needing to bring down the JVM
And sure, it's not everyone's cup of tea, and/or plenty of people will chime in with "yes, but"s to defend golang or every other platform that isn't the JVM. I'm not yucking your yum! I'm just saying for me, the JVM is the bees knees
> by several large engineering organizations, which made the move
The problem with this type of trend is it's often hype and you never know what actually happens or how does it evolve over time.
I've seen organizations make certain announcements, switch maybe 5%, give up and go in different directions, but only the initial announcement ever hit the news.
> and seduced by the promises of a language simple to learn, build, and deploy
It's always simple if you rip it all up. Nice and shiny toys are always great.
I think the rise of containers and being able to compile and run natively has eliminated the argument that would favor the JVM. It's so easy to fully control your dev and deployment environments now using Docker images and to me, that's a far better solution. tl;dr -- containers eliminate Java long term.
> has eliminated the argument that would favor the JVM
This complaint is taking technology definitions too literally. I doubt new adopters of Java or the JVM are really going on about that now. It's more been about the ecosystem, the maturity, etc.
I'm rooting against Kotlin since it appears to be only usable with the JetBrains ide. I'm totally blind and Jetbrains tools are not nearly as accessible or easy to use as VS Code with all the Java extensions in my experience. At all the jobs I've had no one cared if I didn't use Idea, but considering it looks like there's no good VS Code tooling for Kotlin if I have to use Kotlin professionally it's going to be painful.
What's unexpected about that observation is that they have actually completely separated the presentation layer from the business logic because such a thing was required to have "Code with Me" and their "projector" project wherein one could use IJ from a browser https://jetbrains.github.io/projector-client/mkdocs/latest/a...
But, I am fully talking out of school because I don't know what the actual, no kidding, accessibility hurdles one faces when trying to do work in such a setup, nor what concessions VS Code has made to fix those problems
My major issue is that the IDE doesn't use the same hotkeys or similar interface to VS Code. This isn't necessarily a problem, but the fact that it's so different means the learning curve is absolutely brutal so it's not worth the effort for me to look at it. If there was a basic getting started tutorial that walked you through building a simple program, finding and fixing compilation errors, performing basic debugging etc, that was written from the perspective of a screen reader user that would be incredibly helpful. Something like this may exist, but if it does I haven't found it.
Thanks, I've starred the project so I can keep up with it. I don't currently have any plans to do anything with Kotlin but will look at this if I do in the future.
Java's biggest risk towards continued adoption, by far, is the culture surrounding it - old Java programmers and old Java programs continue to be needlessly verbose, even if the language now has the tools (pretty much) to be as terse as other popular, modern languages.
It's an uphill battle, but it might just climb the hill because it's still such a behemoth.
It all failed when .stream() appeared. Why make people use .stream() for functional programming, plus streams aren’t even reusable, I almost wish they invented a new operator based on an exotic UTF-8 character than those 9 extra characters. Fonts should have a ligature for .stream().
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.
> I can come back to a Clojure program I wrote ten years ago and it runs great
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.
It's not clear whether the author built the Clojure program into a jar or not. If so, it would be thanks to the JVM.
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.
I feel there's much more to it. There are so many pieces in Clojure that just feel like they're done right. Even after a decade of using it, I remain happy. Not a single other language (and I tried more than a few) has kept me happy for so long.
Java has the same problem most imperative languages do, which is the lack of clear separation between mutable and immutable state, rigorously enforced by tooling. Many large-scale Java programs try and work around this by using immutable collections, which certainly makes a difference but can only go so far.
Java has the additional issue of being object-oriented, which leads to spaghetti parent-child relationships under stress.
My biggest Issue with Java, is that it isn't streamlined. There are multiple implementations of the jdk that could be used, Many different build systems, etc. The C# ecosystem is smaller for sure, but it is much more streamlined
I think it is quite high, especially for newcomers to the ecosystem. The popular sdkman CLI tool for managing JDK installations provides 17 different JDKs to install:
With the DotNet SDK for comparisons sake, there is but one provider, and package management is provided as first class citizen in the compiler CLI, removing the need to even pick a "gradle" or "maven" style build tool in the first place for almost any project.
It doesn’t negate the issue at all, especially as sdkman is an optional extra tool. If working with others, that default is not always going to be the one your team develops against either. If you are just trying to pick a jdk and don’t even know sdkman exists, a sensible person will rightly wonder why the ecosystem has fractured into 17 JDKs, or you won’t notice at all and blindly pick a download from the oracle website. I’ve seen it cause confusion many times for new (and old!) Java developers.
Checking a new developer has actually managed to install the correct JDK for a given project is still a thing I have to do, all the time.
Sdkmans docs also have no bearing on the multiple build systems in the java world too, which again simply a non-issue in DotNet and many others.
With over 20 years working with Java, I'd much prefer working on Python for lots of reasons, but a big one is that the kinds of projects that involve Java are always involve the same stupid politics and organizational struggles. I've noticed that projects involving Python are way more enjoyable with less friction, likely due to the organizations themselves being more open-minded and maybe younger. I don't know. At some point, every Java project at every Fortune 500 company I worked with was the same damn hellish mess and I had to get away from that.
> I think Java is the best language for most medium to large projects
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.
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?
Well, there are lots of people out there who view "Pythonic" as a euphemism for awful tbh. Throughout my career I've seen multiple large Python codebases be rewritten in Java after they turned into a mess, including - perhaps most embarrassingly - Google's internal code review tool Mondrian, which was written by Guido van Rossum himself.
One reason Java codebases feel more abstract is that they're attempting to solve problems that the scripting worlds tend to just punt on, or handle in ways that don't scale well. And because Java's type system is nominal, solutions to those problems require names.
For example, a lot of the abstraction in Java codebases is to make things deeply testable. That's what drives dependency injection, which is where a lot of BeanFactory stuff comes from. What's the Python solution to that problem? Often they just hardly have tests by the standard of Java developers! This is why Python is big in ML research where codebases are often small disposable experiments, and why after a brief era where Django was popular it sort of died off in the wider server / big data space.
Another source of complexity and abstraction is a focus on pluggable ecosystems. Databases are abstracted by JDBC, and then again by an ORM, which then might be abstracted again by Micronaut or Spring, and at each layer there are multiple competing implementations available which implement standard APIs. This kind of thing happens much less in the scripting world. The downside is that scripting codebases are far more locked-in to their choice of libraries. Porting a Java codebase from one database or ORM to another is hugely easier, because the core APIs are all standardized.
Is there a full library ecosystem of stuff written like the json parser you shared, which is as complete as the enterprisey library ecosystem? Similarly, SO answers? LLM output? Tutorials? YouTube videos?
I think the answer is no.
It's the same problem with C#. Just adding alternate paradigms means nothing. The only thing that matters is how a majority of code in the ecosystem is structured. In java, that's enterprisey code. Most code is glue code, so you're forced into the majority pattern, lest you want to write endless wrappers...
On the other hand, while typescript supports a lot of the enterprisey nonsense similar to C#, the majority of the ecosystem is written with simple functions, callbacks and options objects. Not in an enterprisey way. I don't need to use decorators to use zod.
People that eschew enterprisey code and prefer simple code can't switch to java or c# until the whole culture changes, regardless of the kitchen sink of features either language adds.
>> On the other hand, while typescript supports a lot of the enterprisey nonsense similar to C#, the majority of the ecosystem is written with simple functions, callbacks and options objects. Not in an enterprisey way.
Going back to culture, who makes up the Typescript community? While C# devs are attracted to it there are many multiples more devs coming from a JavaScript background. This has a big impact on how the culture developed.
Taking a step back. C# devs often need to do frontend work. They could go with what the industry has settled on, React, or go another way. The bulk go with react and some perhaps lament still have to switch their brain to another mode for that work. Frontend is obviously more fragmented, but the scale prevents C# devs from influencing patterns to the extent that they do on the backend.
I'd argue similar for Java devs when it comes to frontend. In the case of Blazor, I think C# patterns are a much smaller factor in decision-making. In fact, lots of C# adherents would default to React given it's the industry standard.
I agree with most of what you are saying except for the "solely defines" bit. The culture is a powerful force but individuals are free to make choices and the language allows for these choices.
> It's the same problem with C#. Just adding alternate paradigms means nothing.
C# is still much better because it has a lot of useful DX improvements: from object initializers to IEnumerable everywhere. It keeps the tower of abstractions lower, and makes working with the tower a better experience.
Though I've only worked on microservices written in C# in .net core
Those are not Java paradigms per se - they're just practices of mediocre enterprise developers, of which Java has many, owing to being such a mainstream platform.
As for the language itself, a lot of verbosity has been culled in later language versions, with diamond operators, lambda expressions, local variable type inference, etc.
In either case, code is read more than it is written, so if a bit of verbosity makes code easier to read, I'm okay with it.
ThingDoer.doThing was often just functional programming squeezed into an object-oriented straightjacket. Java 8 added first-class functions and lambdas over a decade ago, eliminating a lot of the need to turn simple behavior into full-blown classes.
One reason for that Java style is that Java was not such a powerful language for a long time. For example lambda expressions were only introduced in Java 8 (2014) and before that developers need to work around this restriction. A common workaround were/are some annotations above of methods and some reflection magic on top. For example a life cycle callback method annotated with @PrePersist is basically the same a registering a _function_. The whole Lombok library is a massive hack to circumvent some inconveniences in Java (and in my opinion no longer needed).
I think a lot of it is the people using it and certain parts of the culture. There are a lot of Enterprise TM programmers that seem to believe as many layers of abstraction and as much verbosity as possible with little tiny methods that do practically nothing leads to better solutions. It is totally possible to write concise and pragmatic code with Java. One thing that will be a thorn in your side though is null handling. The traditional approaches increase line count and branching. The newer(ish) Optional-based null handling is quite verbose but in width.
1. Lack of first class functions till Java 8 is one reason old APIs are horrible with inheritance and reflection everywhere. You had to extend class and override methods even for simplest of tasks.
After Java 11 the code is much more succinct and functional style. But old libraries remain.
There are places where the overextensibility these libraries provide is useful. But those are few.
2. the annotation processors were late to the game - so many libraries which need to inspect object structure (such as serialization) were written with heavy use of reflection.
I will give you an example of how frameworks designed for "modern" Java look like.
Micronaut has something called Micronaut data JDBC - in which you just declare methods with few annotations eg `List<Book> queryTop10BooksByYear(int year)` and it will auto generate the JDBC + SQL code and handle injecting it into your service. The returned object can be a POJO without all the Proxy object circus ORMs come with. I haven't seen something as easy in Python yet. And all this happens in compile time with an annotation processor.
I think it doesn't have to be like that, but it's the way Java code has been written for ages, so those habits stuck. You can see it clearly when you bring a Java programmer to collaborate on a Ruby or Python codebase, if you let them, the will turn your codebase into an enterprise-ready mess with layers on top of layers of indirection in a blink.
As someone who has seen awful code in pretty much every language I've worked with, I'd blame this more on inertia and reluctance to change habits. The bad patterns that have entrenched deep into the ecosystem are very hard to shed even when the language and platform is making progress at impressive speed.
As others are saying, it's a culture not the language. C++ and even some Python etc written in the late 90s, 00s era has the same pattern-itis. It comes from slavish adherence to the Gang Of Four patterns books and an obsession with OO generally. Also the languages themselves were weak on non-OO abstractions and ways of doing code re-use, so for example it took forever for Java to get lambda expressions ... so people used one-off helper classes with "invoke" methods, etc.
As other sibling comments have said, it's cultural. Fortunately, there's some push toward functional & ADT-style modelling in the Java community and they've decided to call it "data-oriented programming" for some reason.
Eh, I don't think Java type system is strict, nor is it the root cause of this cargo cult mess. It's probably due to many enterprise programmers who think design patterns are the building blocks of everything rather than an invisible, emergent structure.
I've been trying Java recently with IntelliJ and it's been funny watching Java's evolution from the IDE's suggestions.
In Java a lot of code looks like this
void foo(Bar bar);
where Bar is an interface, and in many cases it only has one single method, so it looks like a callback that must be wrapped inside a class. Fortunately, Java lets you create anonymous classes to use these methods.
I assume because this paradigm is so common somewhere along the way Java introduced "lambdas" that look like this (I learned this from an IDE hint)
foo((Fish fish) -> false);
But what if you have a class that has Bar.baz method signature but it's called something else like fries()? Turns out you can do this (another IntelliJ hint):
foo(this::fries);
This feels like a complicated way to declare a callback, but it means that if you do implement a method with the same name, you can just pass the instance, otherwise you can use the syntax sugar, e.g.
There is a lot in Java that just feels weird, though. From the top of my head:
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.
After working with it for over 20 years, I think it's time has come and gone and that it's not the most efficient way to build enterprise applications anymore. You're lucky that Clojure program still works on the newer JVM because many of the applications I worked on, which were very large, could not be migrated to newer versions of Java. In fact, that experience repeated several times for me. I barely ever worked on anything that used the latest versions of the JVM, every place I worked was always on things like "Java 8" and crap like that. It was infuriating, but the situations were not unique at all.
We built an app in Java 8 a few years ago and are updating it for each LTS version, currently 21. Except for a few issues like the renaming of Javax packages to Jakarta it was pretty smooth so far.
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!
The Java world had plenty of student programs without Jet Brains. There is even a student-focused IDE, BlueJ, with plenty of visual representations to help people new to programming get their bearings - and this existed since 1999.
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.
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!
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.
Sure, but the same might be said of the subset of Java that existed twenty years ago; this is different from what people mean when they say "Java's good now".
I wrote a swing app a long time ago (20+ years ago) that was used in operating theaters to register organs for transplantation. Swing has saved many lives since. Swing has been good enough for a long time.
As a point of reference, JetBrains platform is on top of swing, and I'd guess that's a significant contributor to why they're able to deliver consistently across Linux, macOS, and Windows. Unlike Eclipse SWT which ships native code for all the platforms it targets
My understanding is that JetBrains puts a heroic amount of effort into making their Swing components not look terrible, and that they can do this because they're a well-resourced engineering-centric company whose main product is a GUI app whose users spend all day in it and often pay for it out of pocket. That Swing might be underrated for this use case (if you also need to ship cross-platform) is an intriguing possibility, but different from whether it's a good choice for the marginal GUI app.
It's as great as it ever was. I like it as its very stable and has a good model of interaction but if you want a modern embeddable map or embeddable chart stick with web interfaces. If you do go with swing definitely check out flatlaf to make it look modern.
I disagree. That has not been my experience whatsoever. Every company I helped, and it's been dozens, had struggles moving to a new versions of the JVM. Every single time there were major issues that required a lot of re-work and re-testing. I bailed around Java 17 or 18, but it didn't matter because NOBODY I was working with was actually even using that version! On one particularly bad project in 2022, a client had a security imperative to update the JVM from 1.5 on a major internal system and my role was to determine efficacy. I quickly found out that several key libraries had ceased support long ago around Java 1.7 and there was no path forward for those. They were simply deprecated products. My team tried getting the source code and re-compiling those 3rd party jars, with the idea of taking ownership of that code, but it was spiraling in terms of scope. They would not listen to me that even getting them to 1.7 was going to be problematic. Worse, some drive-by manager would not believe my appraisal and brought another guy to prove me wrong. It turned into this big pissing contest, which I resented. The other resource wasn't anywhere near as experienced as me, just kind of arrogant and overly confident. I decided to fire that client, which sucked because they were the tippy top of the Fortune 10. Last I heard, they had not made any progress with that upgrade and were still using it on 1.5.
Yes been there but technically this has nothing to do with Java but mis-management. The same issue could have occured in a company with Typescript or C++ for that matter. Keeping your software secure requires maintanance and requires active monitoring of 3rd party libraries and occational switching of libraries and partial rewrites. Sticking you head in the sand and hoping to keep everything running without maintenance will at some point require a full rewrite or extreme high costs to get to a product without CVE's.
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.
You haven't done it, then. Just the re-testing of everything in these large companies is terrifying and complex. Particularly the real-time stuff like Kafka. Most companies refuse to update unless absolutely necessary as they see the solution as an investment that has to produce. Security concerns have changed that attitude somewhat, but you would be surprised how much re-work is often necessary. The frustration of sorting it all out is not worth the money, imho--I'd rather just do something else, so I am.
This is such a funny workaround, I like that. But it doesn't matter in any library or your own code, since factory methods are much better (simply because they have names).
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`
I have never understood complaints about language constructs that don't make sense without an IDE. You have an IDE, it is where you are viewing the code. People that don't have an IDE are causing their own problems and should stop. People viewing the code on GitHub are not really analyzing it at the level that requires finely tracing through references usually and the terseness drastically outweighs the occasional annoyance when you are.
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".
If you would stop complaining if the IDE shipped with the compiler, then just install them at the same time and consider it "shipped with". Splitting them is for convenience and choice, not because the designers are stupid. You can handle installing two things.
(And since we're on the subject of Java, let's not forget how they used to split up JRE and JDK downloads in a very similar way.)
Having the IDE ready to go takes care of the use case of changing one variable, but you didn't need the IDE in the first place. That one's fine either way.
For the use case of making a whole new program in nano, I acknowledge and reject it. You'll be fine. Use cases that exist only out of stubbornness don't need to be catered to. You have the IDE one click away.
While I don’t agree, I do think there’s merit to the arguments you made (edit remotely, change a line and forget about it). Many anti-IDE arguments boil down to “I like a particular workflow and want to generalize it to all contexts” which is weak (you made the choice, you do the work to integrate e.g. Maven dependency awareness with your hyper customized vim environment or whatever).
However, I don’t think your arguments are sufficient to outweigh the benefits that can be obtained by making a language platform with features that assume the presence of IDE support.
> 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".
1. This is an infinitesimally small use case
2. Often those same programmers somehow are completely fine using C++ or Rust
3. Even more often those same programmers deny the usefulness of IDEs just because they need those use cases once every 10 years or so, and keep using subpar tools
C’mon, why don’t you like the authorized secure development workflow? You know, the triple-nested RDP Rube Goldberg machine that connects you to a 15yo desktop environment running on a Pentium III over a dial-up link to the moon (that can only run the IDE that time forgot, most of whose non-obsolete features don’t work because of the eighteen competing antimalware services running).
It’s ATO’d and everything, and it works for all the other contractors. They have no trouble shipping on time, give or take a decade or so; what’s your problem?
In large codebases the main problem with imports is "where that thing comes from" -- you really want explicit imports. Especially if something broke in build and you're not sure you have correct versions of dependencies (what dependency that name came from).
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.
> C# and Nim love that style, and it makes them almost unreadable without a good IDE.
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.
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.
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.
The structured part is somewhat like using for and while loops rather than goto statements - it uses block scope to make it easier to reason about how concurrent code is compartmentalized.
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.
Agreed. This is how I feel using it: https://xkcd.com/297/. It's from 2012! I hadn't even written my first `public static void main(string[] args)` then.
My favorite parts of TPL Dataflow are using Channels + Encapsulate to create custom blocks, backpressure, and parallel execution while maintaining ordering. Great library. I sometimes wonder if it would be possible/useful to implement a TPL Dataflow 2.0 on top of Channels.
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)
For us 8 to 17 was tough due to a lot of things you weren’t supposed to be using going away (sun packages). But TONS of libraries did it anyway. And the move from javax to jakarta for a lot of things in there was also tough.
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.
> For us 8 to 17 was tough due to a lot of things you weren’t supposed to be using going away (sun packages). But TONS of libraries did it anyway.
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.
The move from javax to jakarta was not really connected to the changes in the language. It is very much recommended to not do these upgrades simultaneously.
> The move from javax to jakarta was not really connected to the changes in the language.
It sort of was; it was caused by Java no longer coming with the J2EE libraries. Before that, J2EE could be considered part of Java; now that it's a separate project, they were forced to rename the packages.
Yes it was, your Java 8 code won't compile in Java 9, if using anything that was removed or blocked due to the modules changes, library and runtime are part of the language.
A programming language isn't only grammar and semantics.
The affected APIs were from packages where is is easy to tell from the name that they were not part of the standard.
These can be very useful in certain circumstances, but it should have always been clear that there is a risk they could one day be changed in an incompatible way or removed.
That code was never compatible with standard Java to begin with, therefore nobody should have been surprised. It would have never run on a JVM that didn't bother to implement the same internal APIs.
Crucially, if the OpenJDK project had removed or changed these internal APIs the result would have been all the same. But it's simply unreasonable to expect Oracle to also maintain backwards compatibility there.
For what it's worth, I had absolutely no hurdles migrating from 17 to 21 recently. Everything worked fine, the only minor issues were in upgrading Gradle at the same time (which was only tangential)
I've been away from the Java world for the past 4 years, and I really miss it. I hope I can get back to it soon.
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.
I was really surprised to find out that the support for the STR string templates that was added as a preview feature in Java 21 was completely removed in Java 23 and there is no replacement at all.
Nice to see "Vector API (Tenth Incubator)" - it should open possibility of doing low level vector maths much needed by machine learning toolkit in Java.
Whoever criticises Java in the modern world will have to answer to this: if your IDE of choice does not provide a safe « Extract method » capability, then your langage largely sucks.
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?
OpenJDK is pretty much open and straight from Oracle.
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.
Note that the previous Java LTS release license reverts to the OTN license one year after the new Java LTS version is published, making it no longer free, assuming you keep up with the security updates. See the license note on the Java 21 LTS version[1].
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.
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.
Amazon Corretto and Eclipse Temurin are developed and licensed by Oracle. They are just packaged and distributed by Amazon and IBM respectively. If you report an issue against them, the Amazon/IBM people will forward the issue to us at Oracle to resolve.
BTW, I don't dispute that Oracle is greedy, but I find the suggestion that Amazon, IBM, Google, MS etc. are any less so laughable.
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.
The first time I heard about Valhalla was 2014 (if I remember correctly), so more than a decade ago! However, I'm very happy how Java is engineered. It is really the exception that a technology is so carefully developed. Java is the technology you want for long-term stability.
Project Valhalla is too big to land in just one release. Even if all changes to surface language and the JVM land, it's just the beginning for adding new optimizations.
More new programs should be written in Java/on the JVM.
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.
Oracle makes me too uneasy. Can I use Java without the worry of incurring Oracle's wrath? Maybe, if I make sure I use openjdk/jump through some hoops I'll be fine. Or, I could just use any other language and not have that worry looming over me. C# is right there if I want a java-like experience without the anxiety of Oracle breaking my kneecaps.
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.
Just use OpenJDK (only downside is you have to upgrade every half year) or a distribution of another vendor (most people use Eclipse, or Red Hat if they already are Red Hats customers). It's really not as difficult as it is made out to be.
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.
"Am I using the correct language runtime distribution (or version thereof) so I don't get into legal trouble?" Is a question none of Java's competitors have to ask.
Even using OpenJDK is a sword of damocles waiting to fall. If I forget to update OpenJDK, Oracle could come after me. It's just risk that I don't have to worry about by choosing not to go with Java. It's probably not a lot of risk, but it's risk nonetheless that doesn't exist with Java's competitors.
Competition is so fierce in the language space and there are so many good options that java can't afford to have any friction points like this.
EDIT: I got oracle openjdk and oracle jdk mixed up. They're different things. It looks like the oracle openjdk does not have its license change, the oracle jdk does. This is a problem/risk I don't have to worry about with any other language, but getting the two mixed up is on me.
> If I forget to update OpenJDK, Oracle could come after me
I must have missed that section of the GPLv2.
Oracle does distribute a different (not OpenJDK) Java distribution under a special not-open-source no-cost license, which includes a stipulation that you can't use updates after the next LTS release. This only adds to the confusion: you really only need Oracle's special distribution if you want paid Oracle support for it or their stuff that requires it.
>Even using OpenJDK is a sword of damocles waiting to fall.
No, it really isn't. Honestly, people seem to go to great lengths of talking nonsense to discredit Java. There are many reasons to not like a language, and that is absolutely fine. But there is no point talking nonsense about it when you could just... not use it.
I was under the impression that openjdk changes licenses once a new version comes out. That's why the parent comment said "the only downside to openjdk is you have to upgrade every half year", right?
No they said that because builds of the OpenJdk codebase by the OpenJdk team are only supported for 6 months until the next version comes out.
Builds of the OpenJdk codebase by other vendors are supported for other lengths of time.
I don’t think someone can revoke your gpl licensed software you already have.
Check out 17 U.S.C. §203 and §304. I think it's possible to revoke the license after 35 years (at least in the US).
This coming from a big Oracle skeptic. None of this is true. There is no practical friction left if you're using OpenJDK. And from the parent comment, you do not need to upgrade every 6 months. Most people just work with the LTS version.
> "Am I using the correct language runtime distribution (or version thereof) so I don't get into legal trouble?" Is a question none of Java's competitors have to ask.
I am not sure this is 100% true. I think that if you download a specific binary of Anaconda (for Python), you may get into a situation where you have to pay.
For example, at Anaconda.com, one can download their distribution (their build) but the fine print says: "Use of Anaconda’s offerings at an organization of more than 200 employees/contractors requires a paid business license unless your organization is eligible for discounted or free use."
I think that PSF License is permissive and allows binary versions of Python without the maker having to release the source code.
So, downloading Anaconda as a Python distribution (build) is analogous to downloading Oracle JDK (a commercial build of OpenJDK, from Oracle).
That's because none of Java's competitors have commercial support offerings to begin with, as far as I know?
It's the same situation as with Linux. Red Hat Enterprise Linux isn't free. But it'd be weird if you said you're afraid of using Linux because the licensing is too complicated.
Lots of languages like Python, NodeJS, C++, even Perl have commercial support offerings.
> "Am I using the correct language runtime distribution (or version thereof) so I don't get into legal trouble?" Is a question none of Java's competitors have to ask.
Umm..sorry, but this is just sheer nonsense. There are many commercial Python distributions like ActiveState ActivePython, Anaconda Enterprise, etc that you need to pay for.
If you download and use their prebuilt ActivePython installer without a proper license in a commercial setting, you’re breaching a contract and will get into legal trouble.
> This is a problem/risk I don't have to worry about with any other language,
No, you most certainly DO have to worry about this in many other languages which offer commercial support offerings. (Python/C++/Perl/NodeJS,etc)
> Even using OpenJDK is a sword of damocles waiting to fall.
Just a plain, bald-faced lie.
> If I forget to update OpenJDK, Oracle could come after me.
What?
Licensing for OpenJDK is non trivial. Look at the large table and various bullet points Oracle had to make to tell you the license. https://www.oracle.com/java/technologies/javase/jdk-faqs.htm... (open the first dropdown on their FAQ page to open up their "licensing matrix")
This is a mess, and is the license going to change again while I'm locked in the java ecosystem?
Edit: It looks like the openjdk is consistently under the gplv2, I don't know why it has so many different entries in their table. I think I probably got opendjk and oracle jdk mixed up. I think the person I was replying to who said openjdk needs to be updated every half year got confused as well. It's so hard to even talk about all the different jdks without getting them mixed up or confused. Again, no other java competitors have this problem.
Licensing for OpenJDK is trivial (GPLv2+Classpath). Just like gcc/g++ and its runtime library exception.
Licensing for Oracle JDK is more complicated. This is the one where you can use it for free, but after the next LTS you either have to move to the LTS or pay for updates. There's no reason to use Oracle JDK unless you want to pay for support from Oracle, or if your applications specifically require Oracle JDK. Oracle JDK is built from the same source as OpenJDK.
https://blogs.oracle.com/java/post/free-java-license
What is even the benefit to using Oracle JDK at this point? Years ago, I saw that some jetbrains IDEs said to use it instead of openJDK, but I haven't seen anything else like that.
Oracle JDK offers LTS support with regular security patches and critical bug fixes, even for older LTS releases. (More than a decade plus, I believe, but need to check)
OpenJDK community builds usually only provide updates until the next release (6 months).
Oracle offers paid commercial support contracts: guaranteed patch timelines, 24/7 enterprise support, performance issue troubleshooting, and compliance assurance.
You can also built features atop the Oracle JDK and still get support. SAPJVM does this for instance - hot debugging as a feature.
> Licensing for OpenJDK is non trivial.
?? It is very simple. Please go to the OpenJDK site and read the below:
https://openjdk.org/legal/gplv2+ce.html
What, exactly, are the JVM's competitors (not Java, btw)? You can always use Kotlin or Scala if they take your fancy. They both interop fantastically with 20+ years of the Java ecosystem.
EDIT: The only remotely competitive ecosystem is JS/TS (because billions of pre-installs) and C#.
> Even using OpenJDK is a sword of damocles waiting to fall. If I forget to update OpenJDK, Oracle could come after me. It's just risk that I don't have to worry about by choosing not to go with Java. It's probably not a lot of risk, but it's risk nonetheless that doesn't exist with Java's competitors.
This is absurd hyperbole.
> only downside is you have to upgrade every half year
LTS OpenJDK distributions from eg Eclipse (17, 21 etc) stick around for longer[1]. Heck, you can still get updates for JDK 11 and even 8.
You do have to update the runtime for security and other fixes, but that’s true for other languages too.
[1] https://adoptium.net/support
All that just seems like friction when there are frictionless alternatives available. Life's too short for friction.
Can you explain what the friction is ? If you download and install the ActiveState Python distribution in a commercial setting and accept the license agreement without reading and get sued legally at a later point, will you say Python has too much friction ?
Just go to https://openjdk.org/ and click "Download". Or say `brew install openjdk` (macOS) / `apt install openjdk` (linux).
ZERO friction.
There is no friction. Don't use commercial products if you don't want to pay for them. End of story.
You usually have to explictly opt-in to installing an Oracle JDK because... you know, they have a license agreement that you must agree to.
So there's no friction, everyone uses the OSS ones unless you have very specific needs.
> Oracle makes me too uneasy. Can I use Java without the worry of incurring Oracle's wrath?
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.
> C# is right there if I want a java-like experience without the anxiety of Oracle breaking my kneecaps.
Is Microsoft really better than Oracle in that regard?
If we look at .NET vs Java, then yes, Microsoft is better. Microsoft may charge for some of its dev tools (Visual Studio etc), but .NET itself is and was always totally free.
I don't think "was always" is an accurate statement
However, above and beyond free, it is also a collection of ECMA standards https://learn.microsoft.com/en-us/dotnet/fundamentals/standa...
Now, don't get me wrong: I have grave suspicions there is currently only one actual implementation of them (I don't count hobby, or abandonware, ones) but IMHO "actual standard" combined with "for real reference implementation" is way better than just reference implementation
---
since I'm still within the edit window, the MAUI referenced by the sibling comment is MIT licensed https://github.com/dotnet/maui
https://github.com/dotnet/blazor (Apache 2) is marked an archived, and points to https://github.com/dotnet/aspnetcore (MIT) but command-f blazor on its readme is nothing so :shrug:
> I don't think "was always" is an accurate statement
If we want to be really pedantic they said ".NET" and not ".NET Framework" or ".NET Core", so basically that what came with .NET 5 and newer.
The very idea of those 3 things being disjoint is a supremely Microsoftian thing to do and makes discussions horrific
And .NET is truly cross-platform for 11 years already (since .NET Core 3.0 was released). No licensing/patent/litigation issues since then.
Great GUI cross-platform GUI toolkit (MAUI), great WASM engine (Blazor).
Upcoming .NET 10 is going to be awesome.
Isn't the official MAUI still basically "everything but Linux"? I haven't been keeping up with that the last 2 or so years and I just remember there being an unofficial GTK implementation somewhere in the interwebs, but nothing being officially supported on Linux.
Linux desktop has a tiny market share. No reason to invest significant resources for that. Also, by supporting MAUI on Linux, Microsoft would feed their own competition in desktop area, and it's crucial for them to maintain dominance in that area. I think this is why they did not port the great WPF to Linux as well.
And besides, Linux desktop is a mess. I never learned details on how Wayland / X11 / KDE / Gnome etc. work, which is for what. All I know is that some distros switch from one to another, that one is declared the best, and another the worst, and all of it changes regularly. I'm glad someone in Canonical made the desktop mostly working for me in Ubuntu, although it still lacks a lot compared to Windows.
I think when you need that level of cross platform support to cover Windows, Linux, macOS, maybe mobiles, and you do a serious project, you use Qt.
Depends. If you were there during the Steve Ballmer time then you know that Microsoft will absolutely betray you on almost every dev tech they roll out.
Otherwise C# and .NET have had a pretty solid track record.
You don't have to jump through any hoops. If you don't want to deal with Oracle, don't be an enterprise customer of Oracle and instead just get some openjdk distribution.
> just get some openjdk distribution
From several sources:
- Oracle themselves, at jdk.java.net - Microsoft, at microsoft.com/openjdk - Red Hat ... - Azul Systems ... - Amazon - Bell Soft - Canonical (Ubuntu ships OpenJDK binaries built by them) - build yourself?
Just go to https://openjdk.org/ and click on the "download" link.
Or use your OS package manager and <pkgManager> install openjdk. Problem solved.
Just like any other software, you know ?
That download link takes you to jdk.java.net, which hosts OpenJDK builds built by Oracle.
[dead]
My semi-conspiracy theory is that the success of Rust is partially due to BigTech companies searching for a "legally-safe" alternative to Java.
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.
I'm not sure where things fall on your timeline, but in case you missed it, Amazon has their own Java distribution called Corretto. It was first publicly released in 2018:
https://downloads.corretto.aws/#/overview
This conspiracy theory would explain not only success of Rust, but also Go language and C#/.NET, and any other Java competitor.
I'd say it's 90% because of Oracle and its lawyer-driven business, and 10% because the language is just ugly, and existing libraries are super-ugly and unreadable, with all these Factories and AbstractFactories, and all design patterns forced like a religion whether they're useful or not in a specific context.
Java is hugely popular and widely used on large backend systems. I guess a lot of people here don't work on such systems? I'm always surprised when I see comments like the parent, since in my career exposure to Java is near-ubiquitous.
There has been a move in the past 8 years away from Java on the back end, notably to Go, by several large engineering organizations, which made the move, "motivated" by the example of companies like Google or by projects like Kubernetes, and seduced by the promises of a language simple to learn, build, and deploy.
> seduced by the promises of a language simple to learn, build, and deploy
That's actually quite correct and I'm saying this as someone that does Java on daily basis. Go is in fact superior in terms of deployment. I would rather deploy a Go-written service than a Spring Boot one. That being said, I love using Java for monoliths - large code bases crammed with business logic. I personally don't see Go doing very well in that direction.
Why is it so ? Is go specifically lacking somewhere ?
Businesses often deal with old databases, message queues, SOAP services, legacy systems. Java has a truckload of well-established connectors (Even more than Python!), well-supported JDBC drivers, and vendor-supported SDKs.
Also features like transaction management, dependency injection, validation frameworks, AOP-style cross-cutting concerns are better addressed in Java.
Java has collection streams with great customizability (filter/map/reduce/etc). Far better writing your 10,000th for-loop in Go. You can also get automatic parallel streams without writing any extra code.
Go's profiling tools (esp memory) are very primitive, sorry. JVM profiling tools beat Go's by orders of magnitude. So does the other tooling - GC tuning, monitoring, etc. Java flight recorder and VisualVM are gorgeous.
That said, Go is still better at memory efficient, tight network software like lean k8s controllers. Though frankly, Rust is encroaching into this space.
I'm not them, but there are few things better for operational insight than the JVM. It has a boatload of tuneables, it has a very rich dynamic code load mechanism (Reflection, ClassLoaders, the new Modules system, and it used to have a strong sandboxing system but they killed that), and at the intersection of those two things is JMX, which is dynamically tuneable deployments via API. It's like having JVM-local feature-flags that one can twiddle without needing to bring down the JVM
And sure, it's not everyone's cup of tea, and/or plenty of people will chime in with "yes, but"s to defend golang or every other platform that isn't the JVM. I'm not yucking your yum! I'm just saying for me, the JVM is the bees knees
What deployment challenges have you had with Java / spring boot apps? It has been totally smooth sailing for me.
Creators of Go within Google conveniently left out the fact that within Google there's still far more Java code than Go code.
Go is slowly becoming Java 1.5+ -- see the addition of generics.
Btw, you can AOT compile Java if you wish... it'll probably be a larger binary than a Go binary, but that's whatever...
[Meta] ... God, I'm turning in pjlmp here, lol
> by several large engineering organizations, which made the move
The problem with this type of trend is it's often hype and you never know what actually happens or how does it evolve over time.
I've seen organizations make certain announcements, switch maybe 5%, give up and go in different directions, but only the initial announcement ever hit the news.
> and seduced by the promises of a language simple to learn, build, and deploy
It's always simple if you rip it all up. Nice and shiny toys are always great.
I suppose we are talking about user-facing desktop software.
Most of the largest cloud was built on Java....
I think the rise of containers and being able to compile and run natively has eliminated the argument that would favor the JVM. It's so easy to fully control your dev and deployment environments now using Docker images and to me, that's a far better solution. tl;dr -- containers eliminate Java long term.
> tl;dr -- containers eliminate Java long term
Why can't they co-exist?
> has eliminated the argument that would favor the JVM
This complaint is taking technology definitions too literally. I doubt new adopters of Java or the JVM are really going on about that now. It's more been about the ecosystem, the maturity, etc.
I'm secretly hoping that Kotlin and Compose will bring back Desktop apps on the JVM :-).
I'm rooting against Kotlin since it appears to be only usable with the JetBrains ide. I'm totally blind and Jetbrains tools are not nearly as accessible or easy to use as VS Code with all the Java extensions in my experience. At all the jobs I've had no one cared if I didn't use Idea, but considering it looks like there's no good VS Code tooling for Kotlin if I have to use Kotlin professionally it's going to be painful.
Oh I didn't know about that. Is JetBrains improving on accessibility, at least, or not really?
What's unexpected about that observation is that they have actually completely separated the presentation layer from the business logic because such a thing was required to have "Code with Me" and their "projector" project wherein one could use IJ from a browser https://jetbrains.github.io/projector-client/mkdocs/latest/a...
But, I am fully talking out of school because I don't know what the actual, no kidding, accessibility hurdles one faces when trying to do work in such a setup, nor what concessions VS Code has made to fix those problems
But I do know that YouTrack has a dedicated categorization for accessibility reports and I am sure they would welcome hearing about how they could win back those audiences https://youtrack.jetbrains.com/issues?q=%23%7BUI.%20Accessib...
My major issue is that the IDE doesn't use the same hotkeys or similar interface to VS Code. This isn't necessarily a problem, but the fact that it's so different means the learning curve is absolutely brutal so it's not worth the effort for me to look at it. If there was a basic getting started tutorial that walked you through building a simple program, finding and fixing compilation errors, performing basic debugging etc, that was written from the perspective of a screen reader user that would be incredibly helpful. Something like this may exist, but if it does I haven't found it.
As of somewhat recently, Kotlin has a language server: https://github.com/Kotlin/kotlin-lsp
Using it in vscode, while not perfect yet, is starting to be alright.
Thanks, I've starred the project so I can keep up with it. I don't currently have any plans to do anything with Kotlin but will look at this if I do in the future.
I write desktop app on JavaFX (one Kotlin one pure Java). I don't see any problems why we should wait, it's production ready
I mean, I agree that it is really good! I'm just hoping that it will come in fashion, versus those ElectronJS... things.
Java's biggest risk towards continued adoption, by far, is the culture surrounding it - old Java programmers and old Java programs continue to be needlessly verbose, even if the language now has the tools (pretty much) to be as terse as other popular, modern languages.
It's an uphill battle, but it might just climb the hill because it's still such a behemoth.
It all failed when .stream() appeared. Why make people use .stream() for functional programming, plus streams aren’t even reusable, I almost wish they invented a new operator based on an exotic UTF-8 character than those 9 extra characters. Fonts should have a ligature for .stream().
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.
Nobody complains about the Rust turbo-fish operator which is pretty verbose too. Java has already has introduced a direct toList()/toArray() anyways.
starting with JDK 16, Stream has .toList() that will save you ten characters for the .collect()
It's very difficult for a language designer to satisify the aesthetes.
> I can come back to a Clojure program I wrote ten years ago and it runs great
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.
It's not clear whether the author built the Clojure program into a jar or not. If so, it would be thanks to the JVM.
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.
i think this is because of Clojure's mentality on backwards compatibility and not the JVM specifically. please someone correct me if im wrong tho!
I feel there's much more to it. There are so many pieces in Clojure that just feel like they're done right. Even after a decade of using it, I remain happy. Not a single other language (and I tried more than a few) has kept me happy for so long.
Java has the same problem most imperative languages do, which is the lack of clear separation between mutable and immutable state, rigorously enforced by tooling. Many large-scale Java programs try and work around this by using immutable collections, which certainly makes a difference but can only go so far.
Java has the additional issue of being object-oriented, which leads to spaghetti parent-child relationships under stress.
Valhalla should be able to address this to some extent with immutable value classes.
My biggest Issue with Java, is that it isn't streamlined. There are multiple implementations of the jdk that could be used, Many different build systems, etc. The C# ecosystem is smaller for sure, but it is much more streamlined
The different JDK builds are almost all built from OpenJDK. Maven and Gradle cover nearly all use cases. The complexity is not that high.
I think it is quite high, especially for newcomers to the ecosystem. The popular sdkman CLI tool for managing JDK installations provides 17 different JDKs to install:
https://sdkman.io/jdks/
With the DotNet SDK for comparisons sake, there is but one provider, and package management is provided as first class citizen in the compiler CLI, removing the need to even pick a "gradle" or "maven" style build tool in the first place for almost any project.
At the very top of the page it mentions a default which kind of negates that issue...
It doesn’t negate the issue at all, especially as sdkman is an optional extra tool. If working with others, that default is not always going to be the one your team develops against either. If you are just trying to pick a jdk and don’t even know sdkman exists, a sensible person will rightly wonder why the ecosystem has fractured into 17 JDKs, or you won’t notice at all and blindly pick a download from the oracle website. I’ve seen it cause confusion many times for new (and old!) Java developers.
Checking a new developer has actually managed to install the correct JDK for a given project is still a thing I have to do, all the time.
Sdkmans docs also have no bearing on the multiple build systems in the java world too, which again simply a non-issue in DotNet and many others.
I think Java is the best language for most medium to large projects or anything that requires threading or complicated/optimized IO
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 over 20 years working with Java, I'd much prefer working on Python for lots of reasons, but a big one is that the kinds of projects that involve Java are always involve the same stupid politics and organizational struggles. I've noticed that projects involving Python are way more enjoyable with less friction, likely due to the organizations themselves being more open-minded and maybe younger. I don't know. At some point, every Java project at every Fortune 500 company I worked with was the same damn hellish mess and I had to get away from that.
> I think Java is the best language for most medium to large projects
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.
In the circles I see, Java isn't popular because it's verbose and boring to use.
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.
> it's verbose and boring to use.
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?
Well, there are lots of people out there who view "Pythonic" as a euphemism for awful tbh. Throughout my career I've seen multiple large Python codebases be rewritten in Java after they turned into a mess, including - perhaps most embarrassingly - Google's internal code review tool Mondrian, which was written by Guido van Rossum himself.
One reason Java codebases feel more abstract is that they're attempting to solve problems that the scripting worlds tend to just punt on, or handle in ways that don't scale well. And because Java's type system is nominal, solutions to those problems require names.
For example, a lot of the abstraction in Java codebases is to make things deeply testable. That's what drives dependency injection, which is where a lot of BeanFactory stuff comes from. What's the Python solution to that problem? Often they just hardly have tests by the standard of Java developers! This is why Python is big in ML research where codebases are often small disposable experiments, and why after a brief era where Django was popular it sort of died off in the wider server / big data space.
Another source of complexity and abstraction is a focus on pluggable ecosystems. Databases are abstracted by JDBC, and then again by an ORM, which then might be abstracted again by Micronaut or Spring, and at each layer there are multiple competing implementations available which implement standard APIs. This kind of thing happens much less in the scripting world. The downside is that scripting codebases are far more locked-in to their choice of libraries. Porting a Java codebase from one database or ORM to another is hugely easier, because the core APIs are all standardized.
It's a culture, not language thing. Here is a JSON parser implementation (part of PlantUML) that lacks endless levels of abstraction.
https://github.com/plantuml/plantuml/blob/master/src/main/ja...
I'd argue culture solely defines the language.
Is there a full library ecosystem of stuff written like the json parser you shared, which is as complete as the enterprisey library ecosystem? Similarly, SO answers? LLM output? Tutorials? YouTube videos?
I think the answer is no.
It's the same problem with C#. Just adding alternate paradigms means nothing. The only thing that matters is how a majority of code in the ecosystem is structured. In java, that's enterprisey code. Most code is glue code, so you're forced into the majority pattern, lest you want to write endless wrappers...
On the other hand, while typescript supports a lot of the enterprisey nonsense similar to C#, the majority of the ecosystem is written with simple functions, callbacks and options objects. Not in an enterprisey way. I don't need to use decorators to use zod.
People that eschew enterprisey code and prefer simple code can't switch to java or c# until the whole culture changes, regardless of the kitchen sink of features either language adds.
>> On the other hand, while typescript supports a lot of the enterprisey nonsense similar to C#, the majority of the ecosystem is written with simple functions, callbacks and options objects. Not in an enterprisey way.
Going back to culture, who makes up the Typescript community? While C# devs are attracted to it there are many multiples more devs coming from a JavaScript background. This has a big impact on how the culture developed.
Taking a step back. C# devs often need to do frontend work. They could go with what the industry has settled on, React, or go another way. The bulk go with react and some perhaps lament still have to switch their brain to another mode for that work. Frontend is obviously more fragmented, but the scale prevents C# devs from influencing patterns to the extent that they do on the backend.
I'd argue similar for Java devs when it comes to frontend. In the case of Blazor, I think C# patterns are a much smaller factor in decision-making. In fact, lots of C# adherents would default to React given it's the industry standard.
I agree with most of what you are saying except for the "solely defines" bit. The culture is a powerful force but individuals are free to make choices and the language allows for these choices.
Spot on. You can't separate a language from the speakers of it. You can't redo millions of hours of work put into an ecosystem.
> It's the same problem with C#. Just adding alternate paradigms means nothing.
C# is still much better because it has a lot of useful DX improvements: from object initializers to IEnumerable everywhere. It keeps the tower of abstractions lower, and makes working with the tower a better experience.
Though I've only worked on microservices written in C# in .net core
Those are not Java paradigms per se - they're just practices of mediocre enterprise developers, of which Java has many, owing to being such a mainstream platform.
As for the language itself, a lot of verbosity has been culled in later language versions, with diamond operators, lambda expressions, local variable type inference, etc.
In either case, code is read more than it is written, so if a bit of verbosity makes code easier to read, I'm okay with it.
ThingDoer.doThing was often just functional programming squeezed into an object-oriented straightjacket. Java 8 added first-class functions and lambdas over a decade ago, eliminating a lot of the need to turn simple behavior into full-blown classes.
One reason for that Java style is that Java was not such a powerful language for a long time. For example lambda expressions were only introduced in Java 8 (2014) and before that developers need to work around this restriction. A common workaround were/are some annotations above of methods and some reflection magic on top. For example a life cycle callback method annotated with @PrePersist is basically the same a registering a _function_. The whole Lombok library is a massive hack to circumvent some inconveniences in Java (and in my opinion no longer needed).
I think a lot of it is the people using it and certain parts of the culture. There are a lot of Enterprise TM programmers that seem to believe as many layers of abstraction and as much verbosity as possible with little tiny methods that do practically nothing leads to better solutions. It is totally possible to write concise and pragmatic code with Java. One thing that will be a thorn in your side though is null handling. The traditional approaches increase line count and branching. The newer(ish) Optional-based null handling is quite verbose but in width.
In my opinion at this point null handling is the one remaining thing about Java that is genuinely bad technically
I haven't seen a NPE in the wild for years. We use NullAway in our build - works great.
> by-product of Java's strict type system
1. Lack of first class functions till Java 8 is one reason old APIs are horrible with inheritance and reflection everywhere. You had to extend class and override methods even for simplest of tasks.
After Java 11 the code is much more succinct and functional style. But old libraries remain.
There are places where the overextensibility these libraries provide is useful. But those are few.
2. the annotation processors were late to the game - so many libraries which need to inspect object structure (such as serialization) were written with heavy use of reflection.
I will give you an example of how frameworks designed for "modern" Java look like.
Micronaut has something called Micronaut data JDBC - in which you just declare methods with few annotations eg `List<Book> queryTop10BooksByYear(int year)` and it will auto generate the JDBC + SQL code and handle injecting it into your service. The returned object can be a POJO without all the Proxy object circus ORMs come with. I haven't seen something as easy in Python yet. And all this happens in compile time with an annotation processor.
I think it doesn't have to be like that, but it's the way Java code has been written for ages, so those habits stuck. You can see it clearly when you bring a Java programmer to collaborate on a Ruby or Python codebase, if you let them, the will turn your codebase into an enterprise-ready mess with layers on top of layers of indirection in a blink.
As someone who has seen awful code in pretty much every language I've worked with, I'd blame this more on inertia and reluctance to change habits. The bad patterns that have entrenched deep into the ecosystem are very hard to shed even when the language and platform is making progress at impressive speed.
As others are saying, it's a culture not the language. C++ and even some Python etc written in the late 90s, 00s era has the same pattern-itis. It comes from slavish adherence to the Gang Of Four patterns books and an obsession with OO generally. Also the languages themselves were weak on non-OO abstractions and ways of doing code re-use, so for example it took forever for Java to get lambda expressions ... so people used one-off helper classes with "invoke" methods, etc.
As other sibling comments have said, it's cultural. Fortunately, there's some push toward functional & ADT-style modelling in the Java community and they've decided to call it "data-oriented programming" for some reason.
Eh, I don't think Java type system is strict, nor is it the root cause of this cargo cult mess. It's probably due to many enterprise programmers who think design patterns are the building blocks of everything rather than an invisible, emergent structure.
It is probably more related to people replacing multithreaded services with single-threaded workers.
I've been trying Java recently with IntelliJ and it's been funny watching Java's evolution from the IDE's suggestions.
In Java a lot of code looks like this
where Bar is an interface, and in many cases it only has one single method, so it looks like a callback that must be wrapped inside a class. Fortunately, Java lets you create anonymous classes to use these methods. I assume because this paradigm is so common somewhere along the way Java introduced "lambdas" that look like this (I learned this from an IDE hint) But what if you have a class that has Bar.baz method signature but it's called something else like fries()? Turns out you can do this (another IntelliJ hint): This feels like a complicated way to declare a callback, but it means that if you do implement a method with the same name, you can just pass the instance, otherwise you can use the syntax sugar, e.g. There is a lot in Java that just feels weird, though. From the top of my head: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.
Java is really fast: https://github.com/gunnarmorling/1brc
2 yes, although if you are splitting only one regular character the implementation doesn't use a Regen internally
3 is not an issue anymore since java 22 https://blog.jetbrains.com/idea/2024/02/constructor-makeover...
Doesn't java now let you have both private methods in interfaces and default implementations of the interface methods?
[dead]
After working with it for over 20 years, I think it's time has come and gone and that it's not the most efficient way to build enterprise applications anymore. You're lucky that Clojure program still works on the newer JVM because many of the applications I worked on, which were very large, could not be migrated to newer versions of Java. In fact, that experience repeated several times for me. I barely ever worked on anything that used the latest versions of the JVM, every place I worked was always on things like "Java 8" and crap like that. It was infuriating, but the situations were not unique at all.
We built an app in Java 8 a few years ago and are updating it for each LTS version, currently 21. Except for a few issues like the renaming of Javax packages to Jakarta it was pretty smooth so far.
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!
I wonder where Java would be today without superb tooling and smart student programs from JetBrains.
Java has enjoyed powerful IDEs since late 1990's, some of them are even free beer!
The Java world had plenty of student programs without Jet Brains. There is even a student-focused IDE, BlueJ, with plenty of visual representations to help people new to programming get their bearings - and this existed since 1999.
Sadly BlueJ teaches people almost exactly the wrong things about object-oriented programming.
Java was thriving during the golden age of Eclipse Foundation and IDE. JetBrains is very much recent.
> JetBrains is very much recent.
JetBrains is 25 years old, almost as old as Java.
IntelliJ use wasn't that widespread until about 10-15 years ago. Java was thriving before that.
It was in heavy use in London investment banks in 2005. Even resharper was commonplace by the following year.
Around 10 years ago Eclipse was still the primary editor in the circles I was in.
Still is on my circles, and at home I have been always a Netbeans fan.
I am an IDE guy since Borland products for MS-DOS, yet I was never sold on InteliJ anyway, and Android Studio made me dislike it even further.
I was using Eclipse back then, but indeed Wikipedia says IDEA 1.0 (Jan 2001) predates Eclipse IDE (Nov 2001).
NetBeans was bought by Sun in 1999 and opensourced on Jun 2000.
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.
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!
Is Swing good now? Usually when people say Java is good now I assume they're not talking about Swing.
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.
Sure, but the same might be said of the subset of Java that existed twenty years ago; this is different from what people mean when they say "Java's good now".
I wrote a swing app a long time ago (20+ years ago) that was used in operating theaters to register organs for transplantation. Swing has saved many lives since. Swing has been good enough for a long time.
As a point of reference, JetBrains platform is on top of swing, and I'd guess that's a significant contributor to why they're able to deliver consistently across Linux, macOS, and Windows. Unlike Eclipse SWT which ships native code for all the platforms it targets
My understanding is that JetBrains puts a heroic amount of effort into making their Swing components not look terrible, and that they can do this because they're a well-resourced engineering-centric company whose main product is a GUI app whose users spend all day in it and often pay for it out of pocket. That Swing might be underrated for this use case (if you also need to ship cross-platform) is an intriguing possibility, but different from whether it's a good choice for the marginal GUI app.
It's as great as it ever was. I like it as its very stable and has a good model of interaction but if you want a modern embeddable map or embeddable chart stick with web interfaces. If you do go with swing definitely check out flatlaf to make it look modern.
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
Swing is standard part of JDK, there is nothing deprecated, it even got a Metal backend.
Awesome, thank you, that is great to hear
ive tried javafx but its always easier to me to go back to swing, if it aint broke dont fix it.
Your neighbor's dog barks at Swing.
The JVM and its ecosystem can be used from other languages too like Scala which has all the sexy stuff, also clojure et al
And Kotlin!
I disagree. That has not been my experience whatsoever. Every company I helped, and it's been dozens, had struggles moving to a new versions of the JVM. Every single time there were major issues that required a lot of re-work and re-testing. I bailed around Java 17 or 18, but it didn't matter because NOBODY I was working with was actually even using that version! On one particularly bad project in 2022, a client had a security imperative to update the JVM from 1.5 on a major internal system and my role was to determine efficacy. I quickly found out that several key libraries had ceased support long ago around Java 1.7 and there was no path forward for those. They were simply deprecated products. My team tried getting the source code and re-compiling those 3rd party jars, with the idea of taking ownership of that code, but it was spiraling in terms of scope. They would not listen to me that even getting them to 1.7 was going to be problematic. Worse, some drive-by manager would not believe my appraisal and brought another guy to prove me wrong. It turned into this big pissing contest, which I resented. The other resource wasn't anywhere near as experienced as me, just kind of arrogant and overly confident. I decided to fire that client, which sucked because they were the tippy top of the Fortune 10. Last I heard, they had not made any progress with that upgrade and were still using it on 1.5.
Yes been there but technically this has nothing to do with Java but mis-management. The same issue could have occured in a company with Typescript or C++ for that matter. Keeping your software secure requires maintanance and requires active monitoring of 3rd party libraries and occational switching of libraries and partial rewrites. Sticking you head in the sand and hoping to keep everything running without maintenance will at some point require a full rewrite or extreme high costs to get to a product without CVE's.
This must be satire
New Features: https://openjdk.org/projects/jdk/25/
Java 25 is an LTS release.
Can't wait to have a job migrating an application from 17 to java 25 in 10 years!
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.
You haven't done it, then. Just the re-testing of everything in these large companies is terrifying and complex. Particularly the real-time stuff like Kafka. Most companies refuse to update unless absolutely necessary as they see the solution as an investment that has to produce. Security concerns have changed that attitude somewhat, but you would be surprised how much re-work is often necessary. The frustration of sorting it all out is not worth the money, imho--I'd rather just do something else, so I am.
Except he didn’t say “for ten years” but “in ten years” referring to the extreme length of time companies take to upgrade
He meant "10 years from now" when the company absolutely must get off of 17.
Already doing the work to move my team to 25 and it's been out for a day.
I'm doing that in 2 weeks. The next major version of our product will require 25.
edit: I wrote "require" when I meant "ship with". We ship a Temurin JRE together with our product, so it's being updated with each new installation.
Nice! It really isn’t hard to stay on top of it imo. The only thing stopping anyone from upgrading is their own company culture at this point.
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.
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.
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.
This is such a funny workaround, I like that. But it doesn't matter in any library or your own code, since factory methods are much better (simply because they have names).
Wasn't that possible since java 22?
> Wasn't that possible since java 22?
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).
(not a Java developer, no dog in this fight)
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`
I have never understood complaints about language constructs that don't make sense without an IDE. You have an IDE, it is where you are viewing the code. People that don't have an IDE are causing their own problems and should stop. People viewing the code on GitHub are not really analyzing it at the level that requires finely tracing through references usually and the terseness drastically outweighs the occasional annoyance when you are.
> You have an IDE
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".
If you would stop complaining if the IDE shipped with the compiler, then just install them at the same time and consider it "shipped with". Splitting them is for convenience and choice, not because the designers are stupid. You can handle installing two things.
(And since we're on the subject of Java, let's not forget how they used to split up JRE and JDK downloads in a very similar way.)
Having the IDE ready to go takes care of the use case of changing one variable, but you didn't need the IDE in the first place. That one's fine either way.
For the use case of making a whole new program in nano, I acknowledge and reject it. You'll be fine. Use cases that exist only out of stubbornness don't need to be catered to. You have the IDE one click away.
While I don’t agree, I do think there’s merit to the arguments you made (edit remotely, change a line and forget about it). Many anti-IDE arguments boil down to “I like a particular workflow and want to generalize it to all contexts” which is weak (you made the choice, you do the work to integrate e.g. Maven dependency awareness with your hyper customized vim environment or whatever).
However, I don’t think your arguments are sufficient to outweigh the benefits that can be obtained by making a language platform with features that assume the presence of IDE support.
Either way, I’m just one person, so you do you.
> 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".
1. This is an infinitesimally small use case
2. Often those same programmers somehow are completely fine using C++ or Rust
3. Even more often those same programmers deny the usefulness of IDEs just because they need those use cases once every 10 years or so, and keep using subpar tools
Bro hasn't been employed at any natsec-level project to even _try_ to suggest the first option.
C’mon, why don’t you like the authorized secure development workflow? You know, the triple-nested RDP Rube Goldberg machine that connects you to a 15yo desktop environment running on a Pentium III over a dial-up link to the moon (that can only run the IDE that time forgot, most of whose non-obsolete features don’t work because of the eighteen competing antimalware services running).
It’s ATO’d and everything, and it works for all the other contractors. They have no trouble shipping on time, give or take a decade or so; what’s your problem?
In large codebases the main problem with imports is "where that thing comes from" -- you really want explicit imports. Especially if something broke in build and you're not sure you have correct versions of dependencies (what dependency that name came from).
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.
> C# and Nim love that style, and it makes them almost unreadable without a good IDE.
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...
There is Jetbrains Rider.
Now available to even more audiences than before https://www.jetbrains.com/rider/#:~:text=free%20for%20non-co...
AFAIK it's mostly intended to make writing single source file programs easier.
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.
C# supports the "using alias" like this:
https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...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.
Much better this way with previews, than the mess C++ is having nowadays with standardising features without implementations.
I hope structured concurrency ends up feeling better than async/await with less sugar. The examples do not instill confidence, but we shall see.
The structured part is somewhat like using for and while loops rather than goto statements - it uses block scope to make it easier to reason about how concurrent code is compartmentalized.
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.
Unfortunately on .NET side, TPL Dataflow doesn't get enough love.
They added an async Channel and its actually pretty nice to work with, at least.
Agreed. This is how I feel using it: https://xkcd.com/297/. It's from 2012! I hadn't even written my first `public static void main(string[] args)` then.
My favorite parts of TPL Dataflow are using Channels + Encapsulate to create custom blocks, backpressure, and parallel execution while maintaining ordering. Great library. I sometimes wonder if it would be possible/useful to implement a TPL Dataflow 2.0 on top of Channels.
It looks like a far smarter approach than async/await
I would be shocked if they came up with something that made me want to move away from ZIO.
My feeling (which is worth what it is worth) is that Java as an old language has been improving over the last 10 years, whereas C++ has gotten worse.
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)
For us 8 to 17 was tough due to a lot of things you weren’t supposed to be using going away (sun packages). But TONS of libraries did it anyway. And the move from javax to jakarta for a lot of things in there was also tough.
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.
> For us 8 to 17 was tough due to a lot of things you weren’t supposed to be using going away (sun packages). But TONS of libraries did it anyway.
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.
The move from javax to jakarta was not really connected to the changes in the language. It is very much recommended to not do these upgrades simultaneously.
Right. It was a copyright issue, I know.
We didn’t do that one giant jump. We moved from 8 to 17 in one step, then in a separate step upgraded Tomcat requiring the jakarta changes later.
I guess I tend to think of them as one “modernizing“ combo even though they’re not.
Indeed, exactly the same process we did.
> The move from javax to jakarta was not really connected to the changes in the language.
It sort of was; it was caused by Java no longer coming with the J2EE libraries. Before that, J2EE could be considered part of Java; now that it's a separate project, they were forced to rename the packages.
The JDK didn't come with these packages anymore. They were never part of core Java.
Yeah, Java 9 was the Python 3 moment of the ecosystem, however it has been sorted out for ages.
Not comparable; Python 3 changed the source language. While for most programs complying with standard Java nothing had to be changed at all.
Yes it was, your Java 8 code won't compile in Java 9, if using anything that was removed or blocked due to the modules changes, library and runtime are part of the language.
A programming language isn't only grammar and semantics.
The affected APIs were from packages where is is easy to tell from the name that they were not part of the standard.
These can be very useful in certain circumstances, but it should have always been clear that there is a risk they could one day be changed in an incompatible way or removed.
Does not change the fact that existing code, or existing JARs could not run any longer, and had to be rewriten.
When code breaks, the user doesn't care about the details of the root cause, it stays broken.
That code was never compatible with standard Java to begin with, therefore nobody should have been surprised. It would have never run on a JVM that didn't bother to implement the same internal APIs.
Crucially, if the OpenJDK project had removed or changed these internal APIs the result would have been all the same. But it's simply unreasonable to expect Oracle to also maintain backwards compatibility there.
For what it's worth, I had absolutely no hurdles migrating from 17 to 21 recently. Everything worked fine, the only minor issues were in upgrading Gradle at the same time (which was only tangential)
Best of luck to you.
Nice overview of new features in Java 25: https://www.baeldung.com/java-25-features
I've been away from the Java world for the past 4 years, and I really miss it. I hope I can get back to it soon.
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.
I was really surprised to find out that the support for the STR string templates that was added as a preview feature in Java 21 was completely removed in Java 23 and there is no replacement at all.
Nice to see "Vector API (Tenth Incubator)" - it should open possibility of doing low level vector maths much needed by machine learning toolkit in Java.
It's not that new though. It will probably only be frozen once value types arrive.
Whoever criticises Java in the modern world will have to answer to this: if your IDE of choice does not provide a safe « Extract method » capability, then your langage largely sucks.
> if your IDE of choice does not provide a safe « Extract method » capability, then your langage largely sucks.
Why is that a language problem as opposed to an IDE problem?
When it’s Ruby or another language that uses metaprogramming to the point of complete obscurity to tools and humans.
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?
OpenJDK is pretty much open and straight from Oracle.
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.
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.
Note that the previous Java LTS release license reverts to the OTN license one year after the new Java LTS version is published, making it no longer free, assuming you keep up with the security updates. See the license note on the Java 21 LTS version[1].
[1] https://www.oracle.com/uk/java/technologies/downloads/#java2...
There is literally 0 worry. OpenJDK is fully open source.
Truffle is not part of OpenJDK. It's a separate project and licensed under the Universal Permissive License: https://github.com/oracle/graal/tree/master/truffle.
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.
Use OpenJDK (or similar) and you are free from any Oracle shenanigans.
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.
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...
> 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.
Amazon Corretto and Eclipse Temurin are developed and licensed by Oracle. They are just packaged and distributed by Amazon and IBM respectively. If you report an issue against them, the Amazon/IBM people will forward the issue to us at Oracle to resolve.
BTW, I don't dispute that Oracle is greedy, but I find the suggestion that Amazon, IBM, Google, MS etc. are any less so laughable.
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.
It's only a consideration if you are going to write your own Java implementation and distribute it.
i think its time for some of the enterprise customers to maybe consider upgrading to java9?
It's a damn shame that project Valhalla still isn't finished. This would fix so much and open up java for better matrix math support
The first time I heard about Valhalla was 2014 (if I remember correctly), so more than a decade ago! However, I'm very happy how Java is engineered. It is really the exception that a technology is so carefully developed. Java is the technology you want for long-term stability.
Project Valhalla is too big to land in just one release. Even if all changes to surface language and the JVM land, it's just the beginning for adding new optimizations.
It was submitted recently 2 weeks ago hence we might see something in future releases too.
what's the state of graalpy these days?
"The GraalVM team are transitioning to focus on non-Java Graal Languages including GraalPy and GraalJS. Details are expected to be announced later."
Taken from: https://blogs.oracle.com/java/post/detaching-graalvm-from-th...
Does it have reified generics yet?
i think some of the enterprise users should maybe consider upgrading to java9?
No, thank you. I've never touched Oracle products in my entire career, and that's my no. 1 directive forever.
As opposed to Google, Meta, and Microsoft?
Yes. I just decided some 20 years ago to never touch or learn Oracle products. Is it forbidden to do so? My career is fine without them.