Karen, Sorry for delay. I was on vacation last week.
I plan to review the changes tomorrow. -Dmitry On 2016-11-28 17:47, Karen Kinnear wrote: > Alan, > > I reviewed all the hotspot runtime changes > - except the tests (Christian will review those) > - and jvmti - which Dmitry Samersoff will review. > > They look good. > > thanks, > Karen > >> On Nov 28, 2016, at 9:32 AM, Lois Foltan <lois.fol...@oracle.com> wrote: >> >> Hi Alan, >> >> I have reviewed the hotspot changes and they look good. Minor nit, >> src/share/vm/classfile/javaClasses.cpp only differs by the addition of a >> blank line. >> >> Thanks, >> Lois >> >> On 11/24/2016 10:25 AM, Alan Bateman wrote: >>> Folks on jigsaw-dev will know that we are on a mission to bring the changes >>> accumulated in the jake forest to jdk9/dev. We can think of this as a >>> refresh of the module system in JDK 9, the last big refresh was in May with >>> many small updates since then. >>> >>> The focus this time is to bring the changes that are tied to JSR issues >>> into jdk9/dev, specifically the issues that are tracked on the JSR issues >>> list [1] as: >>> >>> #CompileTimeDependences >>> #AddExportsInManifest >>> #ClassFileModuleName >>> #ClassFileAccPublic >>> #ServiceLoaderEnhancements >>> #ResourceEncapsulation/#ClassFilesAsResources >>> #ReflectiveAccessToNonExportedTypes >>> #AwkwardStrongEncapsulation >>> #ReadabilityAddedByLayerCreator >>> #IndirectQualifiedReflectiveAccess (partial) >>> #VersionsInModuleNames >>> #NonHierarchicalLayers >>> #ModuleAnnotations/#ModuleDeprecation >>> #ReflectiveAccessByInstrumentationAgents >>> >>> Some of these issues are not "Resolved" yet, meaning there is still ongoing >>> discussion on the EG mailing list. That is okay, there is nothing final >>> here. If there are changes to these proposals then the implementation >>> changes will follow. Also, as I said in a mail to jigsaw-dev yesterday [2], >>> is that we will keep the jake forest open for ongoing prototyping and >>> iteration, also ongoing implementation improvements where iteration or bake >>> time is important. >>> >>> For the code review then the focus is therefore on sanity checking the >>> changes that we would like to bring into jdk9/dev. We will not use this >>> review thread to debate alternative designs or other big implementation >>> changes that are more appropriate to bake in jake. >>> >>> To get going, I've put the webrevs with a snapshot of the changes in jake >>> here: >>> http://cr.openjdk.java.net/~alanb/8169069/0/ >>> >>> The changes are currently sync'ed against jdk-9+146 and will be rebased >>> (and re-tested) against jdk9/dev prior to integration. There are a number >>> of small changes that need to be added to this in the coming days, I will >>> refresh the webrev every few days to take account of these updates. >>> >>> >>> A few important points to mention, even if you aren't reviewing the changes: >>> >>> 1. This refresh requires a new version of jtreg to run the tests. The >>> changes for this new version are in the code-tools/jtreg repository and the >>> plan is to tag a new build (jtreg4.2-b04) next week. Once the tag has been >>> added then we'll update the requiredVersion property in each TEST.ROOT to >>> force everyone to update. >>> >>> 2. For developers trying out modules with the main line JDK 9 builds then >>> be aware that `requires public` changes to `requires transitive` and the >>> `provides` clause changes to require all providers for a specific service >>> type to be in the same clause. Also be aware that the binary form of the >>> module declaration (module-info.class) changes so you will need to >>> recompile any modules. >>> >>> 3. Those running existing code on JDK 9 and ignoring modules will need to >>> be aware of a disruptive change in this refresh. The disruptive change is >>> #AwkwardStrongEncapsulation where setAccessible(true) is changed so that it >>> can't be used to break into non-public fields/methods of JDK classes. This >>> change is going to expose a lot of hacks in existing code. We plan to send >>> mail to jdk9-dev in advance of this integration to create awareness of this >>> change. As per the original introduction of strong encapsulation then >>> command line options (and now the manifest of application JAR files) can be >>> used to keep existing code working. The new option is `--add-opens` to open >>> a package in a module for deep reflection by other modules. As an example, >>> if you find yourself with code that hacks into the private `comparator` >>> field in java.util.TreeMap then running with `--add-opens >>> java.base/java.util=ALL-UNNAMED` will keep that code working. >>> >>> >>> A few miscellaneous notes for those that are reviewing: >>> >>> 1. We have some temporary/transition code in the top-level repo to deal >>> with the importing of the JavaFX modules. This will be removed once the >>> changes are in JDK 9 for the OpenJFX project to use. >>> >>> 2. In the jdk repo then it's important to understand that the module system >>> is initialized at startup and there are many places where we need to keep >>> startup performance in mind. This sometimes means less elegant code than >>> might be used if startup wasn't such a big concern. >>> >>> 3. The changes in the jaxws repo make use of new APIs that means the code >>> doesn't compile with JDK 7 or JDK 8. Our intention is to work with the JAXB >>> and JAX-WS maintainers to address the issues in the upstream project and >>> then bring those changes into jdk9/dev to replace the patches that we are >>> forced to push for the short term. >>> >>> 4. You will see several tests where the value of the @modules tag has >>> `:open` or `:+open`. This is new jtreg speak. The former means the test is >>> run with --add-opens to open the package, the latter means the test is >>> exported at compile-time and exported + open at run-time (the latter usage >>> will be rare, it's where tests have static references to JDK internal types >>> and are also doing deep reflection with setAccessible). >>> >>> >>> In terms of dates then we are aiming to integrate these changes into >>> jdk9/dev in early December. I will send a follow-up mail next week on this >>> as we work through the logistics. >>> >>> -Alan >>> >>> [1] http://openjdk.java.net/projects/jigsaw/spec/issues/ >>> [2] >>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-November/010219.html >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources.
