ProGuard on Eclipse product build

Ask a Question
,
1

I don’t know exactly how to ask what I need, so here goes a bunch of information first:

We develop an Eclipse RCP Application.

On our IDE, we installed a plugin called obfuscate4e, that integrates ProGuard on the build process to obfuscate our plugins.

On each of our plugins, we have a custombuildcallbacks.xml file with the following (among other data and instructions):

		<proguard configuration="${basedir}/proguard.cfg" 
			verbose="true" 
			ignorewarnings="true"
			printconfiguration="${temp.o4e.folder}/proguard.cfg">
			<injar dir="${jar.Location}" />
			<outjar file="${obfuscated.jar}" />
			<libraryjar refid="classpath.libs" />
		</proguard>

When we build our product, ProGuard is called as expected and our code is obfuscated. Now that we moved to a new version of Eclipse, that runs on Java 17 (the previous one ran on Java 8), ProGuard does not work anymore.

Trying to debug the process, we could see that when it gets to the ProGuardTask.setConfiguration method,

properties.putAll(getProject().getProperties());

fails because getProject() is null.

Given I have so little information, I don’t think it’s fair to ask “how do I solve my problem?”, so I ask something different: how do I debug it? I don’t understand Ant enough to know how to gather information on why the project might be null.

1 Like
2

Hi @MarioMarinato,

Welcome to the ProGuard Community!

Can you try adding this to your configuration and try again?
-target 8

This will make it use Java 8. If that’s the underlying issue, my hope is this resolves it for you.

Regards,
Jack

3

Hi, @jack, thanks for your kind reply.

I put that on my proguard.cfg file, but the results are the same. I even tried using “-target 11”, because the problem happens when I change the compiler to Java 11 level, but to no avail.

I managed to generate some more debugging info from Ant. But I don’t know what sense to make of it. My console prints this:

  [subant] Failure for target 'post.@dot' of: myproject\customBuildCallbacks.xml
  [subant] The following error occurred while executing this line:
  [subant] myproject\customBuildCallbacks.xml:42: 
        Can't read [myproject\@dot] 
        (Can't read [myproject] (Can't read [Activator.class] 
        (Can't process class [myproject/Activator.class] 
        (Unsupported class version number [55.0] (maximum 52.0, Java 1.8)))))

Edit: after some more digging, it seems to be happening because we’re running an old version of ProGuard (5.3.3). It didn’t support Java 9+, right? Upgrading to 7.3.2 might yield different results. Gonna try that.

Follow-up: after updating to ProGuard 7.3.2, now I get this:

  [subant] Failure for target 'post.@dot' of: myproject\customBuildCallbacks.xml
  [subant] The following error occurred while executing this line:
  [subant] myProject\customBuildCallbacks.xml:42: java.lang.NullPointerException

Which is the same problem I described originally, a null return from a call to getProject(). I wonder if it would be the case of class loading differences because the new proguard.jar is Java 9-based?

4

Thanks for the extra information. May I ask what version of ProGuard you’re using?

As of ProGuard 7.2, we added support for Java 17. That said, I recommend updating to the latest version, if you haven’t already tried that? Then clean and re-rebuild. Let me know if that has any impact for you.

5

Whew, problem solved, and it was not related to ProGuard at all.

As I said, we installed a plugin called obfuscate4e on our Eclipse. When I was trying to update this plugin to use the new ProGuard lib (7.3.2, by the way), I overlooked a configuration I should update. As soon as I realized this and changed the configuration accordingly, everything worked as expected and our code is now being obfuscated.

Thanks for your kind attention!

1 Like
6

Glad to hear it! Mind sharing your configuration so others can learn from this example?

Thanks for the update!
Jack

1 Like
7

The configuration I changed was the following.

As I mentioned, we were updating the ProGuard used on our fork of the now-discontinued obfuscate4e plugin.

The obfuscate4e plugin is in fact a group of plugins, with the following structure:
+ main feature
| + org.obfuscate4e feature
| | - org.obfuscate4e plugin
| | - org.obfuscate4e.help plugin
| + org.obfuscate4e.proguard feature
| | - org.obfuscate4e.proguard plugin
| | - proguard plugin

All of the plugins are versioned as “major.minor.patch.qualifier”.
According to Eclipse’s inner workings, this “qualifier” is substituted on build time to the date and time of the build.

And here was the catch: the proguard plugin, in which the ProGuard jar is placed, DID NOT have the “qualifier” keyword on its version number, a fact I was taking for granted. Because of this, the plugin was not updated properly, because it was being deployed with the same version number. I then changed its version number, to add the “qualifier” keyword.

1 Like