[wildfly-dev] How to avoid depending on corba classes in rt.jar

[Jason Greene]

> On Jan 20, 2016, at 11:56 AM, Michael Musgrove <mmusgrov at redhat.com> wrote:
> 
> 
> 
> On Wed, Jan 20, 2016 at 5:37 PM, Jason Greene <jason.greene at redhat.com <mailto:jason.greene at redhat.com>> wrote:
> 
> > On Jan 20, 2016, at 11:12 AM, Tomasz Adamski <tadamski at redhat.com <mailto:tadamski at redhat.com>> wrote:
> >
> >> In a standalone scenario we are not using modules so the JVM would use
> >> rt.jar unless the user updates the bootclasspath. I do not see how it would
> >> be possible to avoid the jdeps warnings.
> >
> > 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.
> 
> 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.
> 
> 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.
> 
> 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.

Ah yes. 

> 
> We are also investigating how to provide a JTS implementation without an ORB (https://issues.jboss.org/browse/JBTM-2103 <https://issues.jboss.org/browse/JBTM-2103>). If we can make progress on that task then achieving your goal would still be feasible.

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.

> 
> Mike
>  
> 
> 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.
> 
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
> 
> 
> 
> 
> -- 
> Michael Musgrove
> Transactions Team
> e: mmusgrov at redhat.com <mailto:mmusgrov at redhat.com>
> t: +44 191 243 0870
> 
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson
> (US), Charles Peters (US)
> 
> Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland)

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160120/68403a79/attachment.html