JavaFX fxml support

[meetinger]

After obsufiaction, my jar does not start due to an error:
caused by: java.lang.ClassNotFoundException: com.example.Controller at java.net.URLClassLoader.findClass(URLClassLoader.java:382) at java.lang.ClassLoader.loadClass(ClassLoader.java:418) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:355) at java.lang.ClassLoader.loadClass(ClassLoader.java:351) at javafx.fxml.FXMLLoader$ValueElement.processAttribute(FXMLLoader.java:920)

Because the name of the old class remains in the fxml file.

[thomasbehr]

Obfuscating FXML files is not explicitly supported. However, if you only need to adjust class names, you can try adding

<adjust replacecontent="true">
  <include name="**/*.fxml"/>
</adjust>

to the rename element of your yguard task. yGuard is not able to adjust method names that are specified as event handlers in FXML, though.

The other, more reliable option is to exclude class and method names that are used in FXML from obfuscation.

[Fohlen]

@yanchikdev did this fix your issue? Can it be closed?
@thomasbehr should we add a fxml example to the examples folder?

[meetinger]

@Fohlen Yeah, I excluded the controller from obfuscation and it worked.
But I still wanted yGuard to be able to rename methods in FXML

[thomasbehr]

@Fohlen As long as yGuard does not support obfuscating method names in FXML files, I do not think an example is the proper place for providing this kind of information. I would prefer to have this piece of information as part of the yGuard documentation.

[Fohlen]

Since yFiles is also offered for JavaFX applications it probably makes sense to add this functionality to yGuard to cover the use case. Moving up on our priority list.

[Fohlen]

@meetinger I've set up an example with FXML support. However there are two issues that currently need to be handled by hand:

• if you reference a method name from your FXML you need to exclude it from obfuscation
• if you use anonymous functions that actually have semantics (e.g ActionEvent.handle) you will need to exclude those from obfuscation as well

I think this is a well enough tradeoff for obfuscation. Most of our use cases do not require "reflecting" the method names from a config. In contrary this is probably not desired, as during deployment / obfuscation you want to be very explicit what gets mapped. Is this as you imagined it and could this issue be closed with it?

[Fohlen]

Closing this because of inactivity and because we see the current tradeoff as sufficient for most use cases.