<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 20, 2016, at 12:15 PM, Jason Greene <<a href="mailto:jason.greene@redhat.com" class="">jason.greene@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Paul,<div class=""><br class=""></div><div class="">Yes we have had a few discussions about some of our usage with the Oracle JVM QE group. We have also provided some feedback at the JCP level. </div><div class=""><br class=""></div><div class="">To give one example, if you want to provide an alternative serialization mechanism (e.g. to customize the protocol for various reasons such as performance, modularity, security), yet still support the Java serialization API/contract, you have to be able to instantiate empty uninitialized classes. This is something that Java serialization implementation itself can’t work without, but the Java language is not intended to allow you to do. So the common solution that many projects do to achieve this, is to either use reflection internals or the Unsafe. Other examples typically involve the latter (e.g. custom concurrency prims)</div><div class=""><br class=""></div><div class="">So naturally there has been resistance to expose hooks such as this, which is why I predict they won’t be there in Java 9. I would love to be proven wrong though :)</div></div></div></blockquote><div><br class=""></div><div>Just to clarify, I predict they won’t be part of a public javax.xxx API. They will still be internally available since Java itself needs them (as do we). There has been mention of a flag to prevent removing visibility of these classes, as otherwise compatibility will most certainly be broken. That is what I expect we will require. </div><div><br class=""></div><div>That said, we should remove every occurrence that we don’t truly need. </div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 20, 2016, at 11:41 AM, Paul Benedict <<a href="mailto:pbenedict@apache.org" class="">pbenedict@apache.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Jason, have you considered reaching out to Oracle (or have already) to discuss what internal APIs have no public replacement? They are very receptive to that kind of feedback.<br class=""><div class="gmail_extra"><br clear="all" class=""><div class=""><div class="gmail_signature"><div dir="ltr" class=""><div class=""><div dir="ltr" class="">Cheers,<br class="">Paul</div></div></div></div></div>
<br class=""><div class="gmail_quote">On Wed, Jan 20, 2016 at 11:37 AM, Jason Greene <span dir="ltr" class=""><<a href="mailto:jason.greene@redhat.com" target="_blank" class="">jason.greene@redhat.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br class="">
> On Jan 20, 2016, at 11:12 AM, Tomasz Adamski <<a href="mailto:tadamski@redhat.com" class="">tadamski@redhat.com</a>> wrote:<br class="">
><br class="">
>> In a standalone scenario we are not using modules so the JVM would use<br class="">
>> rt.jar unless the user updates the bootclasspath. I do not see how it would<br class="">
>> be possible to avoid the jdeps warnings.<br class="">
><br class="">
> True, my mistake. I thought about a scenario in which despite using xbootclasspath we have some orb dependencies to JDK, but this obviously can only be tested on runtime which is not what jdeps does.<br class="">
<br class="">
While some thought on the feasibility of package renaming is progressing, I have an semi-important tangent (more to say in a subsequent follow-up). At one point we had a long term goal, or perhaps “hope” is more precise, that we would one day just be able to use the ORB in the JVM without shipping a downstream variant. That may very well become a possibility with virtually all known non-Oracle JVMs utilizing the openjdk lib, and thus the same impl.<br class="">
<br class="">
I take this means that Naryana requires references to non org.omg APIs, and thus if we remove them, this goal would no longer be possible.<br class="">
<br class="">
Note that with Java 9 internal APIs, I can pretty much guarantee that we are going to have to use whatever override flag they add for running WildFly/EAP, and certainly many other mainstream Java systems. We rely on those APIs, and there hasn’t been adequate replacement. I wonder if the linkage you refer to here doesn’t also fit this category.<br class="">
<br class="">
--<br class="">
Jason T. Greene<br class="">
WildFly Lead / JBoss EAP Platform Architect<br class="">
JBoss, a division of Red Hat<br class="">
<br class="">
<br class="">
_______________________________________________<br class="">
wildfly-dev mailing list<br class="">
<a href="mailto:wildfly-dev@lists.jboss.org" class="">wildfly-dev@lists.jboss.org</a><br class="">
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank" class="">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a></blockquote></div><br class=""></div></div>
</div></blockquote></div><br class=""><div class="">
--<br class="">Jason T. Greene<br class="">WildFly Lead / JBoss EAP Platform Architect<br class="">JBoss, a division of Red Hat
</div>
<br class=""></div></div></div></blockquote></div><br class=""><div class="">
--<br class="">Jason T. Greene<br class="">WildFly Lead / JBoss EAP Platform Architect<br class="">JBoss, a division of Red Hat
</div>
<br class=""></body></html>