| Hi Bill,
I mean that there are 5 subprojects in GlassFish that use these dependencies. The first thing to do is to see which of them are actually needed, and why and how we can eliminate them. It may be that they aren’t actually needed, or are only used because gmbal-pfl is using them. If we eliminate them, we are free to replace them with the latest asm, which may be needed for JDK11.
I cannot answer what is involved because I don’t know why they are being used now. I am not familiar with the GlassFish subprojects that use them.
There should be no reason for pfl-asm to exist, as far as I can tell. I believe that code simplification is especially worth pursuing now that we have many fewer developers working on this than before.
- Russ
Ok, I think I'm starting to catch up...
There's 5 usages of pfl-asm stuff in GlassFish. If we fix those 5
usages to use the new API, then they can use the new version of
pfl-asm that works with JDK 11.
Is that right?
You mention eliminating them below but I'm not sure what that
involves. That would mean taking these 5 usages and converting them
to not use pfl-asm and use something else instead? That sounds like
a much bigger job than converting them to use a new pfl-asm API. Do
you think this is worth pursuing?
Russell Gold wrote on 1/12/20 8:22 AM:
Russell Gold wrote on 1/11/20 5:36
PM:
[snip]
The ORB does not depend on Glassfish, so it would be
difficult automatically to use the same version, I
suspect. But if the pfl-asm dependency is removed from
Glassfish, I can work on getting rid of it completely. I
believe that other parts of gmbal-pfl still need it.
Sorry, I'm not following what it is
you think needs to be done here.
I have no idea whether GlassFish is
using pfl-asm directly, although certainly
it is using it indirectly because
it's using the ORB and the ORB is using it,
right?
A search of the build.xml files in Glassfish shows 5 usages
each of pfl-asm, pfl-tf-tools and pfl-basic-tools. I think we
would like to eliminate them, if possible.
Currently, the ORB is
built so that it should run under JDK11 (pfl-basic is
an MR jar). Some additional work will be needed in
Glassfish to take advantage of that.
What kind of work would be needed in GlassFish?
How is pfl-basic related to orb-gmbal-pfl?
orb-gmbal-pfl used to be called, simply, pfl, and consists
of a number of projects, including some only used for
testing. I’d like to get rid of the latter. The important
ones are pfl-basic and pfl-dynamic.
And those are in an MR jar that
works in JDK 11?
So there's no need to get rid of
pfl-basic or pfl-dynamic, right?
Correct.
In fact, I don't think
this will need to be done, but we will need the entire
ORB and RMI-IIOP support to work correctly in a JDK 11
runtime, as part of
providing backward compatibility for those products that
need it (e.g.,
WebLogic), including EJB interoperability support.
I’ve already done that work for WebLogic. Glassfish just
needs to use the updated APIs, I believe.
Is that work already in the Eclipse
project?
Yes.
What's involved in converting
GlassFish to use the updated APIs?
I’ll have to do some research on that point.
|
