Unnamed module and duplicate package

[Neil Bartlett]

> On 11 Mar 2016, at 21:56, Alex Buckley <alex.buckley at oracle.com> wrote:
> 
> On 3/11/2016 2:04 AM, Neil Bartlett wrote:
>>> On 11 Mar 2016, at 08:50, Alan Bateman <Alan.Bateman at oracle.com>
>>> wrote:
>>> The transaction API is one of a small number of APIs shared between
>>> Java SE and EE. The complete set is non-aggregator modules that
>>> java.se.ee requires. In the case of the transaction API then Java
>>> SE defines the minimum subset of javax.transaction required to
>>> support the mapping of CORBA system exceptions to RMI exceptions.
>>> The Java Language to IDL Mapping spec has the details. Java SE
>>> defines all the types in javax.transacation.xa, important because
>>> JDBC supports XA.
>> 
>> Whatever the motivation, I referred to this package as “broken”
>> because it has caused a great many problems for OSGi users.
>> Applications that import the javax.transaction package may encounter
>> NoClassDefFoundError due to the missing types if they wire to the
>> platform export. The most commonly employed practical solution is to
>> add back those types with the application ClassLoader.
>> 
>> A properly constructed set of OSGi bundles *should* never throw
>> NoClassDefFoundError or ClassNotFoundException, and I would hope this
>> will also be the case in Jigsaw.
> 
> For a set of consistently compiled modules with no unchecked warnings, the JPMS guarantees the JVM will never throw NoClassDefFoundError, nor ClassCastException due to heap pollution ("no unchecked warnings") or split packages (as 'requires' != Require-Bundle).
> 
> Per Alan's comment, guaranteeing no ClassNotFoundException is impossible because consistently compiled code can use Class::forName with random strings.

Yes I agree this case cannot be prevented — it remains a problem in OSGi also, so I should have been more specific.

It’s my experience that a CNFE can arise when Class.forName is used to load a known class that references (directly or indirectly) an unknown/nonexistent class. This is the kind of error that can be prevented at build time, similarly to NCDFE.

> 
> Alex