<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 11:56 AM, Michael Musgrove <<a href="mailto:mmusgrov@redhat.com" class="">mmusgrov@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Jan 20, 2016 at 5:37 PM, 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-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><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="">
</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 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=""></blockquote><div class=""><br class=""></div><div class="">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></div></div></div></blockquote><div><br class=""></div><div>Ah yes. </div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">We are also investigating how to provide a JTS implementation without an ORB (<a href="https://issues.jboss.org/browse/JBTM-2103" class="">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></div></div></div></blockquote><div><br class=""></div><div>Well, to be honest, even the word “hope” might have been too strong. It’s more like “pipe-dream”. There is still a lot of advantages with having our own downstream, we can patch issues that haven’t been fixed in the official JDK release stream, for example.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">Mike</div><div class=""> </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 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="">
<div class=""><div class="h5"><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="">
</div></div></blockquote></div><br class=""><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div class="gmail_signature"><div dir="ltr" class=""><div class="">Michael Musgrove</div><div class="">Transactions Team</div><div class="">e: <a href="mailto:mmusgrov@redhat.com" target="_blank" class="">mmusgrov@redhat.com</a></div><div class="">t: +44 191 243 0870</div><div class=""><br class=""></div><div class="">Registered in England and Wales under Company Registration No. 03798903</div><div class="">Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson</div><div class="">(US), Charles Peters (US)</div><div class=""><br class=""></div><div class="">Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland)</div></div></div>
</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>