Re: [DISCUSS] permit-reflect vs --add-opens for Java 11 support

>Do we know what third party libraries are using java internals that >we might have problems with? #2 isn't going to work for those >libraries, unless they also add a module-info.class. So maybe we >will need to do #3 for third-party libraries? Adding these third-party libs on module path[1] rathe

Re: [DISCUSS] permit-reflect vs --add-opens for Java 11 support

I'm with Galen on this one. As nice as it would be to be able to say "This is what we'll do," I don't think any of these is going to be the proverbial silver bullet. I think we should, in priority order, (#1) remove what restricted API calls we can, (#2) adopt the module system and properly decla

Re: [DISCUSS] permit-reflect vs --add-opens for Java 11 support

Do we know what third party libraries are using java internals that we might have problems with? #2 isn't going to work for those libraries, unless they also add a module-info.class. So maybe we will need to do #3 for third-party libraries? For #2, maybe we don't have to go whole hog on adding mod

Re: [DISCUSS] permit-reflect vs --add-opens for Java 11 support

#3 first and then work towards #1, then #2. We can document what "--add-open" options needs to be added to start client if running with jdk11+ in the meantime. I also have reservations about how #4 works. If it works, it is a good alternation for #3. On Wed, Oct 10, 2018 at 2:23 PM Sai Boorlagad

Re: [DISCUSS] permit-reflect vs --add-opens for Java 11 support

+1 to Dan's idea if its possible. There is a maven plugin to invoke javac twice with respective java targets. https://maven.apache.org/plugins/maven-compiler-plugin/examples/module-info.html On Wed, Oct 10, 2018 at 1:52 PM Galen O'Sullivan wrote: > er, lost the end of that first sentence there

Re: [DISCUSS] permit-reflect vs --add-opens for Java 11 support

er, lost the end of that first sentence there. I think that reducing dependencies on Unsafe &c is a good goal regardless. On Wed, Oct 10, 2018 at 1:51 PM Galen O'Sullivan wrote: > #1 sounds awesome but may be unrealistic given our advertised feature set. > I think that reducing dependencies on U

Re: [DISCUSS] permit-reflect vs --add-opens for Java 11 support

#1 sounds awesome but may be unrealistic given our advertised feature set. I think that reducing dependencies on Unsafe &c If we can conditionally use Jigsaw modules for Java versions later than 8 while maintaining Java 8 compatiblity, that seems like the best solution. +2 to Dan's idea if it all

Re: [DISCUSS] permit-reflect vs --add-opens for Java 11 support

Here is a discussion from Google Guava project about compiling module-info.java in Java 9+ and including it in a jar with classes compiled for Java 8. https://github.com/google/guava/issues/2970 On Wed, Oct 10, 2018 at 1:39 PM Jacob Barrett wrote: > I like Dan’s idea! I would rather we work to

Re: [DISCUSS] permit-reflect vs --add-opens for Java 11 support

I like Dan’s idea! I would rather we work towards the correct solution. > On Oct 10, 2018, at 1:22 PM, Dan Smith wrote: > > #2 seems like the least hacky way to continue using things like > sun.misc.Unsafe. Could we just compile a module-info.java with Java 9 and > bundle it? This would also hel

Re: [DISCUSS] permit-reflect vs --add-opens for Java 11 support

Also, for #3, what does it look like to run a client application? IOW, what are the command-line arguments needed? Anthony > On Oct 10, 2018, at 1:29 PM, Anthony Baker wrote: > > Do you have a listed of restricted API’s that are used by Geode? Which > libraries used by Geode are affected?

Re: [DISCUSS] permit-reflect vs --add-opens for Java 11 support

Do you have a listed of restricted API’s that are used by Geode? Which libraries used by Geode are affected? Are these run-time only warnings or actual errors? Anthony > On Oct 10, 2018, at 12:20 PM, Owen Nichols wrote: > > Goal: > > Run Geode on Java 11 (GEODE-3 >

Re: [DISCUSS] permit-reflect vs --add-opens for Java 11 support

#2 seems like the least hacky way to continue using things like sun.misc.Unsafe. Could we just compile a module-info.java with Java 9 and bundle it? This would also help consumers of geode that want to use Java 9 modules. I'm a little bit sceptical of this permit-reflect libary, seeing as it's bee

Re: [DISCUSS] permit-reflect vs --add-opens for Java 11 support

I vote for #1, with #4 as a stopgap Isn't a goal of Java 11 support in Geode that we can use the new Java modules system? If so, let's actually try and get there. I think stability would actually improve by using public API instead of internals, and performance fears are just that: fears, until p