Barcode : ClassNotFoundException when using module path in java

matthieu.steyt · February 5, 2022, 7:35pm

Hi,

I’m evaluating Aspose.BarCode for java and I’m getting a ClassNotFoundException when running my code using a module path (using a module-info for my project). See stacktrace below. When running using the classpath, everything works fine. This is possibly related to the fact that the class (‘h’), which can not be found at runtime, is located in the package ‘com/aspose/barcode/internal/do’. A package named ‘do’ should not exist as this is a reserved keyword in java (see https://en.wikipedia.org/wiki/List_of_Java_keywords). When running jdeps --generate-module-info on the aspose-barcode.jar the resulting module-info does not exports this faulty package. Hence the resulting error when running this on the module path.

Can the use of a ‘do’ package be avoided when you are (I assume) obfuscating the jar so it can be used in projects using java modules?

Exception in thread “main” java.lang.NoClassDefFoundError: com/aspose/barcode/internal/do/h
at aspose.barcode@22.1-jdk18/com.aspose.barcode.internal.dl.g.a(Unknown Source)
at aspose.barcode@22.1-jdk18/com.aspose.barcode.internal.dl.g.a(Unknown Source)
at aspose.barcode@22.1-jdk18/com.aspose.barcode.generation.BarcodeGenerator.a(Unknown Source)
at aspose.barcode@22.1-jdk18/com.aspose.barcode.generation.BarcodeGenerator.save(Unknown Source)
at aspose.barcode@22.1-jdk18/com.aspose.barcode.generation.BarcodeGenerator.save(Unknown Source)
at aspose.barcode@22.1-jdk18/com.aspose.barcode.generation.BarcodeGenerator.save(Unknown Source)
at test/be.innersight.Test.main(Test.java:15)
Caused by: java.lang.ClassNotFoundException: com.aspose.barcode.internal.do.h
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
… 7 more

Amjad_Sahi · February 7, 2022, 11:35am

@matthieu.steyt,

Thanks for the stacktrace.

We have logged an investigation ticket with an id “BARCODEJAVA-1282” for your issue. We will look into the details of the problem and try to figure it out soon.

Once we have an update on it, we will let you know here.

Aleksander.Grinin · February 7, 2022, 1:30pm

@matthieu.steyt,
could you please provide an example of the code in which this exception appears?
Thank you

matthieu.steyt · February 7, 2022, 5:49pm

@Aleksander.Grinin
In attachment a simple example. See the README file for compilation and running commands. First place the aspose-barcode-22.1-jdk18.jar under the lib directory as I have not bundled it with the example.

As mentioned I’m using java modules and thus compiling and running it using a module path.

I have tested this example with java 17 (openjdk build 17+35-2724) and java 9 (java hotspot build 9.0.4+11). The same result (see stacktrace above) twice.

BarcodeTestExport.zip (2.3 KB)

Amjad_Sahi · February 7, 2022, 8:28pm

@matthieu.steyt,

I tested your scenario/case with your sample using modulepath on console (command prompt) using JDK11 and I got the same issue. The project is compiled fine but it does not run and produces the error, see the screenshot attached. We will be analyzing and looking into your issue soon.
sc_shot1.png (23.9 KB)

Aleksander.Grinin · February 9, 2022, 4:19pm

matthieu.steyt
Generally speaking, this is acceptable to use keywords in compiled files.
For example, such proguard file defines the naming rules as list of keywords

github.com

facebookarchive/proguard/blob/master/examples/dictionaries/keywords.txt

#
# This obfuscation dictionary contains reserved Java keywords. They can't
# be used in Java source files, but they can be used in compiled class files.
# Note that this hardly improves the obfuscation. Decent decompilers can
# automatically replace reserved keywords, and the effect can fairly simply be
# undone by obfuscating again with simpler names.
# Usage:
#     java -jar proguard.jar ..... -obfuscationdictionary keywords.txt
#

do
if
for
int
new
try
byte
case
char
else

This file has been truncated. show original

But this issue is being reproduced (case with modules) and will be studied further. We adjusted the names of packages after obfuscation.
This fix will be included in release 22.2

matthieu.steyt · February 10, 2022, 1:42pm

Thanks for the quick response. I’ll continue my evaluation when the fix is released.