Unnamed module and duplicate package

[David M. Lloyd]

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