yGuard 1.3.2 Release Notes
Contents
Please read the documentation for
installation instructions.
Technical requirements
yGuard requires Java2 SDK 1.3.x or greater (1.4.x if you want to use the automatic resource file adjustments)
and Ant 1.5 or greater installed on your system.
It may work with earlier versions of these pieces of software as well, however this has not
been tested thoroughly. yGuard 1.3.x works together with Ant 1.6.
Changes since 1.3.1_01
-
Improved name generation. yGuard will now generate legal identifiers
(with respect to
Character.isJavaIdentifierStart()
and Character.isJavaIdentifierPart(char)
and
Character.isIdentifierIgnorable(char)
) and should
therefor produce jars that should verify correctly even on older jdks
if yGuard is run using newer jdks.
-
yGuard now helps in the detection of duplicate class files in source jars.
In pedantic mode yGuard will terminate if duplicate classes are detected
in different source jars. yGuard's obfuscate task will always fail if mutliple
class files containing a definition for the same jar are detected. The log file
displays useful information for finding the duplicate entries.
-
Improved xml log file output for Unicode characters.
-
Made the log file viewer output more consistent with inner class names that
were being mapped during obfuscation versus those who remained fixed.
-
Jar file entries are now being sorted prior to being written to the jar.
-
Improved handling of external classes.
-
Bugfixes:
- Fixed a name clash problem that occurred when already obfuscated code
was being obfuscated again using different settings.
-
Fixed a resolution problem concerning interfaces from external classpaths.
Changes since 1.3.1
-
yGuard now treats the COMPATIBLE flag for the language conformity different.
Field names and class names are now made up of lower ascii-only chars.
-
Bugfixes:
- Fixed a problem concerning the
adjust
elements throwing
a RuntimeException
in the pattern matching code.
-
Fixed a problem where the wrong set of files was affected in the
adjust
section.
Changes since 1.3
-
yGuard will now generate (empty) directory entries in the resulting jar files for each non-empty directory.
-
Improved the optional keeping of "Deprecated" tags. Somehow they still seem to get lost under certain conditions.
Any feedback on this topic is welcomed.
-
Due to a compile time dependency, yGuard could not be used with jdk 1.3.x anymore even if the automatic
resource adjustment feature was not used. This has now been made possible again.
-
Bugfixes:
- Fixed a rare problem that broke obfuscated code using static method
invocations and static field references.
-
There was a bug in the log file viewer (
java -jar yguard.jar [logfile.xml[.gz]]
) that made it crash
under very rare circumstances.
-
Implemented a workaround for an Ant incompatibility problem, which resulted in yGuard behaving differently on
different platforms and in conjunction with different Ant versions.
Changes since 1.2
-
Added automatic text file and property file renaming mechanism. yGuard can
now be configured to rename .properties files according to the obfuscation.
-
It is now possible to process text files and replace occurances
of class names with their obfuscated versions.
-
One can now specify whether resource files should be kept in their original
directory while at the same time the classes residing in the respective
directory can be fully obfuscated to another package.
-
yGuard can now automatically create gzipped (.gz) logfiles and work directly
on compressed logfiles. This reduces the size of the logfiles drastically.
-
It is now possible to simply specify a list of attributes, that should not be
removed by yGuard (for example "
Deprecated
") using the
expose-attributes
property.
-
yGuard has a new name generation method (
language-conformity
= compatible
),
that creates jar file that can be successfully unzipped to the windows
filesystem.
-
In order to avoid namespace clashes, on can now easily specify a prefix
for completeley obfuscated package hierarchies using the
obfuscation-prefix
property.
-
Enhanced documentation (DTD, examples, and new features description).
-
Bugfixes:
- Innerclasses making use of the .class construct should now always be
correctly obfuscated using the replaceClassNameStrings feature.
-
The
patch
element had a bug concerning field name mappings,
which is now resolved.
-
yGuard now tests whether a newly obfuscated name already exists in external
jars and automatically generates names, that should not clash.
-
yGuard should now work together with Ant version 1.6 (there was an undocumented change in the API of Ant).
Changes since 1.1
Changes since 1.0.1
-
Added support for different naming schemes. These schemes result in smaller
jar files, better obfuscation and lead to jar files,
which cannot be unpacked to normal filesystems.
-
Fixed two JBuilder incompatibilities. Innerclasses created by JBuilder do
not prevent yGuard from working anymore and (correct) innerclasses created
by yGuard do not crash JBuilder anymore (which btw. is a bug in JB).
-
Implemented a fix for the problem, where the
ClassName.class
code construct prevented classes from being obfuscated entirely.
-
yGuard can now automatically obfuscate code of the form
Class.forName("com.mycompany.myapp.MyClass");
so that these classes can now be obfuscated by name, too.
-
Improved the serialization of the obfuscation map to the xml file, which can
now be parsed back in by the included tool even for complicated naming
schemes.
-
Refactored the creation of the final jar files. The current implementation
leads to more standard conform jar files.
-
Fixed two bugs concerning the handling of manifest files.
-
Fixed a bug concerning the handling of the Main-Class attribute of manifest
files.
Changes since 1.0
-
Implemented more robust handling of Manifest files. Implementation now makes
use of java.util.jar.Manifest.
-
The Main-Class attribute of the Manifest files will now be translated to the
obfuscated name, if the main class is not exposed.
-
The conserveManifest attribute of the obfuscate task now conserves the
manifest in a better way.