Project Jigsaw: Phase Two

[Mandy Chung]

On 7/9/2014 6:39 AM, Daniel Latrémolière wrote:
> 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)?

I'm glad that you brought this up.   Such reference card exists:
https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool

We're updating this wiki as we identify new noteworthy ones.

> ---
> 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?)

It's a good idea and I will include the simple instruction/link in the 
above wiki.

You can submit a RFE via the usual request channel:
    http://bugreport.java.com

Providing details and explanation of the use cases is important to help 
us evaluate the requests.

> 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 | 
> javax.xml.stream.XMLOutputFactory.setProperty(INDENT, true)

Is there a RFE for it?  If not, can you submit one?

> ----
> 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.)
>

That's a good point.  One usual way to provide experimental APIs is to 
make them available through OpenJDK projects and include them as 
exported APIs when it reaches the state to target to a specific JDK release.

Mandy