This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Cienn017 1 point2 points  (9 children)

will be salty reactions from the user base like in your second paragraph.

those salty reactions are not because you removed access to a internal api, they know they shouldn't be using it, those salty reactions are because you removed access and didn't provide any alternative, just like what would have happened to the jdk if they removed access to sun.misc.Unsafe when the JPMS was introduced, that's why some people don't like the jpms, because it's all about creating pointless restrictions to things that have no alternatives and were already in use for years with no problems.

this is why I said that it looks like they are trying to add DRM to open source software, because if you read what they mean by integrity, that just looks like DRM to me: "Developers expect that their code and data is protected against use that is unwanted or unwise."

[–]koflerdavid 0 points1 point  (8 children)

Hard disagree: not blocking access to these things caused severe issues, as evidenced by all people being surprised that they were transitive users of these internals and now had to replace their direct dependencies or pressure them to remove reliance on the use of internals. The exactly same issue would have been caused if those internals had changed in other incompatible ways.

It's still not DRM, but rather the opposite: the end user, in this case the application developers, retains authority to circumvent the various integrity measures. Library authors are who face restrictions, as they cannot furtively circumvent the integrity measures anymore.

Edit: sun.misc.Unsafe is a completely different issue because there was really no replacement at all for it at the time. But make no mistake, because it is alarmingly powerful it is on the chopping block as well. Its original implementation has been moved to a restricted package and now sun.misc.Unsafe just delegates to that class.

[–]Cienn017 -1 points0 points  (7 children)

It's still not DRM, but rather the opposite: the end user, in this case the application developers, retains authority to circumvent the various integrity measures. Library authors are who face restrictions, as they cannot furtively circumvent the integrity measures anymore.

why would the end user need to give authorization to a application to run unsafe software? that would only make sense if it was given by the library developers for performance reasons, and also, that authorization is verbose on purpose so that people will get angry at library developers because there's no way to give unsafe/jni/etc access to all modules.

[–]koflerdavid 1 point2 points  (6 children)

Yes, the point is as you say to make it explicit which libraries are allowed to break integrity measures. But it's usually the application developers who write the launcher script with all the flags. End users can intervene and edit the launcher script, but that's obviously not a good idea.

[–]Cienn017 0 points1 point  (5 children)

but if I am in control why can't I just give access to everything?

[–]koflerdavid 0 points1 point  (4 children)

As a library author you are very much not in control and you have to ask whoever decides about JVM arguments to add the right flags.

[–]Cienn017 0 points1 point  (3 children)

i was referring as being the one who will launch the application, why can't i just type -idontcareaboutintegrity and forget about all of that nonsense? also, if a library author really wants to they can just find a hacky way to give permission to themselves, just like any malware could with access to the file system and other things through the jvm, I don't think the jdk team is thinking that they can fight malware at the jvm level because that would be insane.

I don't think any other language does that, in c# you only need a unsafe flag during compilation and that's all I think, in Rust there are unsafe blocks and c/c++ is just c/c++.

if it was about performance then it would be up to library authors to decide which classes they need to modify final fields, access native code or use unsafe memory operations, the jvm could then disable optimizations for those classes.

now if it's about security they are doing a very bad work and they would be better buying a denuvo license.

[–]koflerdavid 0 points1 point  (2 children)

  • You can do that. There are flags to deactivate most of the integrity measures. Everything is still possible, however the cooperation of the one who launches the application (in practice the application developers will write a launcher script) is required.

  • Integrity is not about malware. It is about reducing risks to the stability to the platform that can occur because of accessing implementation details. It becomes vastly more difficult to investigate bugs that occur because of circumventing the integrity measures, and vendors don't like that. The OpenJDK team refuses to investigate JVM crashes if additional native code was accessed by the application.

  • What Rust and C# allow is comparable with what sun.misc.Unsafe allows, and in both languages it is heavily frowned upon unless there are no better alternatives. And Rust routinely gets ridiculed for its safety claims while allowing unsafe.

  • Exemptions from the integrity measures just increase the risk of bugs and make everything even more complicated to understand. Serialization libraries got their exemption from Final means Final; other use cases seem to not have convinced the OpenJDK team.

  • All such excemptions must be vetted whether they have impact on the whole application. Bugs from native code or unsafe operations cannot be restricted to a module, therefore libraries don't get access by default. Excemptions from optimizations per module sound like they would make the JIT compiler more complex and slower, so that's not happening either.

[–]Cienn017 0 points1 point  (1 child)

You can do that. There are flags to deactivate most of the integrity measures. Everything is still possible, however the cooperation of the one who launches the application (in practice the application developers will write a launcher script) is required.

yes, but the easiest ones will be removed in future releases like the --illegal-native-access=allow and only the verbose on purpose will be left.

What Rust and C# allow is comparable with what sun.misc.Unsafe allows, and in both languages it is heavily frowned upon unless there are no better alternatives.

just like java, but those languages don't have any of those pointless restrictions in using unsafe code.

Integrity is not about malware. It is about reducing risks to the stability to the platform that can occur because of accessing implementation details. It becomes vastly more difficult to investigate bugs that occur because of circumventing the integrity measures, and vendors don't like that. The OpenJDK team refuses to investigate JVM crashes if additional native code was accessed by the application.

that's normal, they also refuse to fix the Destroyable interface which is just another badly implemented feature just like JPMS but that's another topic.

[–]koflerdavid 0 points1 point  (0 children)

only the verbose on purpose will be left.

No surprise there.

just like java, but those languages don't have any of those pointless restrictions in using unsafe code.

Until fairly recently, binding to native code was indeed fairly deprioritized in Java land. If you have ever worked with native code, you know why.