Losing features of JVM_Open, e.g. CLOEXEC

[Christos Zoulas]

On Oct 29,  1:12pm, martinrb at google.com (Martin Buchholz) wrote:
-- Subject: Losing features of JVM_Open, e.g. CLOEXEC

| throwing away use of old shared infrastructure and replacing with "naked"
| calls to the OS.  Although understandable, this abandons benefits of using
| shared infrastructure.  Here I'm thinking of the close-on-exec flag.  I
| just added use of O_CLOEXEC to linux hotspot, but e.g. zip file opening no
| longer uses JVM_Open, which is a code hygiene regression.
| 
| What we want is to have almost all file descriptors have the close-on-exec
| flag automatically set at fd creation time, using O_CLOEXEC where
| available, and FD_CLOEXEC where not.  How do we get there?
| 
| I'm distressed that the JDK core libraries should be moving towards having
| *more* shared native code infrastructure, but here we seem to be moving in
| the opposite direction.  Having abandoned JVM_Open, the responsibility of
| doing these things right belongs entirely to the core libraries team.  So
| where's the core-library replacement for JVM_Open?

I totally agree with Martin here. Changes like this are harmful.

christos