FlatLaf and Proguard ? #648
Comments
|
I was playing around with Swing for a while last year and combined a few things together into an example project, which included FlatLaf for the look and feel, light/dark theme detector on startup, packaging for deployment, and ProGuard obfuscation. If I remember correctly, I was unable to get obfuscation working with making a fat jar but I didn't know ProGuard at all or Swing or Java that well. Not sure if that'll help you or not but you can check out the POM file in the project to see what I did. https://github.com/MetalAZ/swing-app |
|
It doesn't make much sense to obfuscate an open-source library... 😉 Maybe it makes the library a little bit smaller because of shorter names. So maybe you save 100-200 kB. Swing uses reflection to create UI delegates. ProGuard optimization (without obfuscation) could work. |
|
I hear you and agree on all points. We reduced the FlatLaf jar size by about 140kb when we dropped the DLL and line numbers. I asked the question really just to see if anyone else is using ProGuard with FlatLaf. We use it against our entire application fatjar, with some overrides needed for things like Apache POI and JAXB. Completely excluding FlatLaf from the obfuscation makes it a bit of an outlier; it would be nice if it could be included. I realize that there is no intellectual property requirement, and that there is probably no more than a 100kb reduction to be obtained. I also concur that a first step would be to enable optimization with obfuscation turned off. |
|
How would I make sure I exclude flatlaf from obfuscation? |
|
I am using these Proguard statements. There is not much to be gained here, since obviously FlatLaf is small in the first place. I am also preprocessing the FlatLaf jar to drop line numbers and the DLL, since I would rather have the DLL excluded. Dropping the DLL works with 2.6 and then thanks to the FlatLaf support team it will work again in the next release. It seems the Proguard problems revolve around that the design that calls in the various UI components by name via the properties file, which makes then unreferenced within the analyzed class usage tree. This causes Proguard to believe they are not used and hence drops those classes from the resulting output jar. As a resolution for this, I have seen other applications explicitly reference their defaults and then use properties as an override mechanism. This will be a future issue if we ever move to native image, such as GraalVM, since it similarly inspects for classes that are explicitly used by the application and by default drops everything else. -keep class com.formdev.flatlaf., |
|
Thanks a lot for your reply, I appreciate this a lot. This is what my proguard.conf looks like: I still get this warning: If I would ignore the warning and run the jar i get: So I'm not sure why it doesn't keep everything as I specified in the conf, if you would have any other ideas or see a mistake I made, I appreciate it a lot, thanks. |
|
Update: I fixed it using: |
|
Glad you now have this working. As I had said earlier, I am not using the native DLL support, which is where you encountered this problem. This is why I never tested the presence of those native methods. Also FYI that your definition appears to have duplicate entries for application, enumerations, database drivers, swing, and native methods. |
Has anyone used Proguard against FlatLaf? I currently just keep everything since I was unable to successfully apply any optimization or obfuscation. Here is the keep everything that in my existing definition: -keep class com.formdev.** { *; }. I can obviously drop the line number table and then I also use -injars '....[filereference]....\flatlaf-2.6.jar'(!com/formdev/flatlaf/natives/**) to drop the embedded DLLs. However, it would be great to be able to do more if possible.
The text was updated successfully, but these errors were encountered: