ant task supporting non string properties in gradle context


While converting a very old ANT task using IzPackTask into a gradle build environment I got strange class cast exceptions. I found this happens when using inheritAll: 'true' to configure and inherit ant properties.

While within ANT such properties are generally strings, the internal representation however uses a Hashmap<String, Object> of objects.

In contrast to ANT, gradle uses project properties of various types. Those are commonly groovy.lang.GString instead of java.lang.String or even i.E. Integer objects. When using inheritAll: 'true' those will end up as ANT properties.

This happens to me using an ancient izpack 4.2. The problem arises while casting the value to String , which is still a relic of Java 1.1 I think. The problem can be solved easily by calling projectProps.get(name).toString(); instead.

I tried a big jump to izpack 5.1.4 but I got the same problem here.
Interestingly the cause is not that obvious here:

Some code moved to IzpackAntRunnable. Here a Hashtable<String, String> is used and thus no casting seems necessary any more. Unfortunately it does not work as intended:

While the IzpackAntRunnable constructor requires a Hashtable<String, String> it is initialized by reflection using a newInstance() call. Unfortunately getProject().getProperties() still provides a Hashtable<String, Object>. This fault is hidden since reflective calls are not typesafe.

I'm about to prepare a pull request.


ant task within gradle context


Dieter Stüken
December 6, 2018, 2:11 PM

I think the correct way is to use a Hashtable<String, Object>.

Will there be some fix for the 4.x branch, too?

The code may also be refactored:

Using a Hashtable is a Java 1.1 relic and thus are those iterations using Enumeration. A Hashtable implements a Map since Java 1.3 and may be obsoleted all together. The iteration may take place using a for-each-loop on projectProps.entrySet() instead (or using forEach or even streams if izpack ever reaches Java 8 )

BTW: A similar refactoring currently takes place on ANT, too.




Dieter Stüken


Functional - non-breaking and safe in existing environments


Fix versions

Affects versions