How to avoid depending on corba classes in rt.jar

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

How to avoid depending on corba classes in rt.jar

Michael Musgrove
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
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to avoid depending on corba classes in rt.jar

jtgreene
Administrator
We probably should rename the packages to avoid confusion. What do you think Tomasz?


On Jan 20, 2016, at 10:07 AM, Michael Musgrove <[hidden email]> 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
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

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


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to avoid depending on corba classes in rt.jar

Tomasz Adamski
> 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" <[hidden email]>
> Do: "Michael Musgrove" <[hidden email]>
> DW: "WildFly Dev" <[hidden email]>, "Tomasz Adamski" <[hidden email]>
> 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 <[hidden email]> 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: [hidden email] <mailto:[hidden email]>
> > 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
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to avoid depending on corba classes in rt.jar

Michael Musgrove


On Wed, Jan 20, 2016 at 4:45 PM, Tomasz Adamski <[hidden email]> 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" <[hidden email]>
> Do: "Michael Musgrove" <[hidden email]>
> DW: "WildFly Dev" <[hidden email]>, "Tomasz Adamski" <[hidden email]>
> 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 <[hidden email]> 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: [hidden email] <mailto:[hidden email]>
> > t: <a href="tel:%2B44%20191%20243%200870" value="+441912430870">+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
> > [hidden email]
> > 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
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to avoid depending on corba classes in rt.jar

Michael Musgrove


On Wed, Jan 20, 2016 at 5:01 PM, Michael Musgrove <[hidden email]> wrote:


On Wed, Jan 20, 2016 at 4:45 PM, Tomasz Adamski <[hidden email]> 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" <[hidden email]>
> Do: "Michael Musgrove" <[hidden email]>
> DW: "WildFly Dev" <[hidden email]>, "Tomasz Adamski" <[hidden email]>
> 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 <[hidden email]> 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: [hidden email] <mailto:[hidden email]>
> > t: <a href="tel:%2B44%20191%20243%200870" value="+441912430870" target="_blank">+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
> > [hidden email]
> > 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
t: <a href="tel:%2B44%20191%20243%200870" value="+441912430870" target="_blank">+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
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to avoid depending on corba classes in rt.jar

Tomasz Adamski
In reply to this post by Michael Musgrove
> 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" <[hidden email]>
> Do: "Tomasz Adamski" <[hidden email]>
> DW: "Jason Greene" <[hidden email]>, "WildFly Dev" <[hidden email]>
> 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 <[hidden email]> 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" <[hidden email]>
> > > Do: "Michael Musgrove" <[hidden email]>
> > > DW: "WildFly Dev" <[hidden email]>, "Tomasz Adamski" <
> > [hidden email]>
> > > 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 <[hidden email]>
> > 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: [hidden email] <mailto:[hidden email]>
> > > > 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
> > > > [hidden email]
> > > > 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: [hidden email]
> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to avoid depending on corba classes in rt.jar

jtgreene
Administrator

> On Jan 20, 2016, at 11:12 AM, Tomasz Adamski <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to avoid depending on corba classes in rt.jar

Paul Benedict
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 <[hidden email]> wrote:

> On Jan 20, 2016, at 11:12 AM, Tomasz Adamski <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to avoid depending on corba classes in rt.jar

Michael Musgrove
In reply to this post by jtgreene


On Wed, Jan 20, 2016 at 5:37 PM, Jason Greene <[hidden email]> wrote:

> On Jan 20, 2016, at 11:12 AM, Tomasz Adamski <[hidden email]> 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
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to avoid depending on corba classes in rt.jar

jtgreene
Administrator
In reply to this post by Paul Benedict
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 <[hidden email]> 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 <[hidden email]> wrote:

> On Jan 20, 2016, at 11:12 AM, Tomasz Adamski <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


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


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to avoid depending on corba classes in rt.jar

jtgreene
Administrator

On Jan 20, 2016, at 12:15 PM, Jason Greene <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:

> On Jan 20, 2016, at 11:12 AM, Tomasz Adamski <[hidden email]> 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
[hidden email]
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


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to avoid depending on corba classes in rt.jar

jtgreene
Administrator
In reply to this post by Michael Musgrove

On Jan 20, 2016, at 11:56 AM, Michael Musgrove <[hidden email]> wrote:



On Wed, Jan 20, 2016 at 5:37 PM, Jason Greene <[hidden email]> wrote:

> On Jan 20, 2016, at 11:12 AM, Tomasz Adamski <[hidden email]> 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). 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
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


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to avoid depending on corba classes in rt.jar

jtgreene
Administrator
In reply to this post by Michael Musgrove

On Jan 20, 2016, at 11:09 AM, Michael Musgrove <[hidden email]> 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


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to avoid depending on corba classes in rt.jar

Tomasz Adamski
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" <[hidden email]>
> Do: "Michael Musgrove" <[hidden email]>
> DW: "Tomasz Adamski" <[hidden email]>, "WildFly Dev" <[hidden email]>
> 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 <[hidden email]> 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
>
>

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev