I don't know how to use java and not violate one of Oracle's EULAs. I could read about it and figure out how to do it safely, or I could just not use java. Java isn't essential (for greenfield projects). There's lots of good alternatives, so I'd rather do that.
If you use Oracle's distribution of the JDK then you are an enterprise customer and should have the resources to deal with their license terms.
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.
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.
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.
Builds of the OpenJdk codebase by other vendors are supported for other lengths of time.
What?
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 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.
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.
?? It is very simple. Please go to the OpenJDK site and read the below:
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.
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).
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.
The point remains though that it's the same situation. There's a free open source implementation and some companies that offer paid support.
(Also to needlessly quibble, technically James Gosling under Sun Micro-systems invented Java)
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.
So there's no friction, everyone uses the OSS ones unless you have very specific needs.
Just go to https://openjdk.org/ and click "Download". Or say `brew install openjdk` (macOS) / `apt install openjdk` (linux).
ZERO friction.
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.
Is Microsoft really better than Oracle in that regard?
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:
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.
Great GUI cross-platform GUI toolkit (MAUI), great WASM engine (Blazor).
Upcoming .NET 10 is going to be awesome.
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.
Otherwise C# and .NET have had a pretty solid track record.
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?
Or use your OS package manager and <pkgManager> install openjdk. Problem solved.
Just like any other software, you know ?
"Production and Early-Access OpenJDK Builds, from Oracle"
That's all.
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'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.
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.
"Where I work now, we went through 2 or 3 rounds of funding. Each round involved lawyers doing due dilligence, checking the licensing
of all the software we use, and all the libraries we use, and so on. No issues were raised regarding Java or MySql. Bottom line, I don't know
the difference between this and that license, what I do know is that Oracle licensing for Java and MySql gave us zero grief."
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.
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
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.
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
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.
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.
It's an uphill battle, but it might just climb the hill because it's still such a behemoth.
And now let’s talk about .collect(toList())…
And records which look like ugly beans…
Java is the land of the verbose. But it can probably be solved with 9 extra characters on every line.
let v = (1..5).collect::<Vec<i32>>(); // Cool RustThat was in 2008, we’d be happy by now; and Java had no qualms asking everyone to change the package names from javax’ to jakartax’ in Java 21, so they should have issued a java.collections package and deprecated the lists i java.utils.
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.
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.
Using it in vscode, while not perfect yet, is starting to be alright.
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...
In Java a lot of code looks like this
void foo(Bar bar);
void foo(new Bar { @override boolean baz(Fish fish) { return false; } });
foo((Fish fish) -> false);
foo(this::fries);
saveMenuItem.registerMenuClickListener(myMenuClickHandler);
saveButton.registerClickListener(myMenuClickHandler::onMenuClick);
1. No unsigned integers. "byte" is -127 to 128. I believe this means it's not straightforward to make a 32-bit RGBA structure since you options are either using a signed "red" or using a 16-bit integer to store the 8-bit values. by the way I tried to benchmark how slow Java was compared to C in a simple test (I had arr1[] with indexes of arr2[] which contained values and I created arr3[] by resolving them) and it seems to be only half the speed of C which is probably fast enough for some basic low-level 2D graphics.
2. String.split takes a regex argument and there is no standard way to split without a regex. This was really confusing to me, but fortunately it's very easy to write your own .split, so it's not that much of a big deal.
3. You can call a different constructor with this(), but it has to be the first statement in the constructor. This one is pretty crazy! It would make sense if you couldn't access member fields before calling the constructor, but having to be first statement means if you want to calculate the argument for one constructor based on an argument passed to another constructor you need to do it inside the parentheses.
So far there is only 2 things I wish Java had. First the ability to implement methods in interfaces so you could use them if you have an interface instead of using a static method. Second I wish @NotNull was the default. This is a problem that Kotlin fixes so I think if you like Typescript for tis type-safety learning Kotlin would be a good idea.
$ cat Foo.java
interface Foo {
private String jimbo() {
return "yup";
}
}
$ javap -c -private Foo
Compiled from "Foo.java"
interface Foo {
private java.lang.String jimbo();
Code:
0: ldc #1 // String yup
2: areturn
}
interface Bar {
default boolean isAwesome() {
return true;
}
}3 is not an issue anymore since java 22 https://blog.jetbrains.com/idea/2024/02/constructor-makeover...
These days I don't see those as significant issues, tbh.
I would prefer a Clojure program, but I'll take Java over Typescript at this point.
Python code that follows traditional Python paradigms is called "Pythonic".
Java code that follows Java paradigms is called "awful".
To be fully transparent, I've never written Java professionally, only for a couple small hobby projects 10 years ago, plus some while in school, so my opinion isn't worth the pixels you're reading it on, but I look at most Java code with abject horror.
Endless levels of abstraction. The apparent inability to write a simple function and instead creating a "ThingDoer" class with a single function called "doThing". Run-time introspection and reflection EVERYWHERE. Stack traces that are just an endless stack of calls to functions like ".invoke" and ".run".
I've been under the impression that all of that is a by-product of Java's strict type system, but someone please correct me. Why do Java paradigms seem so awful?
https://github.com/plantuml/plantuml/blob/master/src/main/ja...
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.
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
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.
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.
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.
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.
On the other hand, how universal is the problem of migrating from one ORM to another? Not all problems Java I has been leveraged to solve are relevant today. This is the extra baggage we have to carry forward.
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.
Especially now that hardware architectures are getting fragmented again, I hope it becomes more relevant.
I think Springframework is dragging Java's reputation down. I know Spring boot is better but it's such a monstrosity.
I feel like sadly Python has won the war, though. Good enough for most things even though it is pretty rubbish.
I see people trying to use Rust now for prod AI systems.
With this in context...
> I think Springframework is dragging Java's reputation down. I know Spring boot is better but it's such a monstrosity.
Is that really so? Spring's not the best, but it's definitely better in medium / large environments than a lot of other 1s. There are way more train wrecks to maintain that especially don't have any documentation or the libraries have gone dead.
Is that thanks to JVM or due to the way how Clojure works? Because I can share the same anecdotes for my Clojurescript projects. I can grab any old nbb script and things just work off the bat - sometimes I have to update some npm dependency, but most of the time, things simply aren't horribly broken. Meanwhile, I just spent half a day jumping around for weird Python dependency and venv magic dance, just for the sake of running five interdependent scripts.
In any case, the dominant way people build Clojure has changed. Ten years ago it probably used lein. Nowadays a new project will probably use deps.edn.
Java has the additional issue of being object-oriented, which leads to spaghetti parent-child relationships under stress.
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.