The root modules when compiling code in the unnamed module or where the initial class is loaded from the class path

[Sanne Grinovero]

Hi Alan,

please note the troublesome package from JTA is named
"javax.transaction", not "java.transaction".

I really appreciate the effort to improve on this, but even just
adding an "-addmods" parameter is a new requirement which will break
all the tooling and IDEs out there: people expect to be able to jank
on their favourite keyboard shortcut to launch unit tests after
automated project imports, and see the tests running fine.
It would be great if we could find a solution which doesn't need any parameters.

I'm also skeptical that it is a good idea to have the platform switch
some part of its implementation depending on which libraries and/or
frameworks are going to be used; I realize this is not a new problem
but maybe we have an opportunity here to fix that and avoid these
complexities:

It seems this issue is only affecting some specific packages which are
being shared across JavaSE and JavaEE, would it not be nicer to
cleanup this mess and incorporate the missing APIs into the JavaSE
modules?

I think there's no doubt that we would all highly prefer to have a
single artifact for each package identity. Not least, I'll admit that
it would be nice to no longer have to explicitly add basic APIs like
JTA on the classpath and have them incorporated in the SE platform.

The "bloating" of JavaSE would hardly still be a problem, since
there's a modules system now :)

Thanks,
Sanne




On Mon, Apr 4, 2016 at 1:33 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>
> Just an FYI that the "Root modules" section of JEP 261 has been updated with
> a revised policy on the modules to resolve when compiling code in the
> unnamed module, or at runtime when the main class is loaded from the class
> path.
>
> The key point is that "java.se" will be the only java.* root and means that
> the modules shared with Java EE won't be resolved by default. As a
> remainder, the modules that are in the transitive closure of java.se.ee that
> are not in the transitive closure of java.se are:
>
>   java.activation
>   java.annotations.common
>   java.corba
>   java.transaction
>   java.xml.bind
>   java.xml.ws
>
> This should be a boon to Java EE servers and applications that have
> historically being built or deployed with the EE versions of these modules.
> It will be "as if" these modules don't exist in the JDK.
>
> On the other hand, applications that use types in any of these 6 modules,
> and don't deploy with the EE versions of these components, will need to use
> `-addmods` at compile-time or runtime to ensure that the modules are
> resolved.
>
> This policy is not in place yet. We'll probably need to have it bake in jake
> for a time before we bring it into JDK 9.
>
> -Alan
>
> [1] http://openjdk.java.net/jeps/261