5 ms·

Java – Integrity by Default (JVMLS 2024)

62 points by cempaka 2y ago

spintin 2y ago
This is a perfect example of people struggling to remain employed. Java 1.8 is good enough for eternity, so they have to break it to keep getting a salary. Just like Google/Apple have to break HTTP/1.1 to force adoption of their "obfuscated by complexity" protocols. What needs to be fixed in Java is the Virtual Thread pinning, and that is probably the last usable feature they will ever be able to add. They are also trying to deprecate AWT, for their non open-source JavaFX. The only way to not remain a slave is to break free: Compile your own Java! Compile your own Linux! Buy redundant hardware that does not break easily and is repairable. Make your own devices if you can. Make your own encryption.
- klez 2y ago
  > Java 1.8 is good enough for eternity, so they have to break it to keep getting a salary. I don't know, there are quality of life improvement that I quite like in more recent versions. > They are also trying to deprecate AWT, for their non open-source JavaFX. JavaFX is GPL with a classpath exception, what are you talking about? > Make your own encryption. Why? That's generally considered bad advice.
- vips7L 2y ago
  > Java 1.8 is good enough for eternity, so they have to break it to keep getting a salary. Java 8 is an antiquated runtime that under performs in all categories against other modern runtimes. > What needs to be fixed in Java is the Virtual Thread pinning, and that is probably the last usable feature they will ever be able to add. It is fixed. Go download the EA release. > They are also trying to deprecate AWT, for their non open-source JavaFX. FX is under the same license as OpenJDK (GPL) and available on Github.
  - spintin 2y ago
    [dead]
- stonemetal12 2y ago
  >non open-source JavaFX Is there a non open-source JavaFX? The only version of JavaFX I know of is GPLv2 https://github.com/openjdk/jfx https://github.com/openjdk/jfx
cobbal 2y ago
Without watching the video, this seems to be about https://openjdk.org/jeps/8305968 https://openjdk.org/jeps/8305968
- cempaka 2y ago
  It's really a long running effort that encompasses many JEPs. Modules, FFM, the Unsafe deprecation, and more all play a part.
RyanHamilton 2y ago
I see why the SDK and standard library maintainers would want this change but as an application level programmer I wouldn't want this change. They mention "the impending removal of the Security Manager (JEP 411), we need strong encapsulation to support the creation of robust security layers protected from interference by other code". That should actually be a negative point against this JEP. The security manager was removed as no one used it well or found it useful. Every on e of these features were added because they were useful to java developers. The move to modules and Unsafe have been enough pain for recent times.
- vips7L 2y ago
  As an application developer I love these changes. I do not want some library calling out to architecture specific binaries without me knowing. I want to have to enable that for them so I know that my application is portable. I do not want random code outside of my package to be able to reflect on my class and pull data out of a private variable or set its data breaking any type of encapsulation or rules I have written.
  - cempaka 2y ago
    And I don't want the JVM hamstrung from a whole host of optimizations because this random stuff could be happening at any point.
    - LegionMammal978 2y ago
      Any general-purpose JVM is already going to have JNI entry points which bypass privacy. They can certainly restrict JNI as a whole and make users jump through hoops to enable it, but they're not going to be tearing it out for a long, long time.
  - mdaniel 2y ago
    > I do not want random code outside of my package to be able to reflect on my class and pull data out of a private variable or set its data breaking any type of encapsulation or rules I have written. You have a very strange threat model given how stunningly trivial it is to decompile .class files I'm with you on the JNI but I am not willing to "baby with the bathwater" the Reflection API just avoid having to check the bytecode for Runtime.loadLibrary
Phelinofist 2y ago
I'm always getting a little sad when I read JEPs. Our app needs to run on Android as well, so we will probably never be able to utilize these things as intended. I would love to modularize our app but AFAIU Android doesn't care about that. It doesn't choke if it sees modules (anymore) but it does not enforce the access restrictions.
exabrial 2y ago
It's incredibly important to allow people to break the rules and suffer the consequences. CDI, Spring, JPA, Mock Testing (Mockito) all break the rules in some manner, like creating instances of objects without calling constructors, changing final class definitions, etc. CDI, JPA, Spring are all used "in production", while Mockito would be used only in testing. I have no idea how you balance these two. sun.misc.Unsafe was pretty hard to use and any normal human knew to stay away from it.
- cbsmith 2y ago
  There's an argument to be made that to the extent they break the rules in some manner, they're doing more harm than good. Should you be testing scenarios that are impossible to encounter with the code? Should frameworks be breaking encapsulation and contracts of code? Most of the time breaking the rules is a reflection of either a bad practice or lack of functionality in the language. I'm all for experimenting in either of those dimensions, but there's a lot of value to have a default behaviour of not doing that.
  - exabrial 2y ago
    >There's an argument to be made that to the extent they break the rules in some manner, they're doing more harm than good. Should you be testing scenarios that are impossible to encounter with the code? Yes actually, especially when it comes to i/o. Let's say I want to simulate how many code handles a REST interaction with a third party service. I want to be able to mock the REST callout without performing any actual i/o. This is why these test frameworks are powerful and useful. Later if I want I can test to see if the actual callout works by hitting a local endpoint.
    - cbsmith 2y ago
      "I want to be able to mock the REST callout without performing any actual i/o." Why? Because it's hard for you to mock out actual I/O, which could be solved by a tool that makes it easy to mock out actual I/O.
marajit 2y ago
Bunch of winers in the comments. This is totally necessary effort - there's nothing worse than the ground moving under your feet. In the end its no longer necessary to expose internals. Strong encapsulation even aids in disciplined development within the JDK.
vlaaad 2y ago
I can't shake off a feeling that "integrity by default" is a populist bullshit. If a third-party library is not updated to not use require reflection, the speaker considers it "a red flag that it's improperly maintained" and suggests looking for alternatives. This is just plain ignorance: for particular domains, there are libraries that either don't have alternatives, or the cost of switching to the alternatives is too high. Are JVM developers going to pay me to write a replacement for every old library essential for my projects? This simplistic approach severely downplays the impact on what the speaker calls "old applications", i.e. the battle-tested, money-generating, useful applications. Like, I get the usefulness, and I get that it's an attack surface, but it seems the author never had to deal with real-world projects where going into the internals of other dependencies to fix them or access hidden functionality is an absolutely crucial requirement that creates value for the project.
mlinksva 2y ago
Fantastic talk and direction for the Java ecosystem. Looking forward to future mitigating supply chain attacks (mentioned being left for another day at 9:17).

62 points by cempaka 2y ago

This is a perfect example of people struggling to remain employed. Java 1.8 is good enough for eternity, so they have to break it to keep getting a salary. Just like Google/Apple have to break HTTP/1.1 to force adoption of their "obfuscated by complexity" protocols. What needs to be fixed in Java is the Virtual Thread pinning, and that is probably the last usable feature they will ever be able to add. They are also trying to deprecate AWT, for their non open-source JavaFX. The only way to not remain a slave is to break free: Compile your own Java! Compile your own Linux! Buy redundant hardware that does not break easily and is repairable. Make your own devices if you can. Make your own encryption.

klez 2y ago
> Java 1.8 is good enough for eternity, so they have to break it to keep getting a salary. I don't know, there are quality of life improvement that I quite like in more recent versions. > They are also trying to deprecate AWT, for their non open-source JavaFX. JavaFX is GPL with a classpath exception, what are you talking about? > Make your own encryption. Why? That's generally considered bad advice.
vips7L 2y ago
> Java 1.8 is good enough for eternity, so they have to break it to keep getting a salary. Java 8 is an antiquated runtime that under performs in all categories against other modern runtimes. > What needs to be fixed in Java is the Virtual Thread pinning, and that is probably the last usable feature they will ever be able to add. It is fixed. Go download the EA release. > They are also trying to deprecate AWT, for their non open-source JavaFX. FX is under the same license as OpenJDK (GPL) and available on Github.
- spintin 2y ago
  [dead]
stonemetal12 2y ago
>non open-source JavaFX Is there a non open-source JavaFX? The only version of JavaFX I know of is GPLv2 https://github.com/openjdk/jfx https://github.com/openjdk/jfx

cobbal 2y ago

Without watching the video, this seems to be about https://openjdk.org/jeps/8305968 https://openjdk.org/jeps/8305968

cempaka 2y ago
It's really a long running effort that encompasses many JEPs. Modules, FFM, the Unsafe deprecation, and more all play a part.

RyanHamilton 2y ago

I see why the SDK and standard library maintainers would want this change but as an application level programmer I wouldn't want this change. They mention "the impending removal of the Security Manager (JEP 411), we need strong encapsulation to support the creation of robust security layers protected from interference by other code". That should actually be a negative point against this JEP. The security manager was removed as no one used it well or found it useful. Every on e of these features were added because they were useful to java developers. The move to modules and Unsafe have been enough pain for recent times.

vips7L 2y ago
As an application developer I love these changes. I do not want some library calling out to architecture specific binaries without me knowing. I want to have to enable that for them so I know that my application is portable. I do not want random code outside of my package to be able to reflect on my class and pull data out of a private variable or set its data breaking any type of encapsulation or rules I have written.
- cempaka 2y ago
  And I don't want the JVM hamstrung from a whole host of optimizations because this random stuff could be happening at any point.
  - LegionMammal978 2y ago
    Any general-purpose JVM is already going to have JNI entry points which bypass privacy. They can certainly restrict JNI as a whole and make users jump through hoops to enable it, but they're not going to be tearing it out for a long, long time.
- mdaniel 2y ago
  > I do not want random code outside of my package to be able to reflect on my class and pull data out of a private variable or set its data breaking any type of encapsulation or rules I have written. You have a very strange threat model given how stunningly trivial it is to decompile .class files I'm with you on the JNI but I am not willing to "baby with the bathwater" the Reflection API just avoid having to check the bytecode for Runtime.loadLibrary

Phelinofist 2y ago

I'm always getting a little sad when I read JEPs. Our app needs to run on Android as well, so we will probably never be able to utilize these things as intended. I would love to modularize our app but AFAIU Android doesn't care about that. It doesn't choke if it sees modules (anymore) but it does not enforce the access restrictions.

exabrial 2y ago

It's incredibly important to allow people to break the rules and suffer the consequences. CDI, Spring, JPA, Mock Testing (Mockito) all break the rules in some manner, like creating instances of objects without calling constructors, changing final class definitions, etc. CDI, JPA, Spring are all used "in production", while Mockito would be used only in testing. I have no idea how you balance these two. sun.misc.Unsafe was pretty hard to use and any normal human knew to stay away from it.

cbsmith 2y ago
There's an argument to be made that to the extent they break the rules in some manner, they're doing more harm than good. Should you be testing scenarios that are impossible to encounter with the code? Should frameworks be breaking encapsulation and contracts of code? Most of the time breaking the rules is a reflection of either a bad practice or lack of functionality in the language. I'm all for experimenting in either of those dimensions, but there's a lot of value to have a default behaviour of not doing that.
- exabrial 2y ago
  >There's an argument to be made that to the extent they break the rules in some manner, they're doing more harm than good. Should you be testing scenarios that are impossible to encounter with the code? Yes actually, especially when it comes to i/o. Let's say I want to simulate how many code handles a REST interaction with a third party service. I want to be able to mock the REST callout without performing any actual i/o. This is why these test frameworks are powerful and useful. Later if I want I can test to see if the actual callout works by hitting a local endpoint.
  - cbsmith 2y ago
    "I want to be able to mock the REST callout without performing any actual i/o." Why? Because it's hard for you to mock out actual I/O, which could be solved by a tool that makes it easy to mock out actual I/O.

marajit 2y ago

Bunch of winers in the comments. This is totally necessary effort - there's nothing worse than the ground moving under your feet. In the end its no longer necessary to expose internals. Strong encapsulation even aids in disciplined development within the JDK.

vlaaad 2y ago

I can't shake off a feeling that "integrity by default" is a populist bullshit. If a third-party library is not updated to not use require reflection, the speaker considers it "a red flag that it's improperly maintained" and suggests looking for alternatives. This is just plain ignorance: for particular domains, there are libraries that either don't have alternatives, or the cost of switching to the alternatives is too high. Are JVM developers going to pay me to write a replacement for every old library essential for my projects? This simplistic approach severely downplays the impact on what the speaker calls "old applications", i.e. the battle-tested, money-generating, useful applications. Like, I get the usefulness, and I get that it's an attack surface, but it seems the author never had to deal with real-world projects where going into the internals of other dependencies to fix them or access hidden functionality is an absolutely crucial requirement that creates value for the project.

mlinksva 2y ago

Fantastic talk and direction for the Java ecosystem. Looking forward to future mitigating supply chain attacks (mentioned being left for another day at 9:17).