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
