<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 20, 2016 at 5:37 PM, Jason Greene <span dir="ltr"><<a href="mailto:jason.greene@redhat.com" target="_blank">jason.greene@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br>
> On Jan 20, 2016, at 11:12 AM, Tomasz Adamski <<a href="mailto:tadamski@redhat.com">tadamski@redhat.com</a>> wrote:<br>
><br>
>> In a standalone scenario we are not using modules so the JVM would use<br>
>> rt.jar unless the user updates the bootclasspath. I do not see how it would<br>
>> be possible to avoid the jdeps warnings.<br>
><br>
> 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>
<br>
</span>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>
<br>
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></blockquote><div><br></div><div>We only access internal APIs in one place where we need to embed recovery information inside the (OTS) RecoveryCoordinator IOR. It is not clear to me how much rearchitecting would be required to come up with a different mechanism but I will think about it.</div><div><br></div><div>We are also investigating how to provide a JTS implementation without an ORB (<a href="https://issues.jboss.org/browse/JBTM-2103">https://issues.jboss.org/browse/JBTM-2103</a>). If we can make progress on that task then achieving your goal would still be feasible.</div><div><br></div><div>Mike</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
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>
<div class=""><div class="h5"><br>
--<br>
Jason T. Greene<br>
WildFly Lead / JBoss EAP Platform Architect<br>
JBoss, a division of Red Hat<br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div>Michael Musgrove</div><div>Transactions Team</div><div>e: <a href="mailto:mmusgrov@redhat.com" target="_blank">mmusgrov@redhat.com</a></div><div>t: +44 191 243 0870</div><div><br></div><div>Registered in England and Wales under Company Registration No. 03798903</div><div>Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson</div><div>(US), Charles Peters (US)</div><div><br></div><div>Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland)</div></div></div>
</div></div>