6 ms·

The issue is that many essential libraries and tools rely on setting internal final fields. I assume that's why the options around this have remained open-ended

The issue is that many essential libraries and tools rely on setting internal final fields. I assume that's why the options around this have remained open-ended. The problem with these various "integrity by default" options is that, in most cases, granting access to one effectively grants access to all. For instance, JNI, agent libraries, and JPMS options can each be used to bypass restrictions, making the separation between them largely illusory. Integrity, as framed here, is ultimately binary. The unfortunate reality of the "integrity by default" crusade is that applications relying on libraries and tools that modify internals will continue to do so. The JDK hasn’t filled any gaps—it has only made an already delicate situation worse.

twic 2y ago
Not in my experience. I run my applications with default integrity, and when i hit a problem, i find out what caused it, and fix it. Often it's just a matter of upgrading a library to a newer version which doesn't do naughty reflective things, or changing some config to stop it doing so, or changing our own code. We had a serialisation library which did deep reflection to be slightly more efficient at serialising BigDecimal; there was a system property to turn that off, so i set it. We had code doing deep reflection into JMX to get the current PID; i changed it to use ProcessHandle instead. My colleague wrote a little test data library which does some horrific things; i might delete it and adopt Instacio instead. I think there's only one case where i ended up relaxing integrity, and i'm hoping that's temporary - it will take more time to fix than i was willing to spend.
pron 2y ago
First, it's not a "crusade" but the steps necessary to deliver the features Java's users demand. Second, the prevalence of the use of JDK internals has dropped drastically, and demonstrably so. For example, many programs broke before internals were encapsulated during the upgrade from 8 to 9; 99% of the causes were libraries relying on internals, which had changed. Access to internals was closed off in JDK 16, although, as you say, it can be selectively allowed. And yet, between JDK 17 and JDK 23, changes of similar magnitude to the JDK internals caused nearly no upgrade problems. Upgrading the JDK now is smoother and easier than it's been in the last two decades. Why? Because there's been a large reduction in libraries' access to internals. I think Java's handling of this transition compares very favourably to how other languages have handled similar transitions from some old model to a new one (or evolution in general) in terms of balancing the needs of both old and new projects.
- cogman10 2y ago
  I can attest to how easy it's become to update jdks for our org. 8->11 was really a pain in the neck. 11->17 had some pain, but mostly was nothing serious. 17->21 has been painless. And I have some projects running on 24 already with no problems. The feature delivery has been great and we are getting pretty close to not needing to do anything but update the jdk to move forward. Now, if only I could get devs to stop using lombok....
  - sgammon 2y ago
    > Now, if only I could get devs to stop using lombok One of the only remaining reasons I discard libraries without a further thought
  - pandemic_region 2y ago
    Why the Lombok hate? It's just an innocent preprocessor allowing a bit of syntactic sugar right?
    - pests 2y ago
      It feels weird to me that functions exist without being in the source code.
      - pandemic_region 2y ago
        I never looked at it that way, but I get now where you're coming from. To me, the Lombok annotations are more like @Transactional, providing some useful boilerplate that I don't need to care about, it just works.
        pests 2y ago
        I agree its extremely useful. I am just used to languages/frameworks that at least autogenerate the code. Maybe some inheritance to give you a place to make changes that wont be wiped.
    - 2y ago
sgammon 2y ago
It's 2025 and Guava supports JPMS now
- Phelinofist 2y ago
  Android doesn't :(

twic 2y ago

Not in my experience. I run my applications with default integrity, and when i hit a problem, i find out what caused it, and fix it. Often it's just a matter of upgrading a library to a newer version which doesn't do naughty reflective things, or changing some config to stop it doing so, or changing our own code. We had a serialisation library which did deep reflection to be slightly more efficient at serialising BigDecimal; there was a system property to turn that off, so i set it. We had code doing deep reflection into JMX to get the current PID; i changed it to use ProcessHandle instead. My colleague wrote a little test data library which does some horrific things; i might delete it and adopt Instacio instead. I think there's only one case where i ended up relaxing integrity, and i'm hoping that's temporary - it will take more time to fix than i was willing to spend.

pron 2y ago

First, it's not a "crusade" but the steps necessary to deliver the features Java's users demand. Second, the prevalence of the use of JDK internals has dropped drastically, and demonstrably so. For example, many programs broke before internals were encapsulated during the upgrade from 8 to 9; 99% of the causes were libraries relying on internals, which had changed. Access to internals was closed off in JDK 16, although, as you say, it can be selectively allowed. And yet, between JDK 17 and JDK 23, changes of similar magnitude to the JDK internals caused nearly no upgrade problems. Upgrading the JDK now is smoother and easier than it's been in the last two decades. Why? Because there's been a large reduction in libraries' access to internals. I think Java's handling of this transition compares very favourably to how other languages have handled similar transitions from some old model to a new one (or evolution in general) in terms of balancing the needs of both old and new projects.

cogman10 2y ago
I can attest to how easy it's become to update jdks for our org. 8->11 was really a pain in the neck. 11->17 had some pain, but mostly was nothing serious. 17->21 has been painless. And I have some projects running on 24 already with no problems. The feature delivery has been great and we are getting pretty close to not needing to do anything but update the jdk to move forward. Now, if only I could get devs to stop using lombok....
- sgammon 2y ago
  > Now, if only I could get devs to stop using lombok One of the only remaining reasons I discard libraries without a further thought
- pandemic_region 2y ago
  Why the Lombok hate? It's just an innocent preprocessor allowing a bit of syntactic sugar right?
  - pests 2y ago
    It feels weird to me that functions exist without being in the source code.
    - pandemic_region 2y ago
      I never looked at it that way, but I get now where you're coming from. To me, the Lombok annotations are more like @Transactional, providing some useful boilerplate that I don't need to care about, it just works.
      - pests 2y ago
        I agree its extremely useful. I am just used to languages/frameworks that at least autogenerate the code. Maybe some inheritance to give you a place to make changes that wont be wiped.
  - 2y ago

sgammon 2y ago

It's 2025 and Guava supports JPMS now

Phelinofist 2y ago
Android doesn't :(