Reading binary data

[Maurizio Cimadamore]

On 18/11/2019 01:26, Samuel Audet wrote:
> Anyway, you're saying you can't make more information public at this 
> point about that, that's too bad. As with anything related to C++, I'm 
> simply trying to get as much information as I can. OpenJDK should 
> really be more "open"... 

I think you are mistaking the fact that we're busy spinning many plates 
with a desire to keep information less public that desirable. Right now 
we're focused on what's ahead of us - which is the memory access API. 
Since there's no ABI support slated for this first deliverable, all 
these issues around forging unsafe pointers are, frankly, out of scope 
at the moment. The goal is to provide a safe and more efficient 
alternative to the off heap uses of the ByteBuffer API.

We know that, moving forward to the second part of the story (ABI 
integration) we will need eventually to do something to sort out access 
to unsafe API. And, moving even further, we know we will have to do 
something about C++. As for everything else, we will share detailed 
information as we will have clearer plans about how XYZ fits into the 
general picture.

As a meta-comment, your attitude is not promoting more openness; is 
actually having the opposite effect: if I cannot share an idea (e.g. 
having a mechanism to gate access to unsafe APIs) without having to pay 
a multi-email cost to keep you happy (and this stuff detracts time for 
everything else we have to do!), then I guess it's understandable if, 
next time, I will think twice before hitting "Send" ?

I think the information we shared so far are more than enough to 
understand the broader picture of what we want to do; let me summarize 
it here to make it 100% clear, but please let's close this discussion 
down for now, and let's revisit once more info is actually available:

* not all modules or jars are created equals - some require 'native' 
access, some don't
* module or jars which require native access can insert subtle crashes 
in your application
* there is no mechanism (at the moment) to distinguish between a regular 
module/jar and one which require native access
* as a result, an application which depends on 256 jars/modules doesn't 
know which one might blow it up
* _both_ JNI and the SystemABI API are functionalities that are _more_ 
privileged than, say "String::substring"
* I think it is time we look at some mechanism to separate between these 
two (very different) kind of modules/jar (mechanism TBD)

Should this have been done on JNI from day one? Yes, of course. But I 
doubt that when JNI was created the level of understanding about what 
can go wrong when you start writing application that depends on hundreds 
of jars was as deep as it is now. Should such an effort have been part 
of Jigsaw? It could have been, of course, but there's only so much you 
can stuff under the same umbrella (if you want to produce actual 
deliverables, that is). As aspects of jigsaw were still being actively 
discussed past Java SE 9 [1, 2] - and are still actively being discussed 
_now_  [3] - offering clients some degree of protection against native 
libraries is yet another turn of the crank which fits in the general 
picture of making the Java world safer for everybody. The fact that it 
wasn't done before is a very weak argument in support of the status quo.

[1] - https://openjdk.java.net/jeps/320
[2] - https://openjdk.java.net/jeps/335
[3] - https://bugs.openjdk.java.net/browse/JDK-8220607

Maurizio