Thanks for your insights & opinion, @David Jencks & David Blevins. It is very intersting from my point of view. I got this quote from the mailing list archive [1] by @dblevins > I know we don't support Corba itself, so we'd probably have to figure out> how we're tied to those classes and what to do about it. If the "we do not support it" is still correct, we could try to remove it and then check for the build status (with Java 8). This will open the possibility to build with Java 11 (target byte code level 8) in case we want it as "nice 2 have". The places in the code-base with CORBA related access are: org.apache.openejb.core.OrbFactory org.apache.openejb.client.corba.Corbas XML Files, service-jar XML files: <ServiceProvider id="Default ORB" service="Resource" types="org.omg.CORBA.ORB, ORB" factory-name="create" class-name="org.apache.openejb.core.OrbFactory"> </ServiceProvider> Nevertheless, one outcome of this dicussion is, that PR 664 [2] might be closed due to the incompatible license of jacorb (according to @David Jencks).
[1] https://www.mail-archive.com/dev@tomee.apache.org/msg08054.html[2] https://github.com/apache/tomee/pull/664 Am Dienstag, den 07.07.2020, 17:03 -0700 schrieb David Blevins: > Good discussion with great questions. A couple updates/points: > - Jakarta EE 9 has entirely removed requirements and tests for > CORBA/ORB support (resolved and executed) > - Java 11 may or may not stay as the target jvm version for Jakarta > EE 9 (new discussion > https://www.eclipse.org/lists/jakartaee-spec-project-leads/msg00600.html > ) > - TomEE 8x being the master branch, we have some stability > limitations on removing/adding major features > Here's where I think that pushes us. > CORBA/ORB > We probably don't want to be adding CORBA support. We maybe could > have gotten some small benefit 10 years ago when it would have > allowed us to pursue Java EE Full Profile certification, but with it > being dropped by the JDK and Jakarta platform we'd be setting > ourselves up to have to carry a ton of weight. > That brings us remove vs maintain, which really becomes a stability > question linked to the fact that TomEE 8.0.x is living in master. We > might want to explore ways to support the very limited ties we have > without a compile time dependency: reflection; move that to another > jar released separately and just import it; generate a class or two > with ASM (we do this to support Hibernate due to LGPL restrictions). > Open to ideas. > > JAVA 11 > We almost certainly would not be able to drop Java 8 support between > TomEE 8.0.2 and the coming 8.0.3. More than likely we'd have to > compile on Java 8 and then run the TCK tests on both Java 8 and Java > 11 to verify all works. What that means is any support for Java 11 > in the build itself is likely nice-to-have. > This might become even less of a discussion if Java 8 becomes the > primary java version for Jakarta EE 9, instead of simply being > optional as it is now. This decision will be made by next Tuesday, > but honestly given we're stuck with Java 8 due to TomEE 8/Jakarta EE > 8, we're not really affected either way. > Where I think that brings us is that we can do work to make the build > run on Java 11 as long as it does not break the Java 8 build. > Open to ideas and discussion on that. > >
smime.p7s
Description: S/MIME cryptographic signature
