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
