Hacker News Reader

Comment by quantumwoke | Hacker News Reader

As the maintainer of a large piece of Java software that interacts with legacy code in over 50% of the codebase, this was a very scary read. It sounds like the entire basis for my software which tens of thousands of people rely on every day is soon to be "restricted". I cannot prepare my users for the fact that my software _will not work with no recourse_ in the future. I understand the JVM's need for safety, but this is personally destroying my livelihood. It's along the lines of telling Ruby users one day that monkey patching will be phased out in the next release.

I suppose the next layer down the chain is to start patching code with ASM. Ugh.

View on HN

> "will not work with no recourse"

No, the CLI `--add-opens` CLI option will stay. In other words, applications will need to consciously enable the encapsulation-breaking stuff. Is that bad? Modern software moved to public APIs quite a bit ago. That said, if old applications want to use new JDKs, they will require quite some developement, yes.

One of Java's strong points has always been the amount of care to source and binary compatibility (Java 8 classes work fine on Java 20, source code only need minor modifications). I welcome the new restrictions since they make Java more secure and future-proof, but they have a price. There's lots of (framework) code that makes use of those loopholes and many Java projects already have issues with maintenance since it's not the 'hot stuff' anymore.

The old JVMs will still be available and you so will the Docker containers with them.

That said the writing has been on the wall since Java 9's project Jigsaw. If you have a product that depends on it, I'm surprised you were caught unaware. With more control over what is exported, the amount of compiler optimisations possible greatly increases.

Not if the software I depend on requires the latest JVM (which it will).

Well new JVM rules comes with new JVM. So something gotta give. Leaving Java be potentially unsafe just because few customer relied on it would be irresponsible behavior on JDK maintainers part.

I'm not sure how current JVMs are "unsafe" though. If you go messing with the internals of third party classes, seems like any consequences should be obvious.

Then just enable it at start time with a flag.

> If you go messing with the internals of third party classes, seems like any consequences should be obvious.

The point made in the article is that it's often third-party libraries that do this, breaking invariants in your code. And, with older JVMs, it won't be immediately obvious to you as a user of that library that this is happening.

I can't recall a time when 3rd party code has changed something in my code and broke it. I was hoping someone could provide me with an example

Try loading a library that uses com.sun.* through reflection in a program running on JVM 9 or higher with default settings and you'll see an example. Maybe it hasn't happened to code that you personally wrote, but it has certainly happened this way to code that someone at OpenJDK wrote.

But that third party code may depend on some JVM internal through unsafe, which latter might change (and one really should not depend on internals) and break your code.

Well they have you covered:

> To balance the need for integrity with both the circumstantial, convenience uses of JDK internals and the essential uses, Java gives the user – the application's owner (typically its author, maintainer, or deployer) – the final say on which strong encapsulation boundaries are in place and which should be ignored. This freedom is offered under the guiding principle that the ability of one component to encroach on the boundaries of another must be explicitly granted by the application. Libraries cannot choose to obtain encapsulation-busting "superpowers" without the knowledge and consent of the application's owner.

the entire low latency sector is will be stuck on java 8 until they figure out what they're going to do with Unsafe

which may be forever

JNI exists.

JNI is known to be slow

Marshaling is slow, the trick is not to have chatty interfaces.

using JNI would turn 1 intrinsic'ed instruction into about 800

which might be an acceptable tradeoff if you're shovelling JSON to a websocket

not so good if you're a smart order router trying to hit a level that will be gone in under a microsecond

Won't Project Panama solve this? One of the goals in JEP 424 is to provide performance competitive with sun.misc.Unsafe so that (it says later in the document) it can eventually be removed.

It sounds like --add-opens, etc will still exist. Can you use that? It would, as discussed, be an admission of legacy-ness.

Reply on news.ycombinator.com