Project Jigsaw: Phase Two

Daniel Latrémolière daniel.latremoliere at
Wed Jul 9 13:39:50 UTC 2014

Very interesting.

> [Security & maintainability] /Create proper public APIs for 
> commonly-used JDK-internal APIs/ --- Survey existing bodies of source 
> code to learn which JDK-internal APIs are commonly used and, where 
> feasible, create JDK-specific or possibly standard APIs to replace them.
Will a survey be sufficient? isn't it useful to produce a basic 
reference card for easier upgrading (like a wiki page mapping internal 
API to newly added public API)?
More precisely, can a new wiki page contains the steps for reporting 
request for enhancement of public API (where? Java bugs specially 
tagged? post on a forum?) and collect in a simple table the 
corresponding changes to allow developers to easily find equivalent 
feature to internal API when upgrading applications?

A simple example:
     One solution (without copying data or using an external library) 
for indenting a StAX XMLStreamWriter is the use of 
com.sun.xml.txw2.output.IndentingXMLStreamWriter [1,2].
     Having on a wiki page, a table with one row like following (if Java 
9 API add a new constant INDENT), would probably be a simple reference 
card but very useful for developers upgrading applications:
     com.sun.xml.txw2.output.IndentingXMLStreamWriter |, true)
NB: I hope that ahead-of-time compilation to native code (Graal?) will 
have API to allow developers to provide some guidance on best 
optimizations for their programs (when choice is not automatic between 
memory, performance, code expansion, startup time), even if this will 
probably be with a non-public API
(An useful non-public API will become, after some times in the wild to 
evolve and gain maturity, a future good public API.)

Thanks you,


More information about the jigsaw-dev mailing list