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

[Alan Bateman]

On 05/04/2016 12:34, Sanne Grinovero wrote:
> Hi Alan,
>
> please note the troublesome package from JTA is named
> "javax.transaction", not "java.transaction".
The list is my mail is module names rather not packages. In the case of 
JTA then the module is java.transaction and it exports 
javax.transaction. The types in package javax.transaction.xa don't come 
into the discussion as they have subsumed by the java.sql module and 
that will be resolved by default.


>
> 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.
The only types that Java SE defines in package javax.transaction are the 
exceptions required for mapping CORBA system exceptions to RMI 
exceptions. The Java Language to IDL mapping spec has more details on 
that topic.

If there is a library or application that is only dependent on Java SE 
subset then that code would need to be compiled and run with `-addmods 
java.transaction`.

On the other hand, if there is code using the EE version of JTA then I 
assume they must have java.transaction on the class path or deploying it 
via the endorsed standard mechanism today. The endorsed standard 
mechanism is gone, its replacement is the upgrade module path 
mechanism.  So going forward with the proposal in JEP 261 then you can 
deploy JTA on the class path or as a module, the JDK won't care.

So at least in the case of the types in package javax.transaction then 
we may find that few, if anyone, will notice.

>
> 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?
or the opposite, which is jettison these APIs from Java SE and the JDK. 
That is something for the platform JSR of course.

The only reason that Java SE defines types in package javax.transaction 
is because of CORBA.

The only reason that Java SE defines a subset of the JSR-250 defined 
Common Annotations or includes the JavaBeans Activation Framework is 
because of the web services stack (JAXB and JAX-WS).

>
> 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.
I don't know what you mean by "package identity" here but from the core 
platform perspective then APIs such as JTA shouldn't need to be defined 
by the core platform. Much better to deploy them as modules that declare 
their dependences and only export the packages with the APIs that they 
define.

-Alan