ClassJsonAdapter throws AssertionError without wrapping IllegalAccessException

[Puccet]

It seems like the issue from #1523 is still unresolved as i'm generating the uber jar with shade plugin but i'm facin gexactly the same issue.

Some additional info:

I'm using JRE Zulu 17.54.21-ca-fx-jre17.0.13
It happens only if executed within the uber jar, not if executed from the ide in debug or run mode

any idea?

Thanks in advance

[Puccet]

THe maven snippet

<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-shade-plugin</artifactId> <version>3.2.4</version> <configuration> <filters> <filter> <artifact>*:*</artifact> <excludes> <exclude>module-info.class</exclude> <exclude>META-INF/*.SF</exclude> <exclude>META-INF/*.DSA</exclude> <exclude>META-INF/*.RSA</exclude> </excludes> </filter> </filters> </configuration> <executions> <execution> <phase>package</phase> <goals> <goal>shade</goal> </goals> <configuration> <transformers> <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer"> <mainClass>it.fabiofrumento.smv.Main</mainClass> </transformer> </transformers> </configuration> </execution> </executions> </plugin>

[Smithor]

I have experienced this issue myself, and while I don't have a direct solution for you, I do have a workaround (attached below). I have not had success with packaging Moshi in an Uber-jar environment, but having it tied in on its own works fine.

I have attached the relevant Maven build instructions to have your project work. I know it is not ideal, I also tried to have an uber-jar environment, but encountered the same AssertionError, and couldn't escape it through any of the other merge methods I tried. This more traditional solution did allow it to keep working however, which is all I was worried about at the end of the day heh.

         <build>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-jar-plugin</artifactId>
                <version>3.4.2</version>
                <configuration>
                    <archive>
                        <manifest>
                            <packageName>com.org</packageName>
                            <addClasspath>true</addClasspath>
                            <classpathPrefix>lib/</classpathPrefix>
                            <mainClass>com.org.Main</mainClass>
                        </manifest>
                    </archive>
                </configuration>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-dependency-plugin</artifactId>
                <version>3.6.0</version>
                <executions>
                    <execution>
                        <phase>prepare-package</phase>
                        <goals>
                            <goal>copy-dependencies</goal>
                        </goals>
                        <configuration>
                            <outputDirectory>${project.build.directory}/lib</outputDirectory>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
         </build>

For someone debugging: If it helps at all, I'm using JPMS on Java 21. I would definitely prefer that it wasn't just an Assumption Error tossed out, because this made it so hard to troubleshoot and locate.

I suspect this is happening because when the combined jar is put together, the automatic module for Moshi is lost as it is no longer on its own as a Jar. This causes a problem because, even though the automatic module is allowed access in the configuration, the new entity does not share a name with the given automatic name, and so the code is no longer open to Moshi. Purely a guess though, I am still very much a JPMS novice.

Hopefully this information helps.