issue deriving automatic module name

[paul.bakker.nl at gmail.com]

My point is that the module name resolver that generates a module name from the file name should not choke on this file pattern. Failing at startup if there is a problem is of course the right thing to do.

Yes, this jar has indeed another problem. I only ran into these problems testing some of my existing migration demos in IntelliJ, which puts all jars on the module path for a modular application. I’m going to open an issue with them for better control over this. Putting the jar on the CP is fine in this scenario, it is only a transitive dependency of another automatic module (Hibernate).

Paul

> On Oct 4, 2017, at 6:07 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
>> On 03/10/2017 17:44, Paul Bakker wrote:
>> Hi,
>> 
>> I ran into an issue testing some migration scenarios. When using jboss-transaction-api_1.2_spec-1.0.1.Final.jar as an automatic module, startup fails with:
>> 
>> Caused by: java.lang.IllegalArgumentException: jboss.transaction.api.1.2.spec: Invalid module name: '1' is not a Java identifier
>> 
>> This is clearly a strange JAR name, and can be fixed by providing a module name, but it should probably not prevent startup.
>> 
> I assume you've put this JAR file on the module path because some code in an automatic module has references to classes in this JAR file. So catching this at startup seem right, you will otherwise risk a failure at runtime (NoClassDefFoundError) if the module system were to ignore the oddly named JAR file.
> 
> As an aside, the contents of this JAR file are also problematic because it contains classes from the java.transaction and java.sql modules. This is something that we hope the owners of the Java Transaction API JSR will resolve soon, maybe by splitting the spec into two so that Java SE can define a java.transaction.xa module (in conjunction with jettisoning the java.transaction module from Java SE and the JDK).
> 
> -Alan