[DISCUSS] JakartaEE - continue rolling our own API jars vs use official ones?

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

[DISCUSS] JakartaEE - continue rolling our own API jars vs use official ones?

Mark Struberg
Hi folks!

JakartaEE moved to the Eclipse Foundation and all the APIs are now available without much restrictions.
There are 4 potentially problematic issues with the 'official' spec APIs:

1.) Most of them are EPLv2 licensed. This is a catB license [1] and weak-copyleft. That means we MUST add attribution and MUST provide a source code download. And of course not only we need to do this, but reciprocallly also all the downstream consumers and users.

2.) Our very own geronimo spec APIs used to have really great OSGi integration. The official API jars not so much. Some of them have no OSGi support at all. Did anyone look at the new official spec APIs? Can they be used in OSGi environments? I'm  not an OSGi person myself, so I need others to join into this discussion.

3.) Java8 support. Our own spec APIs mostly do not have module information. I just recently added this via MANIFEST.MF. The official spec API jars mostly use a module-info.class file. While this is technically preferable, it often bombs up with older low level bytecode manipulation libraries. The cause is that module-info.class must at least be a Java9 class file. So it's not really compatible with Java8. This doesn't happen that often - but I saw it happening. Is this really a problem? Or should we move to Java11 with JakartaEE anyway?

4.) When developing a new spec we cannot easily take the EPLv2 licensed sources over and modify them ourselves. We are bound to whatever Eclipse publishes as snapshot. Something to consider...

Of course the upside of using the official API jars are:
* we do not need to do any bytecode compat signature checks anymore.
* the JavaDoc is MUCH better obviously

Anything I missed?

LieGrue,
strub
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] JakartaEE - continue rolling our own API jars vs use official ones?

Romain Manni-Bucau
The fact we sometimes change the default provider can justify we keep it. That said we must also provide the module-info file to stay compliant - and not an automatic module name.

The copyright is also a nice to have which enforces this.

Finally I agree keeping osgi control is important for us and eclipse is, let say, not very keen yo do it yet.

Le sam. 25 avr. 2020 à 10:43, Mark Struberg <[hidden email]> a écrit :
Hi folks!

JakartaEE moved to the Eclipse Foundation and all the APIs are now available without much restrictions.
There are 4 potentially problematic issues with the 'official' spec APIs:

1.) Most of them are EPLv2 licensed. This is a catB license [1] and weak-copyleft. That means we MUST add attribution and MUST provide a source code download. And of course not only we need to do this, but reciprocallly also all the downstream consumers and users.

2.) Our very own geronimo spec APIs used to have really great OSGi integration. The official API jars not so much. Some of them have no OSGi support at all. Did anyone look at the new official spec APIs? Can they be used in OSGi environments? I'm  not an OSGi person myself, so I need others to join into this discussion.

3.) Java8 support. Our own spec APIs mostly do not have module information. I just recently added this via MANIFEST.MF. The official spec API jars mostly use a module-info.class file. While this is technically preferable, it often bombs up with older low level bytecode manipulation libraries. The cause is that module-info.class must at least be a Java9 class file. So it's not really compatible with Java8. This doesn't happen that often - but I saw it happening. Is this really a problem? Or should we move to Java11 with JakartaEE anyway?

4.) When developing a new spec we cannot easily take the EPLv2 licensed sources over and modify them ourselves. We are bound to whatever Eclipse publishes as snapshot. Something to consider...

Of course the upside of using the official API jars are:
* we do not need to do any bytecode compat signature checks anymore.
* the JavaDoc is MUCH better obviously

Anything I missed?

LieGrue,
strub
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] JakartaEE - continue rolling our own API jars vs use official ones?

Raymond Auge
As someone who has fought for better OSGi support in the MP spec APIs I can say that this has proven difficult and largely without success.

Le sam. 25 avr. 2020 à 10:43, Mark Struberg <[hidden email]> a écrit :
JakartaEE moved to the Eclipse Foundation and all the APIs are now available without much restrictions.
There are 4 potentially problematic issues with the 'official' spec APIs:

1.) Most of them are EPLv2 licensed. This is a catB license [1] and weak-copyleft. That means we MUST add attribution and MUST provide a source code download. And of course not only we need to do this, but reciprocallly also all the downstream consumers and users.

This is the weakest part of my knowledge about it, but I cannot disagree.
 

2.) Our very own geronimo spec APIs used to have really great OSGi integration. The official API jars not so much. Some of them have no OSGi support at all. Did anyone look at the new official spec APIs? Can they be used in OSGi environments? I'm  not an OSGi person myself, so I need others to join into this discussion.

I can attest that the spec jars cannot be used together in a pure OSGi environment without modification! You don't have to look further than the package imports of the specs as a whole to see that they are disjointed in terms of the import requirements. This is only the first part of the issue.
 

3.) Java8 support. Our own spec APIs mostly do not have module information. I just recently added this via MANIFEST.MF. The official spec API jars mostly use a module-info.class file. While this is technically preferable, it often bombs up with older low level bytecode manipulation libraries. The cause is that module-info.class must at least be a Java9 class file. So it's not really compatible with Java8. This doesn't happen that often - but I saw it happening. Is this really a problem? Or should we move to Java11 with JakartaEE anyway?

With modern tooling, Geronimo can continue building on Java8 to remain compatible, while also generating a Java9 module-info.java (even while still using the maven-bundle-plugin) if we choose. Bnd since 4.3.0 can write Java9 module info while running on Java8.
 

4.) When developing a new spec we cannot easily take the EPLv2 licensed sources over and modify them ourselves. We are bound to whatever Eclipse publishes as snapshot. Something to consider...

Since most of the changes in order to properly support OSGi don't necessarily involve code changes, and are mostly about generating proper bundle metadata I think building from the original sources isn't that hard and what I've been mostly doing since the beginning.
 

Of course the upside of using the official API jars are:
* we do not need to do any bytecode compat signature checks anymore.
* the JavaDoc is MUCH better obviously

Agreed!

So, I would support Apache rolling our own.

- Ray
 

Anything I missed?

LieGrue,
strub


--
Raymond Augé (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)