Re: [PROPOSAL] --add-opens for Java 11 support
Dan, are you saying we do or do not need --add-opens for reflection? The opens directive is for open up classes in its own modules for reflection. I don't think we can use that to open up jdk's packages, can we? On Fri, Nov 2, 2018 at 3:52 PM Dan Smith wrote: > I guess I'm ok with documenting the --add-opens workaround in the short > term, so that users can start playing with Geode on JDK 11. Maybe we should > indicate the JDK 11 support is experimental. I guess in addition to that, > we are going to document that users should put Geode on the classpath and > not the module path? Has anyone tested putting Geode on the module path? > > There are actually two ways to reserve a module name - you can create the > module-info.java, OR you can just add an Automatic-Module-Name header to > the your jar manifest. I think that would probably be the minimum we should > do before we start telling users to put geode on the module path. > > Regarding reflection - I don't think we don't need--add-opens for that. > Users just need to use the opens directive to mark their packages as > available for reflection. > > -Dan > > > On Fri, Nov 2, 2018 at 8:49 AM Jinmei Liao wrote: > > > Galen, you are right, --add-opens is necessary for accessing the private > > fields and methods when doing deep reflection which is used a lot in our > > serialization code. > > > > Let me step back and explain the scope of what we are trying to do here. > > We all know to be fully java11 compliant, we need to: > > 1. remove all the java internal API dependencies in geode itself > > 2. upgrade all the 3rd party libraries that was using java internal API > as > > well. > > 3. properly modularize geode and include module-info in the manifest. > > > > The bad news is: we are NOT doing any of them YET, and even if we > achieved > > all the above, from what I read, these "--add-opens" are still necessary > if > > we need to allow our code to do deep reflection at runtime. > > > > What we are trying to achieve here is: > > 1. get a green jdk11 pipeline up and running first. We need to be able to > > use jdk11 to run all our tests first, so that we can begin working on > the 3 > > things in the above list. > > 2. our users can download our code and starting running in jdk11 (with > some > > additional configuration of course), this way, we can get the community > to > > experiment with geode in jdk11 and improve upon it. > > > > We are only trying to discuss how to achieve the bottom 2 goals first > here. > > > > Cheers. > > > > On Thu, Nov 1, 2018 at 11:16 PM Galen O'Sullivan > > wrote: > > > > > I did a little more reading, and it sounds like we should create an > > > module-info.java to reserve the proper name for those customers who are > > > using Java 9+. See this article[1] for a description of what can go > wrong > > > if people start using the automatic package without us having declared > a > > > name. I think a module-info should be necessary for *any* level of Java > > 9+ > > > support. > > > > > > Jinmei, please correct me if I'm wrong here, but I believe --add-opens > is > > > necessary for the reflection that we use in PDX auto-serialization, and > > > probably elsewhere as well. This would make it necessary for any Java > > > program communicating with Geode that uses automatic serialization to > > have > > > --add-opens. I don't understand all that well what level of reflection > is > > > available in Java 11, but it will probably take quite a bit of time to > > do a > > > complete fix. > > > > > > +1 to this approach, provided we create a module-info.java > > > > > > [1]: > https://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html > > > > > > > > > On Thu, Nov 1, 2018 at 10:57 AM Jinmei Liao wrote: > > > > > > > And one disclaimer I have to add is that these "--add-opens" are the > > ones > > > > uncovered by our current set of tests, there might be more needed in > > > areas > > > > that are not covered by our tests. So to say the most, our current > > jdk11 > > > > support is still in beta mode. > > > > > > > > On Thu, Nov 1, 2018 at 10:33 AM Jinmei Liao > wrote: > > > > > > > > > 1) yes, gfsh script will need to be updated to add these > > > configurations. > > > > > 2) yes, these ad-opens are required to run geode clients as well. > We > > > will > > > > > need to document them. > > > > > > > > > > On Thu, Nov 1, 2018 at 10:31 AM Dan Smith > wrote: > > > > > > > > > >> A couple of questions: > > > > >> > > > > >> 1) Are you proposing changing gfsh start server to automatically > add > > > > these > > > > >> add-opens, or are you suggesting users will have to do that? > > > > >> 2) Are these add-opens required for running a geode client? > > > > >> > > > > >> -Dan > > > > >> > > > > >> On Thu, Nov 1, 2018 at 9:48 AM Patrick Rhomberg < > > prhomb...@apache.org > > > > > > > > >> wrote: > > > > >> > > > > >> > In case anyone else's email broke the thread, below is a link to > > the > > > > >> > previous thread in th
Re: [PROPOSAL] --add-opens for Java 11 support
Regarding -add-opens for reflection - I misunderstood. I thought you were saying we need --add-opens for *all* reflection. But it sounds like we are doing reflection on the JDK classes themselves. If that is the case I agree we need --add-opens until we fix that. -Dan On Mon, Nov 5, 2018 at 8:41 AM Jinmei Liao wrote: > Dan, are you saying we do or do not need --add-opens for reflection? The > opens directive is for open up classes in its own modules for reflection. I > don't think we can use that to open up jdk's packages, can we? > > On Fri, Nov 2, 2018 at 3:52 PM Dan Smith wrote: > > > I guess I'm ok with documenting the --add-opens workaround in the short > > term, so that users can start playing with Geode on JDK 11. Maybe we > should > > indicate the JDK 11 support is experimental. I guess in addition to that, > > we are going to document that users should put Geode on the classpath and > > not the module path? Has anyone tested putting Geode on the module path? > > > > There are actually two ways to reserve a module name - you can create the > > module-info.java, OR you can just add an Automatic-Module-Name header to > > the your jar manifest. I think that would probably be the minimum we > should > > do before we start telling users to put geode on the module path. > > > > Regarding reflection - I don't think we don't need--add-opens for that. > > Users just need to use the opens directive to mark their packages as > > available for reflection. > > > > -Dan > > > > > > On Fri, Nov 2, 2018 at 8:49 AM Jinmei Liao wrote: > > > > > Galen, you are right, --add-opens is necessary for accessing the > private > > > fields and methods when doing deep reflection which is used a lot in > our > > > serialization code. > > > > > > Let me step back and explain the scope of what we are trying to do > here. > > > We all know to be fully java11 compliant, we need to: > > > 1. remove all the java internal API dependencies in geode itself > > > 2. upgrade all the 3rd party libraries that was using java internal API > > as > > > well. > > > 3. properly modularize geode and include module-info in the manifest. > > > > > > The bad news is: we are NOT doing any of them YET, and even if we > > achieved > > > all the above, from what I read, these "--add-opens" are still > necessary > > if > > > we need to allow our code to do deep reflection at runtime. > > > > > > What we are trying to achieve here is: > > > 1. get a green jdk11 pipeline up and running first. We need to be able > to > > > use jdk11 to run all our tests first, so that we can begin working on > > the 3 > > > things in the above list. > > > 2. our users can download our code and starting running in jdk11 (with > > some > > > additional configuration of course), this way, we can get the community > > to > > > experiment with geode in jdk11 and improve upon it. > > > > > > We are only trying to discuss how to achieve the bottom 2 goals first > > here. > > > > > > Cheers. > > > > > > On Thu, Nov 1, 2018 at 11:16 PM Galen O'Sullivan < > gosulli...@pivotal.io> > > > wrote: > > > > > > > I did a little more reading, and it sounds like we should create an > > > > module-info.java to reserve the proper name for those customers who > are > > > > using Java 9+. See this article[1] for a description of what can go > > wrong > > > > if people start using the automatic package without us having > declared > > a > > > > name. I think a module-info should be necessary for *any* level of > Java > > > 9+ > > > > support. > > > > > > > > Jinmei, please correct me if I'm wrong here, but I believe > --add-opens > > is > > > > necessary for the reflection that we use in PDX auto-serialization, > and > > > > probably elsewhere as well. This would make it necessary for any Java > > > > program communicating with Geode that uses automatic serialization to > > > have > > > > --add-opens. I don't understand all that well what level of > reflection > > is > > > > available in Java 11, but it will probably take quite a bit of time > to > > > do a > > > > complete fix. > > > > > > > > +1 to this approach, provided we create a module-info.java > > > > > > > > [1]: > > https://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html > > > > > > > > > > > > On Thu, Nov 1, 2018 at 10:57 AM Jinmei Liao > wrote: > > > > > > > > > And one disclaimer I have to add is that these "--add-opens" are > the > > > ones > > > > > uncovered by our current set of tests, there might be more needed > in > > > > areas > > > > > that are not covered by our tests. So to say the most, our current > > > jdk11 > > > > > support is still in beta mode. > > > > > > > > > > On Thu, Nov 1, 2018 at 10:33 AM Jinmei Liao > > wrote: > > > > > > > > > > > 1) yes, gfsh script will need to be updated to add these > > > > configurations. > > > > > > 2) yes, these ad-opens are required to run geode clients as well. > > We > > > > will > > > > > > need to document them. > > > > > > > > > > > > On Thu, Nov 1, 2018 at
Re: Geode Native & Apache Geode 1.8 Release
geode-native should be ready to go now On Tue, Oct 30, 2018 at 2:56 PM Dave Barnes wrote: > unix_index.html and win_index.html cannot simply be removed, as they're > referenced by Cmake. I created a ticket to address this: > https://issues.apache.org/jira/browse/GEODE-5958. > > On Tue, Oct 30, 2018 at 11:48 AM Dave Barnes wrote: > > > Re: the docs links mentioned in Anthony's message: > > > > docs/README.md - the reference to the Geode CONTRIBUTE.md file is useful. > > I think we can assume that a user of the geode-native API will have a > Geode > > installation, too. > > docs/api/unix_index.html and docs/api/win_index.html - These files (and > > their bad links) are no longer needed and can be removed. > > > > On Tue, Oct 30, 2018 at 7:48 AM Anthony Baker wrote: > > > >> I ran rat manually and got this: > >> > >> Files with unapproved licenses: > >> > >> /geode/.cpackignore > >> /geode/.lcovrc > >> /geode/clicache/src/native_shared_ptr.hpp > >> /geode/templates/security/CMakeLists.txt.forInstall > >> > >> Shouldn’t these failures be causing travis to fail? > >> > >> Many of the files rat that marks as binary have this the annoying BOM > [1] > >> from visual studio. Seems like we should just remove those. That will > >> reveal a number of files that need a license header. > >> > >> What is this file? Seems to be binary content: > >> clicache/test/native_shared_ptrTests.cpp > >> > >> I also noticed this text that should be updated to point to where we > >> intend to host the documentation (on the geode website): > >> > >> docs/README.md:The Geode-Native repository provides the full source for > >> the Apache Geode Native Client User Guide in markdown format (see > >> _geode-project-dir_/geode-docs/CONTRIBUTE.md for more information on > how to > >> use markdown in this context). Users can build the markdown into an HTML > >> user guide using [Bookbinder](https://github.com/pivotal-cf/bookbinder) > >> and the instructions below. > >> docs/api/unix_index.html:Access documentation at http://docs-gemfire-nativeclient-develop.cfapps.io"; > >> target="_blank">Pivotal GemFire Native Client Documentation. > >> docs/api/win_index.html:Access documentation at http://docs-gemfire-nativeclient-develop.cfapps.io"; > >> target="_blank">Pivotal GemFire Native Client Documentation. > >> > >> > >> Anthony > >> > >> [1] https://en.wikipedia.org/wiki/Byte_order_mark > >> > >> > On Oct 29, 2018, at 12:11 PM, Jacob Barrett > >> wrote: > >> > > >> > There are a lot of files that rat is seeing as binary files and > ignoring > >> > the headers. Many of those files are not binary. Perhaps they have the > >> > wrong metadata associated with them in git as a result of bad commits. > >> We > >> > should clean all those files up so that rat is checking everything > >> > correctly. > >> > > >> > On Thu, Oct 18, 2018 at 3:41 PM Dan Smith wrote: > >> > > >> >> Following up on this - is there anything we still need to do before > we > >> cut > >> >> the 1.8 release branch in 2 weeks? > >> >> > >> >> Overall I think the native client source code looks like it's in good > >> shape > >> >> - we're running rat, the LICENSE and NOTICE look good, no binaries in > >> the > >> >> source, etc. > >> >> > >> >> For cutting the release branch, do we have criteria other than > passing > >> >> travis [1] ? > >> >> What will our release steps should look like for the native client - > >> just > >> >> tar up the source and sign it with gpg? > >> >> > >> >> If we can have this figured out ahead of time and at least > >> provisionally > >> >> added to the release steps [2] I think it will help this release go a > >> >> little smoother. > >> >> > >> >> [1] https://travis-ci.org/apache/geode-native/branches > >> >> [2] > >> >> > >> > https://cwiki.apache.org/confluence/display/GEODE/Releasing+Apache+Geode > >> >> > >> >> On Thu, Oct 11, 2018 at 3:23 PM Dan Smith wrote: > >> >> > >> >>> +1 for a source release. Awesome! > >> >>> > >> >>> -Dan > >> >>> > >> >>> On Thu, Oct 11, 2018 at 2:32 PM Michael Oleske > >> >> wrote: > >> >>> > >> Plus 1 for source release. Exciting times we live in! > >> > >> For verifying, plus one to a pipeline that's not just travis. > Though > >> they're instructions in the repo about how to run tests to get that > >> baseline confidence. > >> > >> -michael > >> > >> On Wednesday, October 10, 2018, Anilkumar Gingade < > >> aging...@pivotal.io> > >> wrote: > >> > >> > Good work team. > >> > +1 to get this as part of Geode 1.8 release. > >> > It will be good to see community taking advantage of this. And > >> >> building > >> new > >> > native client apps. > >> > I assume it will have all the docs about client-server > compatibility > >> > version info. And framework for backward compatibility testing > with > >> >> new > >> > geode releases. > >> > > >> > -Anil. > >> > > >> > > >> > > >> > On Wed,
