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.
Cheers,
Paul
On Wed, Jan 20, 2016 at 11:37 AM, Jason Greene <jason.greene(a)redhat.com>
wrote:
> On Jan 20, 2016, at 11:12 AM, Tomasz Adamski <tadamski(a)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.
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
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev