Re: Analysis of apache-tomcat-8.0.12 dependency on JDK-Internal APIs
Hi Mark, Did you get a chance to followup on the discussion on core-libs-dev@openjdk mailing list ? Rgds,Rory On 12/09/2014 11:11, dalibor topic wrote: On 11.09.2014 20:50, Mark Thomas wrote: The protection against JRE triggered memory leaks is a source of a lot of internal API usage: http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListener.java?view=annotate It would be great of there were public APIs we could use instead or better still if the various memory leaks could be fixed. Other than that, I can't think of any off-hand. Use the internal API is something we try to avoid if at all possible. Thanks, Mark - I think this discussion would warrant its own thread on the core-libs-dev@openjdk mailing list [1] - can you start a thread there? cheers, dalibor topic [1] http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Analysis of apache-tomcat-8.0.12 dependency on JDK-Internal APIs
Hi Mark, Thanks for the feedback, I will follow up on this. Rgds,Rory On 11/09/2014 19:50, Mark Thomas wrote: On 11/09/2014 14:59, Rory O'Donnell Oracle, Dublin Ireland wrote: Hi Mladen/Mark, 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], along with instructions on how to run the jdeps analysis tool yourself . We have analyzed jar files within apache-tomcat-8.0.12 and found 0 jar files depending on JDK-Internal APIs. However, jdeps is a static analysis tool and therefore use of JDK-internal APIs via reflection or dynamically generated bytecode are not reported by the tool, while such a dependency should also be replaced. If you have any feedback please reply either on this list or to me directly. We do make use JDK-Internal APIs but we always do it via reflection as it is nearly always vendor specific. The protection against JRE triggered memory leaks is a source of a lot of internal API usage: http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListener.java?view=annotate It would be great of there were public APIs we could use instead or better still if the various memory leaks could be fixed. Other than that, I can't think of any off-hand. Use the internal API is something we try to avoid if at all possible. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Analysis of apache-tomcat-8.0.12 dependency on JDK-Internal APIs
On 12/09/2014 11:11, dalibor topic wrote: On 11.09.2014 20:50, Mark Thomas wrote: The protection against JRE triggered memory leaks is a source of a lot of internal API usage: http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListener.java?view=annotate It would be great of there were public APIs we could use instead or better still if the various memory leaks could be fixed. Other than that, I can't think of any off-hand. Use the internal API is something we try to avoid if at all possible. Thanks, Mark - I think this discussion would warrant its own thread on the core-libs-dev@openjdk mailing list [1] - can you start a thread there? Will do. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Analysis of apache-tomcat-8.0.12 dependency on JDK-Internal APIs
Hi Mladen/Mark, 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], along with instructions on how to run the jdeps analysis tool yourself . We have analyzed jar files within apache-tomcat-8.0.12 and found 0 jar files depending on JDK-Internal APIs. However, jdeps is a static analysis tool and therefore use of JDK-internal APIs via reflection or dynamically generated bytecode are not reported by the tool, while such a dependency should also be replaced. If you have any feedback please reply either on this list or to me directly. 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 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Analysis of apache-tomcat-8.0.12 dependency on JDK-Internal APIs
On 11/09/2014 14:59, Rory O'Donnell Oracle, Dublin Ireland wrote: Hi Mladen/Mark, 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], along with instructions on how to run the jdeps analysis tool yourself . We have analyzed jar files within apache-tomcat-8.0.12 and found 0 jar files depending on JDK-Internal APIs. However, jdeps is a static analysis tool and therefore use of JDK-internal APIs via reflection or dynamically generated bytecode are not reported by the tool, while such a dependency should also be replaced. If you have any feedback please reply either on this list or to me directly. We do make use JDK-Internal APIs but we always do it via reflection as it is nearly always vendor specific. The protection against JRE triggered memory leaks is a source of a lot of internal API usage: http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListener.java?view=annotate It would be great of there were public APIs we could use instead or better still if the various memory leaks could be fixed. Other than that, I can't think of any off-hand. Use the internal API is something we try to avoid if at all possible. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
