Problem with Proguard after jSerialComm upgrade from 2.5.3 to 2.9.1

[mattbrenner]

Hi,

I've been using jSerialComm for a few years. I have been using jSerialComm-2.5.3.jar. I also use Proguard (v. 6.2.0).

Occasionally, I get an unexpected error from jSerialComm. It finally occurred me to check for a newer version and see if using it disappears those problems. I fetched a copy of jSerialComm-2.9.1 and rebuilt my system. No problem rebuilding. However, when I run Proguard to shrink my program's jar file, I get these messages from Proguard:

ProGuard, version 6.2.0 Reading program jar [/home/matt/proguard/spotter.jar] Reading library jar [/usr/lib/jvm/jdk1.8.0_261/jre/lib/rt.jar] Reading library jar [/usr/lib/jvm/jdk1.8.0_261/jre/lib/jce.jar] Warning: com.fazecast.jSerialComm.SerialPort$1: can't find referenced method 'java.util.List access$000()' in program class com.fazecast.jSerialComm.SerialPort Warning: com.fazecast.jSerialComm.SerialPort$1: can't find referenced method 'boolean access$102(boolean)' in program class com.fazecast.jSerialComm.SerialPort Warning: com.fazecast.jSerialComm.SerialPort$1: can't find referenced method 'void access$200()' in program class com.fazecast.jSerialComm.SerialPort Warning: there were 3 unresolved references to program class members. Your input classes appear to be inconsistent. You may need to recompile the code. (http://proguard.sourceforge.net/manual/troubleshooting.html#unresolvedprogramclassmember) Error: Please correct the above warnings first.

I realize Proguard is not your program (or problem), but maybe you can offer some suggestions?

Thank you very much for any assistance you can provide.

Also, I want to ell you that jSerialComm is a great library. It has been very useful and generally well behaved. It is a first-class piece of work! Thanks for making it available.

Regards,

Matt

[hedgecrw]

Hey Matt,

Unfortunately, I've never used ProGuard, so I don't have any deep insights to give here. I did try to download the latest version of ProGuard (7.2.1) and run this JAR through it using the following config:

-injars       jSerialComm-2.9.1.jar
-outjars      jSerialComm-2.9.1_out.jar
-libraryjars  C:/Program Files/Java/jdk-9.0.4/jmods/java.base.jmod
-printmapping proguard.map

-dontnote module-info
-dontnote jdk.internal.**

-keep public class * {
   public * ;
 }

It seemed to work without complaining about anything, but I'm sure I'm not using it correctly. Can you post some version of your proguard configuration file I can play around with?

[mattbrenner]

Hi hedgecrw,

First, thank you very much for undertaking to help with a proguard-related problem. Fortunately, I've been able to sort it out by reworking some proguard files.

I do, however, have another question. Among the .so files included in the jSerialComm jar file are several armv7 files:

Linux/armv7/libjSerialComm.so Linux/armv7-hf/libjSerialComm.so Linux/armv7hf/libjSerialComm.so

In my production version I strip out the unneeded .so files on the production platform. I realize this is a bit at odds with the portability goals of jSerialComm, but I'm trying to minimize storage usage and OTA transfer costs.

I understand that "hf" stands for "hard-float," but I'm puzzled over what might the differences between these two files:

Linux/armv7-hf/libjSerialComm.so Linux/armv7hf/libjSerialComm.so

I suppose I can try running my application with one and then the other to see which work, but I'm actually curious to know the differences.

Also, will,

Linux/armv7/libjSerialComm.so

in place of the hf version (thought it might be slower)?

Any light you can shed will be appreciated.

Best regards, Matt

[hedgecrw]

Glad you were able to get this sorted out.

To answer your questions:

1) The jSerialComm JAR does not contain both Linux/armv7-hf and Linux/armv7hf directories (I just double-checked), so somehow you have managed to combine two versions of the library into one JAR file. 2) Using armv7 in place of armv7hf should work from a theoretical point of view, but the problem is that the Java-side of the library may specifically try to load the hf version on a hard-float machine and fail if that library is missing.

Hope that helps!