I think this is one of the things we'll need to revisit when we
introduce module requirements.
Note that some APIs (e.g., JavaMail, JAF) are not designed to be
reusable by multiple implementations, so the API module and the
implementation module are tightly tied. If the implementation
module exposes no public APIs (e.g., JAF), is there any reason to
expose the implementation APIs in a separate module instead of just
including them in the API module?
In any event, you're right that we'll need to revise this
recommendation once we have a better understanding of modules.
And remember that the main reason we have API modules is
because developers said "I want to be able to compile
against the standard API and know that I haven't referenced any
implementation classes". I know that API implementors often want a
reusable definition of the standard APIs that they can depend on
when building their own implementation, but that was a secondary
reason for creating API jar files and was not possible in all cases.
Greg Wilkins wrote on 11/28/18 01:38 AM:
Bill et al,
I disagree with the following section:
The implementation jar file typically includes all the classes from
the API jar file, plus whatever implementation classes are needed
to produce a complete runtime.
In some cases the implementation jar file might contain only
the implementation artifacts, and depend on the API jar file
for the API definitions, although this is discouraged for
standalone implementations.
Having API classes in implementation jars just invites
duplicate classes and reduces flexibility. A jar that is
"standalone" in one deployment may well be used as component
in another, plus there is no general reason that multiple
versions of an API cannot be deployed in the same classloader
scope. These issues have always existed, but will only be
made more acute by JPMS.
The policy should default to having separate jars for API
and implementation, with perhaps a naming convention for
aggregating both if a single jar is really needed.
regards
--
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
|
