You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-dev@xmlgraphics.apache.org by Rory O'Donnell <ro...@oracle.com> on 2016/03/31 10:07:59 UTC
Re: Batik dependencies on JDK-Internal APIs
Hi Luis,
It's been a while since we contacted you, I hope all is well. Did you
get a chance to look at the internal
dependencies on the com.sun.* packages ?
The module system was integrated into JDK 9 and is now available for
testing in early-access, with build 111.
We’ve defined a modular structure for the JDK (JEP 200
<http://openjdk.java.net/jeps/200>), reorganized the source code
according to that structure
(JEP 201 <http://openjdk.java.net/jeps/201>), and restructured the JDK
and JRE run-time images to support modules (JEP 220
<http://openjdk.java.net/jeps/220>). The last major component,
the module system itself (JSR 376
<http://openjdk.java.net/projects/jigsaw/spec/> and JEP 261
<http://openjdk.java.net/jeps/261>), was integrated into JDK 9 earlier
last week and is now available for testing
in early-access build 111 - here. <http://jdk9.java.net/download>
More information on Mark Reinhold's blog [1]
Rgds, Rory
Project Jigsaw <http://openjdk.java.net/projects/jigsaw/> is an enormous
effort, encompassing six JEPs
<http://openjdk.java.net/projects/jigsaw/#jeps> implemented by dozens of
engineers over many years. So far we’ve defined a modular structure for
the JDK (JEP 200 <http://openjdk.java.net/jeps/200>), reorganized the
source code according to that structure (JEP 201
<http://openjdk.java.net/jeps/201>), and restructured the JDK and JRE
run-time images to support modules (JEP 220
<http://openjdk.java.net/jeps/220>). The last major component, the
module system itself (JSR 376
<http://openjdk.java.net/projects/jigsaw/spec/> and JEP 261
<http://openjdk.java.net/jeps/261>), was integrated into JDK 9
<http://openjdk.java.net/projects/jdk9> earlier this week and is now
available for testing in early-access build 111
<http://jdk9.java.net/download>.
[1] http://mreinhold.org/blog/jigsaw-module-system
On 30/05/2015 11:21, Luis Bernardo wrote:
>
> Hi Rory,
>
> Thank you for your message.
>
> We know for a fact that Batik relies on com.sun.* packages (in
> particular com.sun.image.codec.* packages). I will run jdeps to see if
> I uncover more problems, but we already know we have a problem.
>
> The question is where we go from here. If I understand the point you
> are trying to communicate is that with JDK 9, Batik, as is right now
> with dependencies on com.sun.* packages, will not work anymore. And I
> think the goal of your message was to call our attention to this fact.
> So, we acknowledge here that we are aware of this looming problem.
>
> We will try to find bandwidth and resources to address this.
>
> Regards,
> Luis
>
>
> On 5/29/15 9:55 AM, Rory O'Donnell wrote:
>> Hi All,
>>
>> Is there someone who could help with this ?
>>
>> Rgds,Rory
>>
>> On 19/05/2015 14:33, Rory O'Donnell wrote:
>>> Hi All,
>>>
>>> My name is Rory O'Donnell, I am the OpenJDK Quality Group Lead.
>>>
>>> I'm contacting you because your open source project seems to be a
>>> very popular dependency 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
>>>
>>> --
>>> Rgds,Rory O'Donnell
>>> Quality Engineering Manager
>>> Oracle EMEA , Dublin, Ireland
>>
>> --
>> Rgds,Rory O'Donnell
>> Quality Engineering Manager
>> Oracle EMEA , Dublin, Ireland
>
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
Re: Batik dependencies on JDK-Internal APIs
Posted by Rory O'Donnell <ro...@oracle.com>.
Hi Simon,
Could I ask you to post your query on
http://mail.openjdk.java.net/pipermail/jigsaw-dev/ ?
If you haven’t already subscribed to a list then please do so first,
otherwise your message will
be discarded as spam.
Rgds,Rory
On 15/04/2016 13:03, Simon Steiner wrote:
>
> Hi,
>
> I have started testing Java 9:
>
> I am setting -Djava.specification.version=1.9 so imageio can keep working.
>
> I get Cipher.getInstance("AES/CBC/NoPadding") not found
>
> Also:
>
> java.lang.IllegalStateException: getOutput() == null!
>
> at
> com.sun.imageio.plugins.tiff.TIFFImageWriter.prepareWriteSequence(java.desktop@9-ea/TIFFImageWriter.java:2623
> <mailto:java.desktop@9-ea/TIFFImageWriter.java:2623>)
>
> I am not sure how to load jar’s at runtime:
>
> No signature of method:
> jdk.internal.loader.ClassLoaders$AppClassLoader.addURL() is applicable
> for argument types: (java.net.URL)
>
> I raised:
>
> https://github.com/levigo/jbig2-imageio/issues/10
>
> https://github.com/jai-imageio/jai-imageio-core/issues/24
>
> https://issues.apache.org/jira/browse/PDFBOX-3313
>
> Thanks
>
> *From:*Rory O'Donnell [mailto:rory.odonnell@oracle.com]
> *Sent:* 15 April 2016 12:53
> *To:* Simon Steiner <ss...@thunderhead.com>;
> batik-dev@xmlgraphics.apache.org; Luis Bernardo
> <lm...@gmail.com>; Dalibor Topic <da...@oracle.com>;
> Balchandra Vaidya <ba...@oracle.com>; Muneer Kolarkunnu
> <ab...@oracle.com>
> *Cc:* rory.odonnell@oracle.com
> *Subject:* Re: Batik dependencies on JDK-Internal APIs
>
> **************************************
> This message originates from outside our organisation. Consider
> carefully whether you should click on any links, open any attachments
> or reply. If in doubt, forward to ~ ITrequests
> **************************************
>
> Hi Luis,
>
> Thanks for the update !
>
> We are very interested in hearing your experiences in testing any
> Early Access builds. Have you have begun testing against
> JDK 9 and or JDK 9 with Project Jigsaw EA builds, have you uncovered
> showstopper issues that you would like to discuss?
> We would really like to hear your findings so far, either reply to me
> or via the mailing lists [1], [2].
>
> Early Access b113 <https://jdk9.java.net/download/> for JDK 9 is
> available on java.net, summary of changes are listed here
> <http://download.java.net/java/jdk9/changes/jdk-9+113.html>.
>
> Early Access b113 <https://jdk9.java.net/jigsaw/> (#4664) for JDK 9
> with Project Jigsaw is available on java.net.
>
> * The important change in this build is that root modules when
> compiling code in the unnamed module, or when running and the main
> class is loaded from the class path, do not include the EE
> modules. More on this in JEP 261.
> * The other change in this build is that the -Xpatch option is now
> aligned with what we have documented in JEP 261, support for the
> old form has been removed.
>
>
> Rgds,Rory
>
> [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/
> [2] http://mail.openjdk.java.net/pipermail/jdk9-dev/
>
>
> On 15/04/2016 12:25, Simon Steiner wrote:
>
> Hi,
>
> I've removed these classes since they were not being used anymore.
>
> Thanks
>
> -------- Forwarded Message --------
>
> Subject: Re: Batik dependencies on JDK-Internal APIs
>
> Date: Thu, 31 Mar 2016 09:07:59 +0100
>
> From: Rory O'Donnell<ro...@oracle.com> <ma...@oracle.com>
>
> Reply-To:batik-dev@xmlgraphics.apache.org
> <ma...@xmlgraphics.apache.org>
>
> To: Luis Bernardo<lm...@gmail.com> <ma...@gmail.com>,
>
> batik-dev@xmlgraphics.apache.org
> <ma...@xmlgraphics.apache.org>
>
> CC:rory.odonnell@oracle.com <ma...@oracle.com>, Dalibor Topic<da...@oracle.com> <ma...@oracle.com>,
>
> Balchandra Vaidya<ba...@oracle.com> <ma...@oracle.com>, Muneer Kolarkunnu<ab...@oracle.com> <ma...@oracle.com>
>
> Hi Luis,
>
> It's been a while since we contacted you, I hope all is well. Did you get a chance to look at the internal dependencies on the com.sun.* packages ?
>
> The module system was integrated into JDK 9 and is now available for testing in early-access, with build 111.
>
> We’ve defined a modular structure for the JDK (JEP 200<http://openjdk.java.net/jeps/200> <http://openjdk.java.net/jeps/200>), reorganized the source code according to that structure (JEP 201<http://openjdk.java.net/jeps/201> <http://openjdk.java.net/jeps/201>), and restructured the JDK and JRE run-time images to support modules (JEP 220<http://openjdk.java.net/jeps/220> <http://openjdk.java.net/jeps/220>). The last major component, the module system itself (JSR 376<http://openjdk.java.net/projects/jigsaw/spec/>
> <http://openjdk.java.net/projects/jigsaw/spec/> and JEP 261<http://openjdk.java.net/jeps/261> <http://openjdk.java.net/jeps/261>), was integrated into JDK 9 earlier last week and is now available for testing in early-access b!
>
> uild 111 -
>
> here.<http://jdk9.java.net/download> <http://jdk9.java.net/download>
>
> More information on Mark Reinhold's blog [1]
>
> Rgds, Rory
>
> Project Jigsaw<http://openjdk.java.net/projects/jigsaw/>
> <http://openjdk.java.net/projects/jigsaw/> is an enormous effort, encompassing six JEPs<http://openjdk.java.net/projects/jigsaw/#jeps>
> <http://openjdk.java.net/projects/jigsaw/#jeps> implemented by dozens of engineers over many years. So far we’ve defined a modular structure for the JDK (JEP 200<http://openjdk.java.net/jeps/200> <http://openjdk.java.net/jeps/200>), reorganized the source code according to that structure (JEP 201<http://openjdk.java.net/jeps/201> <http://openjdk.java.net/jeps/201>), and restructured the JDK and JRE run-time images to support modules (JEP 220<http://openjdk.java.net/jeps/220> <http://openjdk.java.net/jeps/220>). The last major component, the mod!
>
> ule system
>
> itself (JSR 376<http://openjdk.java.net/projects/jigsaw/spec/>
> <http://openjdk.java.net/projects/jigsaw/spec/> and JEP 261<http://openjdk.java.net/jeps/261> <http://openjdk.java.net/jeps/261>), was integrated into JDK 9<http://openjdk.java.net/projects/jdk9>
> <http://openjdk.java.net/projects/jdk9> earlier this week and is now available for testing in early-access build 111<http://jdk9.java.net/download> <http://jdk9.java.net/download>.
>
> [1]http://mreinhold.org/blog/jigsaw-module-system
>
> On 30/05/2015 11:21, Luis Bernardo wrote:
>
> Hi Rory,
>
> Thank you for your message.
>
> We know for a fact that Batik relies on com.sun.* packages (in
>
> particular com.sun.image.codec.* packages). I will run jdeps to see if
>
> I uncover more problems, but we already know we have a problem.
>
> The question is where we go from here. If I understand the point you
>
> are trying to communicate is that with JDK 9, Batik, as is right now
>
> with dependencies on com.sun.* packages, will not work anymore. And I
>
> think the goal of your message was to call our attention to this fact.
>
> So, we acknowledge here that we are aware of this looming problem.
>
> We will try to find bandwidth and resources to address this.
>
> Regards,
>
> Luis
>
> On 5/29/15 9:55 AM, Rory O'Donnell wrote:
>
> Hi All,
>
> Is there someone who could help with this ?
>
> Rgds,Rory
>
> On 19/05/2015 14:33, Rory O'Donnell wrote:
>
> Hi All,
>
> My name is Rory O'Donnell, I am the OpenJDK Quality Group Lead.
>
> I'm contacting you because your open source project seems to be a
>
> very popular dependency 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>
> <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>
> <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
>
> --
>
> Rgds,Rory O'Donnell
>
> Quality Engineering Manager
>
> Oracle EMEA , Dublin, Ireland
>
> --
>
> Rgds,Rory O'Donnell
>
> Quality Engineering Manager
>
> Oracle EMEA , Dublin, Ireland
>
> --
>
> Rgds,Rory O'Donnell
>
> Quality Engineering Manager
>
> Oracle EMEA , Dublin, Ireland
>
> Simon Steiner
>
> Developer
>
> Smart Communications Division<http://www.thunderhead.com/smart-communications>
> <http://www.thunderhead.com/smart-communications>
>
> T +44 20 8238 7464
>
> M
>
> ssteiner@thunderhead.com <ma...@thunderhead.com>
>
> [https://www.thunderhead.com/uploads/2016/02/email-footer-banner-SC.png]<http://www.thunderhead.com/smart-communications>
> <http://www.thunderhead.com/smart-communications>
>
> Smart Communications is a trading name of Thunderhead Limited which is registered in England under No. 4303041 whose registered office is at Ingeni Building, 17 Broadwick Street, Soho, London. W1F 0DJ.
>
> The contents of this e-mail are intended for the named addressee only. It contains confidential information. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.
>
>
>
> --
> Rgds,Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA , Dublin, Ireland
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
RE: Batik dependencies on JDK-Internal APIs
Posted by Simon Steiner <si...@gmail.com>.
Hi,
I have started testing Java 9:
I am setting -Djava.specification.version=1.9 so imageio can keep working.
I get Cipher.getInstance("AES/CBC/NoPadding") not found
Also:
java.lang.IllegalStateException: getOutput() == null!
at com.sun.imageio.plugins.tiff.TIFFImageWriter.prepareWriteSequence(java.desktop@9-ea/TIFFImageWriter.java:2623 <mailto:java.desktop@9-ea/TIFFImageWriter.java:2623> )
I am not sure how to load jar’s at runtime:
No signature of method: jdk.internal.loader.ClassLoaders$AppClassLoader.addURL() is applicable for argument types: (java.net.URL)
I raised:
https://github.com/levigo/jbig2-imageio/issues/10
https://github.com/jai-imageio/jai-imageio-core/issues/24
https://issues.apache.org/jira/browse/PDFBOX-3313
Thanks
From: Rory O'Donnell [mailto:rory.odonnell@oracle.com]
Sent: 15 April 2016 12:53
To: Simon Steiner <ss...@thunderhead.com>; batik-dev@xmlgraphics.apache.org; Luis Bernardo <lm...@gmail.com>; Dalibor Topic <da...@oracle.com>; Balchandra Vaidya <ba...@oracle.com>; Muneer Kolarkunnu <ab...@oracle.com>
Cc: rory.odonnell@oracle.com
Subject: Re: Batik dependencies on JDK-Internal APIs
**************************************
This message originates from outside our organisation. Consider carefully whether you should click on any links, open any attachments or reply. If in doubt, forward to ~ ITrequests
**************************************
Hi Luis,
Thanks for the update !
We are very interested in hearing your experiences in testing any Early Access builds. Have you have begun testing against
JDK 9 and or JDK 9 with Project Jigsaw EA builds, have you uncovered showstopper issues that you would like to discuss?
We would really like to hear your findings so far, either reply to me or via the mailing lists [1], [2].
Early Access b113 <https://jdk9.java.net/download/> for JDK 9 is available on java.net, summary of changes are listed here <http://download.java.net/java/jdk9/changes/jdk-9+113.html> .
Early Access b113 <https://jdk9.java.net/jigsaw/> (#4664) for JDK 9 with Project Jigsaw is available on java.net.
* The important change in this build is that root modules when compiling code in the unnamed module, or when running and the main class is loaded from the class path, do not include the EE modules. More on this in JEP 261.
* The other change in this build is that the -Xpatch option is now aligned with what we have documented in JEP 261, support for the old form has been removed.
Rgds,Rory
[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/
[2] http://mail.openjdk.java.net/pipermail/jdk9-dev/
On 15/04/2016 12:25, Simon Steiner wrote:
Hi,
I've removed these classes since they were not being used anymore.
Thanks
-------- Forwarded Message --------
Subject: Re: Batik dependencies on JDK-Internal APIs
Date: Thu, 31 Mar 2016 09:07:59 +0100
From: Rory O'Donnell <ma...@oracle.com> <ro...@oracle.com>
Reply-To: batik-dev@xmlgraphics.apache.org <ma...@xmlgraphics.apache.org>
To: Luis Bernardo <ma...@gmail.com> <lm...@gmail.com>,
batik-dev@xmlgraphics.apache.org <ma...@xmlgraphics.apache.org>
CC: rory.odonnell@oracle.com <ma...@oracle.com> , Dalibor Topic <ma...@oracle.com> <da...@oracle.com>,
Balchandra Vaidya <ma...@oracle.com> <ba...@oracle.com>, Muneer Kolarkunnu <ma...@oracle.com> <ab...@oracle.com>
Hi Luis,
It's been a while since we contacted you, I hope all is well. Did you get a chance to look at the internal dependencies on the com.sun.* packages ?
The module system was integrated into JDK 9 and is now available for testing in early-access, with build 111.
We’ve defined a modular structure for the JDK (JEP 200 <http://openjdk.java.net/jeps/200> <http://openjdk.java.net/jeps/200>), reorganized the source code according to that structure (JEP 201 <http://openjdk.java.net/jeps/201> <http://openjdk.java.net/jeps/201>), and restructured the JDK and JRE run-time images to support modules (JEP 220 <http://openjdk.java.net/jeps/220> <http://openjdk.java.net/jeps/220>). The last major component, the module system itself (JSR 376 <http://openjdk.java.net/projects/jigsaw/spec/> <http://openjdk.java.net/projects/jigsaw/spec/> and JEP 261 <http://openjdk.java.net/jeps/261> <http://openjdk.java.net/jeps/261>), was integrated into JDK 9 earlier last week and is now available for testing in early-access b!
uild 111 -
here. <http://jdk9.java.net/download> <http://jdk9.java.net/download>
More information on Mark Reinhold's blog [1]
Rgds, Rory
Project Jigsaw <http://openjdk.java.net/projects/jigsaw/> <http://openjdk.java.net/projects/jigsaw/> is an enormous effort, encompassing six JEPs <http://openjdk.java.net/projects/jigsaw/#jeps> <http://openjdk.java.net/projects/jigsaw/#jeps> implemented by dozens of engineers over many years. So far we’ve defined a modular structure for the JDK (JEP 200 <http://openjdk.java.net/jeps/200> <http://openjdk.java.net/jeps/200>), reorganized the source code according to that structure (JEP 201 <http://openjdk.java.net/jeps/201> <http://openjdk.java.net/jeps/201>), and restructured the JDK and JRE run-time images to support modules (JEP 220 <http://openjdk.java.net/jeps/220> <http://openjdk.java.net/jeps/220>). The last major component, the mod!
ule system
itself (JSR 376 <http://openjdk.java.net/projects/jigsaw/spec/> <http://openjdk.java.net/projects/jigsaw/spec/> and JEP 261 <http://openjdk.java.net/jeps/261> <http://openjdk.java.net/jeps/261>), was integrated into JDK 9 <http://openjdk.java.net/projects/jdk9> <http://openjdk.java.net/projects/jdk9> earlier this week and is now available for testing in early-access build 111 <http://jdk9.java.net/download> <http://jdk9.java.net/download>.
[1] http://mreinhold.org/blog/jigsaw-module-system
On 30/05/2015 11:21, Luis Bernardo wrote:
Hi Rory,
Thank you for your message.
We know for a fact that Batik relies on com.sun.* packages (in
particular com.sun.image.codec.* packages). I will run jdeps to see if
I uncover more problems, but we already know we have a problem.
The question is where we go from here. If I understand the point you
are trying to communicate is that with JDK 9, Batik, as is right now
with dependencies on com.sun.* packages, will not work anymore. And I
think the goal of your message was to call our attention to this fact.
So, we acknowledge here that we are aware of this looming problem.
We will try to find bandwidth and resources to address this.
Regards,
Luis
On 5/29/15 9:55 AM, Rory O'Donnell wrote:
Hi All,
Is there someone who could help with this ?
Rgds,Rory
On 19/05/2015 14:33, Rory O'Donnell wrote:
Hi All,
My name is Rory O'Donnell, I am the OpenJDK Quality Group Lead.
I'm contacting you because your open source project seems to be a
very popular dependency 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> <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> <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
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
Simon Steiner
Developer
Smart Communications Division <http://www.thunderhead.com/smart-communications> <http://www.thunderhead.com/smart-communications>
T +44 20 8238 7464
M
ssteiner@thunderhead.com <ma...@thunderhead.com>
[https://www.thunderhead.com/uploads/2016/02/email-footer-banner-SC.png] <http://www.thunderhead.com/smart-communications> <http://www.thunderhead.com/smart-communications>
Smart Communications is a trading name of Thunderhead Limited which is registered in England under No. 4303041 whose registered office is at Ingeni Building, 17 Broadwick Street, Soho, London. W1F 0DJ.
The contents of this e-mail are intended for the named addressee only. It contains confidential information. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
Re: Batik dependencies on JDK-Internal APIs
Posted by Rory O'Donnell <ro...@oracle.com>.
Hi Luis,
Thanks for the update !
We are very interested in hearing your experiences in testing any Early
Access builds. Have you have begun testing against
JDK 9 and or JDK 9 with Project Jigsaw EA builds, have you uncovered
showstopper issues that you would like to discuss?
We would really like to hear your findings so far, either reply to me or
via the mailing lists [1], [2].
Early Access b113 <https://jdk9.java.net/download/> for JDK 9 is
available on java.net, summary of changes are listed here
<http://download.java.net/java/jdk9/changes/jdk-9+113.html>.
Early Access b113 <https://jdk9.java.net/jigsaw/> (#4664) for JDK 9 with
Project Jigsaw is available on java.net.
* The important change in this build is that root modules when
compiling code in the unnamed module, or when running and the main
class is loaded from the class path, do not include the EE modules.
More on this in JEP 261.
* The other change in this build is that the -Xpatch option is now
aligned with what we have documented in JEP 261, support for the old
form has been removed.
Rgds,Rory
[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/
[2] http://mail.openjdk.java.net/pipermail/jdk9-dev/
On 15/04/2016 12:25, Simon Steiner wrote:
> Hi,
>
> I've removed these classes since they were not being used anymore.
>
> Thanks
>
> -------- Forwarded Message --------
> Subject: Re: Batik dependencies on JDK-Internal APIs
> Date: Thu, 31 Mar 2016 09:07:59 +0100
> From: Rory O'Donnell <ro...@oracle.com>
> Reply-To: batik-dev@xmlgraphics.apache.org
> To: Luis Bernardo <lm...@gmail.com>,
> batik-dev@xmlgraphics.apache.org
> CC: rory.odonnell@oracle.com, Dalibor Topic <da...@oracle.com>,
> Balchandra Vaidya <ba...@oracle.com>, Muneer Kolarkunnu <ab...@oracle.com>
>
>
>
> Hi Luis,
>
> It's been a while since we contacted you, I hope all is well. Did you get a chance to look at the internal dependencies on the com.sun.* packages ?
>
> The module system was integrated into JDK 9 and is now available for testing in early-access, with build 111.
>
> We’ve defined a modular structure for the JDK (JEP 200 <http://openjdk.java.net/jeps/200>), reorganized the source code according to that structure (JEP 201 <http://openjdk.java.net/jeps/201>), and restructured the JDK and JRE run-time images to support modules (JEP 220 <http://openjdk.java.net/jeps/220>). The last major component, the module system itself (JSR 376 <http://openjdk.java.net/projects/jigsaw/spec/> and JEP 261 <http://openjdk.java.net/jeps/261>), was integrated into JDK 9 earlier last week and is now available for testing in early-access build 111 - here. <http://jdk9.java.net/download>
>
> More information on Mark Reinhold's blog [1]
>
> Rgds, Rory
>
> Project Jigsaw <http://openjdk.java.net/projects/jigsaw/> is an enormous effort, encompassing six JEPs <http://openjdk.java.net/projects/jigsaw/#jeps> implemented by dozens of engineers over many years. So far we’ve defined a modular structure for the JDK (JEP 200 <http://openjdk.java.net/jeps/200>), reorganized the source code according to that structure (JEP 201 <http://openjdk.java.net/jeps/201>), and restructured the JDK and JRE run-time images to support modules (JEP 220 <http://openjdk.java.net/jeps/220>). The last major component, the module system itself (JSR 376 <http://openjdk.java.net/projects/jigsaw/spec/> and JEP 261 <http://openjdk.java.net/jeps/261>), was integrated into JDK 9 <http://openjdk.java.net/projects/jdk9> earlier this week and is now available for testing in early-access build 111 <http://jdk9.java.net/download>.
> [1] http://mreinhold.org/blog/jigsaw-module-system
>
>
> On 30/05/2015 11:21, Luis Bernardo wrote:
>> Hi Rory,
>>
>> Thank you for your message.
>>
>> We know for a fact that Batik relies on com.sun.* packages (in
>> particular com.sun.image.codec.* packages). I will run jdeps to see if
>> I uncover more problems, but we already know we have a problem.
>>
>> The question is where we go from here. If I understand the point you
>> are trying to communicate is that with JDK 9, Batik, as is right now
>> with dependencies on com.sun.* packages, will not work anymore. And I
>> think the goal of your message was to call our attention to this fact.
>> So, we acknowledge here that we are aware of this looming problem.
>>
>> We will try to find bandwidth and resources to address this.
>>
>> Regards,
>> Luis
>>
>>
>> On 5/29/15 9:55 AM, Rory O'Donnell wrote:
>>> Hi All,
>>>
>>> Is there someone who could help with this ?
>>>
>>> Rgds,Rory
>>>
>>> On 19/05/2015 14:33, Rory O'Donnell wrote:
>>>> Hi All,
>>>>
>>>> My name is Rory O'Donnell, I am the OpenJDK Quality Group Lead.
>>>>
>>>> I'm contacting you because your open source project seems to be a
>>>> very popular dependency 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
>>>>
>>>> --
>>>> Rgds,Rory O'Donnell
>>>> Quality Engineering Manager
>>>> Oracle EMEA , Dublin, Ireland
>>> --
>>> Rgds,Rory O'Donnell
>>> Quality Engineering Manager
>>> Oracle EMEA , Dublin, Ireland
> --
> Rgds,Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA , Dublin, Ireland
>
>
>
> Simon Steiner
> Developer
> Smart Communications Division <http://www.thunderhead.com/smart-communications>
> T +44 20 8238 7464
> M
> ssteiner@thunderhead.com
>
> [https://www.thunderhead.com/uploads/2016/02/email-footer-banner-SC.png] <http://www.thunderhead.com/smart-communications>
>
> Smart Communications is a trading name of Thunderhead Limited which is registered in England under No. 4303041 whose registered office is at Ingeni Building, 17 Broadwick Street, Soho, London. W1F 0DJ.
>
> The contents of this e-mail are intended for the named addressee only. It contains confidential information. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.
>
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland