▲ 86 points
back
96 comments
> The JEP is a Preview Feature meaning the Foreign Function & Memory API (hereafter "FFM") will not be a final feature in JDK 21. I think some of us hoped it could make it into finality in 21. However, my personal opinion is that the API is very unlikely to change in any significant way and what we are seeing in 21 will be very close to the final FMM API.
One thing I really appreciate about Java and the JEP process is the careful attention to detail and avoid breaking changes. So if it takes a few extra cycles, I'm all in. It's worth getting it right the first time.
FFS, stuff I downloaded from Node _5m ago_ is already deprecated.
Yeah. this is one of the main reasons I use Java for most of my work. The time spent putting out fires caused by framework- and library churn is time not building something useful.
My first exposure to programming, the AP CS exam (and its accompanying course), was in java. My first hobby foray into programming (Minecraft) was Java. So, I'm heavily biased here by my familiarity. However, in the years since, I've done a lot of time where my primary focus at jobs was, among others: python data stuff, "fullstack" stuff, Scala stuff, and golang stuff. And I just keep coming back to Java as my overall favorite.
My personal diff against most languages goes something like:
1. Stuff rots a lot less fast than in python and js. Code keeps working for longer, dependency goofiness happens a lot less, etc.
2. It's just less clunky than golang - but this is mostly my own preferences. I often describe go as if someone designed a language, and then had this list of hard language design problems, and were I to look at this list, I would go "hmm yes these are hard problems where all the options have drawbacks", and then for EVERY SINGLE ONE OF THEM they picked the compromise I would not have picked. So it's just death by a thousand little things that annoy me. My current job is golang though so I'm wondering if I'll come around to it or something. We shall see.
3. Java just doesn't encourage such terrible cleverness that Scala (and to a lesser extent python and js) invites. This might be cultural too where Scala has this functional programming fanatics segment who love the cats library a little too much. But never have I ever before seen so much code that's just intractable to junior devs, and requires far too much brain-CPU for mids and seniors to read. Sure you can get into a lot of trouble with Java's reflection, but IME many java devs are suitably reluctant to go reflection crazy.
4. Damn is it fast by default. And can be REALLY fast if you specifically focus on a specific path.
5. The tooling is so mature. Does python or go even have anything like VisualVM? And as I understand it, even VisualVM is old hat compared to JFR, though I've not looked closely there.
6. The library ecosystem. It's even more expansive then npm but 10x less thrashy and churny. I particularly like that there's this interesting niche of academic libraries that end up out there that you might find yourself bumping into now and then.
7. Packaging. People use maven. Even people who use gradle still basically are just using maven with extra steps. Sure it's XML but aside from adding dependencies, you hardly touch it. And if your build system truly needs to be weird (like, say, android), then gradle is right there for you. 2 tools for the whole ecosystem. How many does python have again? I find I have little patience for packaging problems and I suspect some of it stems from the fact that if I were using Java, I wouldn't be having packaging problems.
I'm sure I could go on, but I'll cut it here. For a million reasons, I find stuff built in Java just works and keeps working (both dev-environment and in prod) far more probably and for longer than in other languages and stacks. And it's fast enough to develop that I'd say it's well within range of python and ruby and such, for anything that bigger than a couple files.
> 3. Java just doesn't encourage such terrible cleverness that Scala (and to a lesser extent python and js) invites. This might be cultural too where Scala has this functional programming fanatics segment who love the cats library a little too much. But never have I ever before seen so much code that's just intractable to junior devs, and requires far too much brain-CPU for mids and seniors to read. Sure you can get into a lot of trouble with Java's reflection, but IME many java devs are suitably reluctant to go reflection crazy.
Java has improved significantly in this regard, but Java used to be the poster child for overly clever intractable code. It mostly been relagated to memes and legacy code, but AbstractFactoryFactory used to be the way of writing Java code, where everything was supposed to happen through a dozen layers of indirection.
For sure. I do speak of Java mainly from what I've seen in the past, say, decade. Where it does seem like we've mostly learned our collective lesson there.
Ive been programming Java since around 1.4 and that AbstractFactoryFactory meme is just BS. Its not in the language. Some frameworks were bloated in that way but that's not the language.
As someone who mostly does small hobby projects I do really like how easy the packaging is in Python and JS is. To get started you literally just do “npm i” or “pip install” whereas Maven and Gradle are a bit of a pain to configure in comparison
True but beyond hobby projects this becomes a double-edged sword that swings back at you.
Could it not have both? Can’t something work like Maven or Gradle but have some nice utility commands to make installing things easy? Or does that already exist?
Lol, what? NPM is amazing
I like Scala and I really recognise that terrible cleverness, but I really don't like you blaming it on the language because it's a failure of people.
(Conversely, I really really wish I'd done my personal project in Scala rather than C#. It manages to be good and horrible at the same time)
I don't really believe that you can separate the language from how it's used. I blame Java when people write code that beats the crap out of the GC because Java both makes it easy (especially with streams sometimes) and also is flippant about it in most recommendations (which emphasize that the gc is good, allocating an object is cheap, and so on). Python somehow doesn't seem to have that happen nearly as often, for instance.
So I also blame Scala when people over-use implicits and go functional-mad because Scala encourages it.
> Python somehow doesn't seem to have that happen nearly as often, for instance.
It really is not a sarcastic comment, but Python is just not that fast to make GC the performance bottleneck in ordinary usage. It uses ref counting, which trades off performance to a more deterministic deallocation (plus there is also the GIL).
One of Scala's biggest mistakes was probably to support higher rank types, because it seems to have resulted in a in a hostile takeover of the Scala community by pure FP zealots. No one in the world ever thought: "why don't I write Haskell code on top of a VM that really isn't well-optimized for it, using a language that wasn't designed at all for it?" But that seems to be what a large portion of the community does nowadays.
This wasn't Scala's only mistake though. It seems to have a history of implementing features that then die out due to a combination of lack of support and of never being implemented well in the first place, including:
* specialized types
* macros
* delimited continuations
* Scala reflection
* Eclipse IDE support
* Scala native (technically still going but only whenever there is funding at a university to pay a student to work on it)
* Multiple collections library rewrites (this one is pretty core!)
* other half-baked bundled libraries that have been deprecated/removed over time
Not to mention the number of community-owned frameworks that have been discontinued or declined in usage over time. Anyone remember Lift? That used to be the most popular web framework in Scala! And how are Play Framework and Akka doing nowadays?
If your build system requires more than what Maven can do, I'd say it's time to go home and rethink your life choices. All that Gradle does is allow you to create an unfixable spaghetti mess. Adapt your project to Maven, write your own plugins and extensions if you must. Don't. Use. Gradle.
Say what you will about the evil database company which shall not be named, but under their stewardship the JVM ecosystem is moving into the right direction, and there is massive investment in foundational technologies that will take years to come to fruition, some of it unmatched (eg virtual threads or GraalVM).
People tend to forget that it was Oracle alongside IBM, that joined Sun in the major Java push before anyone else. See Network Computer, first Swing based GUI for DBAs, SP in Java,...
Both of which also have had their own JVM implementations.
Virtual Threads are actually in their second preview which means it might not be years before we see them standard in the JDK.
It currently looks like Virtual Threads will be final in JDK 21, to be released in September this year.
Just to be clear that's a submitted draft JEP [1] so not quite there yet....
Out of curiosity, what's the difference between virtual threads, green threads and, say, goroutines?
Not a lot. To a large extent, they are different names for the same concept. But since they are the names used for that concept by specific implementations, they also imply the particularities of those implementations.
The old Java green threads could only use a single core, the new Java virtual threads can use multiple cores. AFAIK, Java green and virtual threads are both cooperatively scheduled, Goroutines are, nowadays, preemptively scheduled. And so on and so forth.
Java's virtual threads are preemptive, not cooperative -- they are preempted not at explicit points, but at blocking IO operations.
Its solving the function colouring issue. Your code can run against old-school OS-threads with blocking I/O, or it can run against virtual threads with non-blocking I/O that look and behave almost exactly the same, but are multiplexed onto fewer underlying OS threads, without needing to introduce language constructs such as async/await or changing anything in your program code except maybe the executor implementation.
Golang is opinionated towards its single coroutine model, there is no way to switch. Its a good model and it works well, but there are cases where it leaks, such as low-performance C interop.
Green threads usually refer to single-threaded runtimes such as Node.
So it's basically an implementation of transparent of M:N scheduling, right?
I remember that early versions of Rust had that but dropped it because building a single implementation of that that scales to all platforms is hard (tm).
Green threads usually refer to single-threaded runtimes such as Node.
This doesn't sound right. How is the single-threaded event-loop of node green threads?
> FFS, stuff I downloaded from Node _5m ago_ is already deprecated.
There's really no reason to use hyperbole to make your point. And besides, Node and Java aren't very different in their release policies. Node follows a standard LTS structure where every other release is an LTS, and Java follows a standard LTS structure where every third release is an LTS. If anything, that means more versions of Node are supported for longer without backwards incompatible changes.
The comment isn't about the language but the ecosystem, which yes it's hyperbole, but seems to generally hold true. The node ecosystem has a ton of churn
No, the comment is clearly about the language. The literal context of the submission is a new API being added to Java, and the GP is discussing how they prefer the slow pace of evolution of Java to Node's supposed breakneck pace of breaking changes.
Unfortunately, they're just making up things about Node, thus my comment explaining how they're incorrect.
My first thought was “What about JNA?”
> Over the years, numerous frameworks have emerged to fill the gaps left by JNI, including JNA, JNR and JavaCPP. These frameworks are often a marked improvement over JNI but the situation is still less than ideal — especially when compared with languages which offer first-class native interoperation. For example, Python's ctypes package can dynamically wrap functions in native libraries without any glue code. Other languages, such as Rust, provide tools which mechanically derive native wrappers from C/C++ header files.
Is this JEP going to make that possible in Java?
I believe the goal of this project is to provide a low-level API for FFI, on which other tools can build.
Not sure which part of the quoted text you are asking about specifically, but it is quite likely possible to build such an abstraction on top of it (plus Java's dynamic class loading + loading dynamic libs should be able to handle pretty much any case). For an example, jextract is also in the works that will generate Java helper classes from C headers.
Thanks. Sorry for being unclear - I was talking about importing a C header.
Yes it's possible. The same project developed a tool called jextract that uses clang to convert C headers to Java Panama classes:
This is interesting and a nice thing to have built into the JVM.
It seems to me though that SubstrateVM[1] makes calling native functions even easier (from page 8 of the slides):
// C:
struct timespec {
__time_t tv_sec;
__syscall_slong_t tv_nsec;
};
int clock_gettime(clockid_t __clock_id, struct timespec *__tp)
// Java:
@CStruct interface timespec extends PointerBase {
@CField long tv_sec();
@CField long tv_nsec();
}
@CFunction static native int clock_gettime(int clock_id, timespec tp);
This is an intricate API that is likely to require an intricate implementation just to be correct. But correctness won't be enough, the JEP requires the JIT to implement some complex optimizations.
I could use some reflections around: how do you implement such a large and complex feature in a JIT without potentially creating lots of vulnerabilities. It looks like a lot of new surface area in the VM with bad failure modes and VM engineers too are only human.
How is the overhead of each function call in this implementation? I'm wondering if it's significantly more efficient to manipulate a struct in foreign memory directly than to call a bunch of foreign setter functions. This may influence how I eventually implement a Java binding for AccessKit [1].
Yet another feature Android will miss out.
It's a shame. Android _should have_ from the beginning used: Linux containers, a modified JVM profile, Android libraries as regular java dependencies, etc.
At least they updated Android 12 to Java 11 LTS, and Android 14 will get Java 17 LTS.
However it is a subset as usual, and most likely because they are already starting to feel that Kotlin also needs those Java libraries which are leaving Java 8 behind, unless they feel like rewriting Maven Central universe into Kotlin.
You seem to be knowledgeable about the Android situation - what’s the current deal? From what I gathered, android uses a hybrid runtime that has many parts of the code AOT compiled and cached, but can JIT compile as well to suit for a particular device, is my understanding correct?
But yeah, I agree with you, they really should have gone with possibly a simpler JIT compiler and an alternative GC implementation that is more conservative in memory usage.
Here for the JIT/AOT, since Android 7 (5 and 6 used AOT only),
https://source.android.com/docs/core/runtime/jit-compiler?hl...
The issue isn't even converting JVM bytecodes into DEX, other compliant Java implementations for embedded do similar approaches, see PTC and Aicas.
The issue is how they have stagnated Java support on purpose as means to push Kotlin, they aren't being innocent by using Java 8 samples against Kotlin features.
And the whole but Oracle doesn't cut it, given how dependent Kotlin is on the whole JVM ecosystem.
It starts that way, with a mark and sweep collector (think Java CMS or the GC of Go). But some applications like games or Facebook are monsters so the GC was changed to a copy collector which has a better throughput, avoid fragmentation at the cost of using more memory.
Also the code is not just AOTed, Android is using profile guided AOT. After several days of usage, the code is AOTed with the profile collected from previous runs.
What's wrong with the current one?
Java on Android is a miserable experience because of how far behind it is. That you can't really guarantee that anything past Java 1.7 is available means that everyone just writes to that lowest common denominator (of course, there's plenty of legacy code too…)
Yes, how else would they push their Kotlin agenda, if modern Java was given the same access.
See how little everyone cares on the JVM, it is just another guest language alongside Scala, Clojure and Groovy competing for attention.
Unfortunately the application we develop (speech assistant) also needs to run on Android (head units) and that is really frustrating