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.bate...@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
