commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rony G. Flatscher (Apache)" <r...@apache.org>
Subject Re: Apache Commons Configuration & Bean Scripting Framework (BSF) - dependencies on JDK-Internal APIs
Date Sat, 20 Jun 2015 16:27:55 GMT
Hi Rory,

just ran "jdeps -jdkinternals" on both, BSF 2.4.0 and BSF 3.1, both have no internal dependencies.

Best regards,

---rony



On 15.06.2015 14:19, Rony G. Flatscher (Apache) wrote:
> On 15.06.2015 10:04, Rory O'Donnell wrote:
>> Hi Benedict,
>>
>> I'm contacting you in relation to Apache Commons Configuration & Bean Scripting
Framework (BSF), 
>> both projects seems to be  very popular dependencies for other open source projects.
>>
>> As part of the preparations for JDK 9, Oracle’s engineers have been analyzing open
source projects
>> like yours to understand usage. One area of concern involves identifying compatibility
problems,
>> such as reliance on JDK-internal APIs.
>>
>> Our engineers have already prepared guidance on migrating some of the more common
usage patterns
>> of JDK-internal APIs to supported public interfaces.  The list is on the OpenJDK
wiki [0].
>>
>> As part of the ongoing development of JDK 9, I would like to inquire about your usage
of 
>> JDK-internal APIs and to encourage migration towards supported Java APIs if necessary.
>>
>> The first step is to identify if your application(s) is leveraging internal APIs.
>>
>> /Step 1: Download JDeps. /
>>
>>    Just download a preview release of JDK8(JDeps Download
>>    <https://jdk8.java.net/download.html>). You do not need to actually
>>    test or run your application on JDK8. JDeps(Docs
>>    <http://docs.oracle.com/javase/8/docs/technotes/tools/unix/jdeps.html>)
>>    looks through JAR files and identifies which JAR files use internal
>>    APIs and then lists those APIs.
>>
>> /Step 2: To run JDeps against an application/. The command looks like:
>>
>>    jdk8/bin/jdeps -P -jdkinternals *.jar > your-application.jdeps.txt
>>
>>    The output inside your-application.jdeps.txt will look like:
>>
>>    your.package (Filename.jar)
>>           -> com.sun.corba.se            JDK internal API (rt.jar)
>>
>> _3rd party library using Internal APIs:_
>> If your analysis uncovers a third-party component that you rely on, you can contact
the provider
>> and let them know of the upcoming changes. You can then either work with the provider
to get an
>> updated library that won't rely on Internal APIs, or you can find an alternative
provider for the
>> capabilities that the offending library provides.
>>
>> _Dynamic use of Internal APIs:_
>> JDeps can not detect dynamic use of internal APIs, for example through reflection,
service loaders
>> and similar mechanisms.
>>
>> Rgds,Rory
>>
>> [0] https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool
>>
> Maybe a few remarks: there are two different packages, one BSF 2.x and one BSF 3.x. BSF
2.x is an
> opensource scripting framework for Java, BSF 3.x is an Apache implementation of JSR-223
> (javax.script, which was influenced by BSF 2.x). The Java baseline is 1.4, if I am not
mistaken,
> such that pre Java 1.6 (when javax.script appeared for the first time) installations
could use
> either framework. BSF 3.x uses the package name "javax.script" such that starting with
Java 1.6, due
> to the class loading rules, the Java supplied "javax.script" will be found and used,
even if BSF 3
> is installed.
>
> Having said that, I would plan to analyze at least BSF 2.x (and also apply a few, "last"
updates,
> including supplying a "javax.script.BSF ScriptEngine" implementation to ease creating
a javax.script
> ScriptEngine for BSF 2.x script engines, as there may be som BSF 2.x scripting languages
that could
> be then deployed via the javax.script framework) with jdeps. In case it is using "JDK-internal
APIs"
> it will be interesting to learn whether (and how) one could use different APIs that are
available in
> the 1.4 world (unless we lift that baseline to Java 7 or 8).
>
> ---rony
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message