5:07 p.m.
The narayana jts jar has dependencies on internal jdk orb classes. We test
that it can work with the openjdk-orb by adding the openjdk-orb jar to the
bootclasspath. However, jdeps -jdkinternals reports that we depend on
internal JDK APIs. Is it the case that we cannot avoid this warning but
that we are safe provided at runtime we use the classes in the openjdk-orb
jar?
A follow up question is, if we add javax.orb.api as module dependency (in
our wildfly transactions subsystem) then at runtime will we be using the
classes provided by openjdk-orb?
Thanks,
Mike
--
Michael Musgrove
Transactions Team
e: mmusgrov(a)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)
5:13 p.m.
We probably should rename the packages to avoid confusion. What do you think Tomasz?
On Jan 20, 2016, at 10:07 AM, Michael Musgrove
<mmusgrov(a)redhat.com> wrote:
The narayana jts jar has dependencies on internal jdk orb classes. We test that it can
work with the openjdk-orb by adding the openjdk-orb jar to the bootclasspath. However,
jdeps -jdkinternals reports that we depend on internal JDK APIs. Is it the case that we
cannot avoid this warning but that we are safe provided at runtime we use the classes in
the openjdk-orb jar?
A follow up question is, if we add javax.orb.api as module dependency (in our wildfly
transactions subsystem) then at runtime will we be using the classes provided by
openjdk-orb?
Thanks,
Mike
--
Michael Musgrove
Transactions Team
e: mmusgrov(a)redhat.com <mailto:mmusgrov@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)
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
5:45 p.m.
A follow up question is, if we add javax.orb.api as module dependency
(in
our wildfly transactions subsystem) then at runtime will we be using the
classes provided by openjdk-orb?
If we use openjdk-orb in jboss-modules environment we are sure that openjdk-orb is used as
orb classes are not exported as system packages.
Is it the case that we cannot avoid this warning but
that we are safe provided at runtime we use the classes in the openjdk-orb
jar?
In standalone scenario it should work correctly too. I will look wheter the error is
caused by jdeps tool behaviour or do we indeed have some unwanted runtime references to
JDK.
We probably should rename the packages to avoid confusion. What do
you think
Tomasz?
This can be done but I see one problem: openjdk-orb is a hg repository and we have
possibility to synchronize it with JDK head if there are some changes in ORB code. I would
have to script it somehow to preserve such possibility. But I agree that it will be nice
to do.
--
Tomasz Adamski
Software Engineer
JBoss by Red Hat
----- Oryginalna wiadomość -----
> Od: "Jason Greene" <jason.greene(a)redhat.com>
> Do: "Michael Musgrove" <mmusgrov(a)redhat.com>
> DW: "WildFly Dev" <wildfly-dev(a)lists.jboss.org>, "Tomasz
Adamski" <tadamski(a)redhat.com>
> Wysłane: środa, 20 styczeń 2016 17:13:04
> Temat: Re: [wildfly-dev] How to avoid depending on corba classes in rt.jar
>
We probably should rename the packages to avoid confusion. What do
you think
Tomasz?
>
>
> > On Jan 20, 2016, at 10:07 AM, Michael Musgrove <mmusgrov(a)redhat.com>
wrote:
> >
> > The narayana jts jar has dependencies on internal jdk orb classes. We test
> > that it can work with the openjdk-orb by adding the openjdk-orb jar to the
> > bootclasspath. However, jdeps -jdkinternals reports that we depend on
> > internal JDK APIs. Is it the case that we cannot avoid this warning but
> > that we are safe provided at runtime we use the classes in the openjdk-orb
> > jar?
> >
> > A follow up question is, if we add javax.orb.api as module dependency (in
> > our wildfly transactions subsystem) then at runtime will we be using the
> > classes provided by openjdk-orb?
> >
> > Thanks,
> > Mike
> >
> > --
> > Michael Musgrove
> > Transactions Team
> > e: mmusgrov(a)redhat.com <mailto:mmusgrov@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)
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
6:01 p.m.
On Wed, Jan 20, 2016 at 4:45 PM, Tomasz Adamski <tadamski(a)redhat.com> wrote:
> A follow up question is, if we add javax.orb.api as module
dependency (in
> our wildfly transactions subsystem) then at runtime will we be using the
> classes provided by openjdk-orb?
If we use openjdk-orb in jboss-modules environment we are sure that
openjdk-orb is used as orb classes are not exported as system packages.
Okay so we are covered in wildfly and EAP which is good to know.
> Is it the case that we cannot avoid this warning but
> that we are safe provided at runtime we use the classes in the
openjdk-orb
> jar?
In standalone scenario it should work correctly too. I will look wheter
the error is caused by jdeps tool behaviour or do we indeed have some
unwanted runtime references to JDK.
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.
> We probably should rename the packages to avoid confusion. What do you
think
> Tomasz?
This can be done but I see one problem: openjdk-orb is a hg repository and
we have possibility to synchronize it with JDK head if there are some
changes in ORB code. I would have to script it somehow to preserve such
possibility. But I agree that it will be nice to do.
I agree it would be nice (but I guess not a must have).
Mike
--
Tomasz Adamski
Software Engineer
JBoss by Red Hat
----- Oryginalna wiadomość -----
> Od: "Jason Greene" <jason.greene(a)redhat.com>
> Do: "Michael Musgrove" <mmusgrov(a)redhat.com>
> DW: "WildFly Dev" <wildfly-dev(a)lists.jboss.org>, "Tomasz
Adamski" <
tadamski(a)redhat.com>
> Wysłane: środa, 20 styczeń 2016 17:13:04
> Temat: Re: [wildfly-dev] How to avoid depending on corba classes in
rt.jar
>
> We probably should rename the packages to avoid confusion. What do you
think
> Tomasz?
>
>
> > On Jan 20, 2016, at 10:07 AM, Michael Musgrove <mmusgrov(a)redhat.com>
wrote:
> >
> > The narayana jts jar has dependencies on internal jdk orb classes. We
test
> > that it can work with the openjdk-orb by adding the openjdk-orb jar to
the
> > bootclasspath. However, jdeps -jdkinternals reports that we depend on
> > internal JDK APIs. Is it the case that we cannot avoid this warning but
> > that we are safe provided at runtime we use the classes in the
openjdk-orb
> > jar?
> >
> > A follow up question is, if we add javax.orb.api as module dependency
(in
> > our wildfly transactions subsystem) then at runtime will we be using
the
> > classes provided by openjdk-orb?
> >
> > Thanks,
> > Mike
> >
> > --
> > Michael Musgrove
> > Transactions Team
> > e: mmusgrov(a)redhat.com <mailto:mmusgrov@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)
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
--
Michael Musgrove
Transactions Team
e: mmusgrov(a)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)
6:09 p.m.
On Wed, Jan 20, 2016 at 5:01 PM, Michael Musgrove <mmusgrov(a)redhat.com>
wrote:
On Wed, Jan 20, 2016 at 4:45 PM, Tomasz Adamski <tadamski(a)redhat.com>
wrote:
> > A follow up question is, if we add javax.orb.api as module dependency
> (in
> > our wildfly transactions subsystem) then at runtime will we be using the
> > classes provided by openjdk-orb?
>
> If we use openjdk-orb in jboss-modules environment we are sure that
> openjdk-orb is used as orb classes are not exported as system packages.
>
Okay so we are covered in wildfly and EAP which is good to know.
>
> > Is it the case that we cannot avoid this warning but
> > that we are safe provided at runtime we use the classes in the
> openjdk-orb
> > jar?
>
> In standalone scenario it should work correctly too. I will look wheter
> the error is caused by jdeps tool behaviour or do we indeed have some
> unwanted runtime references to JDK.
>
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.
>
> > We probably should rename the packages to avoid confusion. What do you
> think
> > Tomasz?
>
> This can be done but I see one problem: openjdk-orb is a hg repository
> and we have possibility to synchronize it with JDK head if there are some
> changes in ORB code. I would have to script it somehow to preserve such
> possibility. But I agree that it will be nice to do.
>
I agree it would be nice (but I guess not a must have).
On second thoughts, for standalone usage it is a pain to have to tell the
user that he must start the JVM with -Xbootclasspath/p:${openjdk-orb.jar}
which might be a barrier to adoption for some users.
Mike
Mike
>
> --
> Tomasz Adamski
> Software Engineer
> JBoss by Red Hat
>
> ----- Oryginalna wiadomość -----
> > Od: "Jason Greene" <jason.greene(a)redhat.com>
> > Do: "Michael Musgrove" <mmusgrov(a)redhat.com>
> > DW: "WildFly Dev" <wildfly-dev(a)lists.jboss.org>, "Tomasz
Adamski" <
> tadamski(a)redhat.com>
> > Wysłane: środa, 20 styczeń 2016 17:13:04
> > Temat: Re: [wildfly-dev] How to avoid depending on corba classes in
> rt.jar
> >
> > We probably should rename the packages to avoid confusion. What do you
> think
> > Tomasz?
> >
> >
> > > On Jan 20, 2016, at 10:07 AM, Michael Musgrove <mmusgrov(a)redhat.com>
> wrote:
> > >
> > > The narayana jts jar has dependencies on internal jdk orb classes. We
> test
> > > that it can work with the openjdk-orb by adding the openjdk-orb jar
> to the
> > > bootclasspath. However, jdeps -jdkinternals reports that we depend on
> > > internal JDK APIs. Is it the case that we cannot avoid this warning
> but
> > > that we are safe provided at runtime we use the classes in the
> openjdk-orb
> > > jar?
> > >
> > > A follow up question is, if we add javax.orb.api as module dependency
> (in
> > > our wildfly transactions subsystem) then at runtime will we be using
> the
> > > classes provided by openjdk-orb?
> > >
> > > Thanks,
> > > Mike
> > >
> > > --
> > > Michael Musgrove
> > > Transactions Team
> > > e: mmusgrov(a)redhat.com <mailto:mmusgrov@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)
> > > _______________________________________________
> > > wildfly-dev mailing list
> > > wildfly-dev(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> > --
> > Jason T. Greene
> > WildFly Lead / JBoss EAP Platform Architect
> > JBoss, a division of Red Hat
> >
> >
>
--
Michael Musgrove
Transactions Team
e: mmusgrov(a)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)
--
Michael Musgrove
Transactions Team
e: mmusgrov(a)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)
7:37 p.m.
On Jan 20, 2016, at 11:09 AM, Michael Musgrove
<mmusgrov(a)redhat.com> wrote:
I agree it would be nice (but I guess not a must have).
On second thoughts, for standalone usage it is a pain to have to tell the user that he
must start the JVM with -Xbootclasspath/p:${openjdk-orb.jar} which might be a barrier to
adoption for some users.
Ok so revisiting this again. It looks like we have to replace the org.omg APIs because
they hard code ORB impl classes, so even if we renamed the packages, we still would need
either endorsed or Xbootclasspath to be used by the user for non-modular standalone
bootstrapping.
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
8:18 p.m.
So in the end I have doubts wheter the rename should be performed as the initial problem
won't be solved and additional configuration will be necessary anyway...
--
Tomasz Adamski
Software Engineer
JBoss by Red Hat
----- Oryginalna wiadomość -----
Od: "Jason Greene" <jason.greene(a)redhat.com>
Do: "Michael Musgrove" <mmusgrov(a)redhat.com>
DW: "Tomasz Adamski" <tadamski(a)redhat.com>, "WildFly Dev"
<wildfly-dev(a)lists.jboss.org>
Wysłane: środa, 20 styczeń 2016 19:37:29
Temat: Re: [wildfly-dev] How to avoid depending on corba classes in rt.jar
> On Jan 20, 2016, at 11:09 AM, Michael Musgrove <mmusgrov(a)redhat.com> wrote:
>
> I agree it would be nice (but I guess not a must have).
>
> On second thoughts, for standalone usage it is a pain to have to tell the
> user that he must start the JVM with -Xbootclasspath/p:${openjdk-orb.jar}
> which might be a barrier to adoption for some users.
Ok so revisiting this again. It looks like we have to replace the org.omg
APIs because they hard code ORB impl classes, so even if we renamed the
packages, we still would need either endorsed or Xbootclasspath to be used
by the user for non-modular standalone bootstrapping.
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
6:12 p.m.
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.
--
Tomasz Adamski
Software Engineer
JBoss by Red Hat
----- Oryginalna wiadomość -----
> Od: "Michael Musgrove" <mmusgrov(a)redhat.com>
> Do: "Tomasz Adamski" <tadamski(a)redhat.com>
> DW: "Jason Greene" <jason.greene(a)redhat.com>, "WildFly Dev"
<wildfly-dev(a)lists.jboss.org>
> Wysłane: środa, 20 styczeń 2016 18:01:26
> Temat: Re: [wildfly-dev] How to avoid depending on corba classes in rt.jar
>
> On Wed, Jan 20, 2016 at 4:45 PM, Tomasz Adamski <tadamski(a)redhat.com> wrote:
>
> > > A follow up question is, if we add javax.orb.api as module dependency (in
> > > our wildfly transactions subsystem) then at runtime will we be using the
> > > classes provided by openjdk-orb?
> >
> > If we use openjdk-orb in jboss-modules environment we are sure that
> > openjdk-orb is used as orb classes are not exported as system packages.
> >
>
> Okay so we are covered in wildfly and EAP which is good to know.
>
>
> >
> > > Is it the case that we cannot avoid this warning but
> > > that we are safe provided at runtime we use the classes in the
> > openjdk-orb
> > > jar?
> >
> > In standalone scenario it should work correctly too. I will look wheter
> > the error is caused by jdeps tool behaviour or do we indeed have some
> > unwanted runtime references to JDK.
> >
>
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.
>
>
> >
> > > We probably should rename the packages to avoid confusion. What do you
> > think
> > > Tomasz?
> >
> > This can be done but I see one problem: openjdk-orb is a hg repository and
> > we have possibility to synchronize it with JDK head if there are some
> > changes in ORB code. I would have to script it somehow to preserve such
> > possibility. But I agree that it will be nice to do.
> >
>
> I agree it would be nice (but I guess not a must have).
>
> Mike
>
> >
> > --
> > Tomasz Adamski
> > Software Engineer
> > JBoss by Red Hat
> >
> > ----- Oryginalna wiadomość -----
> > > Od: "Jason Greene" <jason.greene(a)redhat.com>
> > > Do: "Michael Musgrove" <mmusgrov(a)redhat.com>
> > > DW: "WildFly Dev" <wildfly-dev(a)lists.jboss.org>,
"Tomasz Adamski" <
> > tadamski(a)redhat.com>
> > > Wysłane: środa, 20 styczeń 2016 17:13:04
> > > Temat: Re: [wildfly-dev] How to avoid depending on corba classes in
> > rt.jar
> > >
> > > We probably should rename the packages to avoid confusion. What do you
> > think
> > > Tomasz?
> > >
> > >
> > > > On Jan 20, 2016, at 10:07 AM, Michael Musgrove
<mmusgrov(a)redhat.com>
> > wrote:
> > > >
> > > > The narayana jts jar has dependencies on internal jdk orb classes. We
> > test
> > > > that it can work with the openjdk-orb by adding the openjdk-orb jar
to
> > the
> > > > bootclasspath. However, jdeps -jdkinternals reports that we depend on
> > > > internal JDK APIs. Is it the case that we cannot avoid this warning
but
> > > > that we are safe provided at runtime we use the classes in the
> > openjdk-orb
> > > > jar?
> > > >
> > > > A follow up question is, if we add javax.orb.api as module dependency
> > (in
> > > > our wildfly transactions subsystem) then at runtime will we be using
> > the
> > > > classes provided by openjdk-orb?
> > > >
> > > > Thanks,
> > > > Mike
> > > >
> > > > --
> > > > Michael Musgrove
> > > > Transactions Team
> > > > e: mmusgrov(a)redhat.com <mailto:mmusgrov@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)
> > > > _______________________________________________
> > > > wildfly-dev mailing list
> > > > wildfly-dev(a)lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> > >
> > > --
> > > Jason T. Greene
> > > WildFly Lead / JBoss EAP Platform Architect
> > > JBoss, a division of Red Hat
> > >
> > >
> >
>
>
>
> --
> Michael Musgrove
> Transactions Team
> e: mmusgrov(a)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)
>
6:37 p.m.
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
6:41 p.m.
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
7:15 p.m.
Hi Paul,
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.
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)
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 :)
On Jan 20, 2016, at 11:41 AM, Paul Benedict
<pbenedict(a)apache.org> wrote:
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
<mailto:jason.greene@redhat.com>> wrote:
> On Jan 20, 2016, at 11:12 AM, Tomasz Adamski <tadamski(a)redhat.com
<mailto:tadamski@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 <mailto:wildfly-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
<https://lists.jboss.org/mailman/listinfo/wildfly-dev>
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
7:21 p.m.
On Jan 20, 2016, at 12:15 PM, Jason Greene
<jason.greene(a)redhat.com> wrote:
Hi Paul,
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.
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)
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 :)
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.
That said, we should remove every occurrence that we don’t truly need.
> On Jan 20, 2016, at 11:41 AM, Paul Benedict <pbenedict(a)apache.org
<mailto:pbenedict@apache.org>> wrote:
>
> 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
<mailto:jason.greene@redhat.com>> wrote:
>
> > On Jan 20, 2016, at 11:12 AM, Tomasz Adamski <tadamski(a)redhat.com
<mailto:tadamski@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 <mailto:wildfly-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
<https://lists.jboss.org/mailman/listinfo/wildfly-dev>
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
6:56 p.m.
On Wed, Jan 20, 2016 at 5:37 PM, 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.
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.
We are also investigating how to provide a JTS implementation without an
ORB (https://issues.jboss.org/browse/JBTM-2103). If we can make progress on
that task then achieving your goal would still be feasible.
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(a)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)
7:30 p.m.
On Jan 20, 2016, at 11:56 AM, Michael Musgrove
<mmusgrov(a)redhat.com> wrote:
On Wed, Jan 20, 2016 at 5:37 PM, Jason Greene <jason.greene(a)redhat.com
<mailto:jason.greene@redhat.com>> wrote:
> On Jan 20, 2016, at 11:12 AM, Tomasz Adamski <tadamski(a)redhat.com
<mailto:tadamski@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(a)redhat.com <mailto:mmusgrov@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
3023
days inactive
3023
days old
13 comments
4 participants
participants (4)
-
Jason Greene -
Michael Musgrove -
Paul Benedict -
Tomasz Adamski