On 03/11/2016 09:23 AM, Alan Bateman wrote:
On 11/03/2016 14:52, David M. Lloyd wrote:
What about javax.transaction.xa? Ideally we won't just throw that
into some unnamed module right?
With it being a part of java.sql though, it's going to be pretty tough
to separate out. Can it not at least be its own module which can be
upgraded in a consistent way with java.transaction? I guess it's just
not clear to me how this is going to work. From my perspective, it
would be at the least more organizationally convenient to treat all
the SE+EE modules in the same way.
The proposal is for the java.sql module to own and export
javax.transaction.xa. You'll see it in the summary table that I linked
to in the mail.
On the surface then it might look odd but we've explored many options.
The good news is that javax.transaction.xa is slow moving, I'm not aware
of any changes in 10+ years. We have of course discussed this with the
relevant spec leads in the JCP and we of course understand that it
requires a bit of coordination in the event that JSR 907 decides some
day to update something in the xa package.
That would definitely be ideal from a security standpoint, especially
if in this context "non-core" means "all except for 'java.base'"... or
as close as possible to it.
We are currently down to ~25 modules defined to the boot loader. With
more effort then we could reduce this a bit (maybe by 4 or 5 modules).
What are the limiting factors? In my analysis the only problem that
seemed close to insurmountable was the special natives that are used in
the JDK but these only seem to be used from java.base. Does it all boil
down to getClassLoader()==null security checks on the Java side, or is
there a JVM component that I haven't discovered?
--
- DML
