Hi Alan, Regarding use of internal APIs - what is the plan for Unsafe? I recall some discussion about possibly making it a proper public API, but don't recall seeing anything finalized.
Thanks sent from my phone On Jun 23, 2015 7:10 AM, "Alan Bateman" <alan.bate...@oracle.com> wrote: > On 23/06/2015 10:34, Martijn Verburg wrote: > >> Hi all, >> >> As part of the Adoption Group we're planning on holding a Hackday in >> London >> for the July/Aug timeframe, primarily as an education/awareness piece >> around Jigsaw (there's lots to catch up on). >> >> Is there anything in particular you'd like a group of 'users'/developers >> to >> look at? I assume basing this off the latest jdk9 forest will be more >> stable than the jigsaw forest. >> >> I would expect/hope that JSR 376 will be further along by then so there > may be more to talk about and play with at this event. > > In the mean-time there is a lot to discuss and prepare. We've been warning > (and javac has emitted warnings) for many years that JDK-internal APIs will > not be accessible out of the box so anything that reduces or eliminates > dependences on internal APIs in popular libraries will be a big help. It > might be fun to use jdeps on the say the 20 most popular libraries to get a > feel for the problem. > > We've had the initial changes for JEP 220 in JDK 9 for about 6 months. > This is the JEP that changes the structure of the run-time images. This has > implications for tools (mostly) that have been used to directly accessing > rt.jar and other internal files in the legacy images. JEP 220 comes with a > supported interface for accessing classes and resources in the run-time > image so that may be worth spending time on. There is a refresh of this in > flight and it should be in by the time you have this event. It might be fun > to try out the top 20 tools and plugins to see if they run with JDK 9 and > maybe even hack on one or two of them to use the FileSystem API. > > Another idea is to look at the module graph in JEP 200, or better still, > the most up to date graph of modules in the JDK 9 forests. One idea is to > hack on make/Images.gmk in the top-level repository to force the JDK build > to produce run-time with a subset of the modules. The primitive image > building tool that this make file runs will be replaced by a linker tool in > time but there is enough to hack on to get a feel for the modules and what > might run (or not run) with a small set of modules. The module graph is > essentially an API so any feedback or usage of that API would be useful too. > > -Alan >
