yGuard Changelog

yGuard 2.2.0 - Changes since 2.1.0

yGuard is now fully JDK-1.6 compatible.
The yGuard task now supports a way of specifying a set of Jar files that should be obfuscated at the same time using simple patternset syntax.
yGuard now uses the same technique for all elements in the MANIFEST file to adjust fully qualified class name strings.
It is now possible to tell yGuard not to obfuscate specific package names.
yGuard can now be given a list of digest algorithms that will be used to create the digests in the manifest.
yGuard now issues a warning if the package or class or method name of a native method is obfuscated.

Fixed a bug that caused yGuard to throw a NullPointerException if an attribute element contained no nested patternset.
Fixed a bug that caused yGuard to use multiple logging instances if a yGuard task was executed multiple times.
Fixed LineNumberTable and SourceFile elements.
Added overloadEnabled property.

Fixed a bug that caused yGuard to fail during class file parsing if a method signature contained an inner class of a parameterized class.
yGuard will not complain about the Java 1.5 attributes Bridge, Enum, and Varargs as 'unknown attributes' anymore.
Fixed a bug that caused all class names to be kept from renaming if the extends attribute was used in combination with the classes attribute.

Fixed an inconsistency between the interpretation of the Ant syntax in the rename and shrink elements. Now, both elements apply patternset elements in nested method and field elements to class names, just as stated in the yGuard documentation.
If the classes attribute of the class element is not set or set to "none", the shrinking engine will now include the classes that match based on the given name attribute or nested patternset, effectively ignoring the classes attribute.

New elaborate code shrinking functionality.
More powerful Ant syntax: extends/implements attributes for the class element.
General Ant syntax changes due to the introduction of the new yguard, shrink, and rename elements.
yGuard now needs Java 2 SDK 1.4.x or greater to function properly.

Fixed bad treatment of the new enclosing method feature in Tiger which sometimes led to AbstractMethodErrors at runtime.

Improved obfuscation logic for enumerations. Now the two static methods valueOf(String) and values() don't have to be exposed manually anymore.
Fixed bad annotation handling for non-trivial annotations. Annotations had not been parsed and handled correctly, which could lead to either errors during obfuscation or Errors at runtime.

Fixed a bug that made yGuard ignore some of the attributes in the expose section ("sourcefile" and "linenumbertable").
Fixed a rare but severe bug that accidentally removed method attributes and sometimes led to ArrayIndexOutOfBoundsExceptions during the obfuscation.

Added JDK 1.5 (a.k.a Java 5.0 code-named Tiger) compatibility. yGuard can now deal correctly with the new JDK and Java features: generics, var-args, enumerations, annotations, new ".class" bytecode construct, signatures, local variable type table, enclosing method information.
Implemented the ability to obfuscate/scramble/shrink line number information. This makes it possible to more easily debug stacktraces without exposing line number information in the obfuscated version of the application.
Implemented the ability to obfuscate the source file information. This is necessary in order to view line number information in stack traces. It is now possible to reassign the source file attribute inside class files so that the original source file name is not exposed in the obfuscated application.
Added the ability to determine on a per-class basis what attributes to expose or obfuscate. This includes line number information (with optional scrambling/compression or removal), source file attributes, deprecation attributes, etc. This makes it easy to obfuscate parts of your application while keeping the public API untouched and debug information for third party jars intact.
Improved the stacktrace deobfuscation tool. It can now unscramble line number information from stacktraces, features a more polished view of the mapping rules and deobfuscates stacktraces more reliably if the stacktraces are ambiguous.