1. I am using javaguard-1.0beta2 on jdk1.3.1_03
2. How do I know the new startup class name?
'Main-Class' attribute in my Manifest file, contains the old Class name.
1. Shouldnt JavaGaurd rename this name also?
2. how do i run my application after all the names are changed?
You're absolutely right :-)
The current version doesn't rename that attribute, but it will be implemented the next couple of days.
I forgot to mention:
1) You can find out the name of your startup class by looking into the logfile.
2) To be able to run the Jar file you can add the following two lines to your script file:
The 'Main-Class' attribute isn't touched currently so your Jar file should start the usual way.
Thanks for your reply.
I tried all your tips but it didnt help me. I was getting "java.lang.NoClassDefFoundError", so I thought as JavaGaurd is changing the class file name so may be its unable to get the required classes in the jar. I used script file so that JavaGaurd doesnt change the class name but then error was coming on another file.
Problem was following
I had following in my manifest file
Class-Path: ./lib/jhall.jar ./lib/help.jar ./lib/ipworks.jar ./lib/jaxp.jar ./lib/crimson.jar . myTool.jar
this line was trucated by JavaGaurd to
Class-Path: ./lib/jhall.jar ./lib/help.jar ./lib/ipworks.jar ./lib/ja
so all the classes in jaxp, crimson and myTool we giving problems.
Now everytime i use JavaGaurd i have to change its manifest file.
isnt this a bug?
Yes, indeed. I'm currently working on a new Manifest file parser that a) will avoid that problem and b) automatically renames the "Main-Class" attribute correctly.
A preview version of the new parser is already contained in the CVS, and the (hopefully :-)) final version will be checked in in a couple of hours.
JavaGaurd seems to be quite promising tool. I havent looked in much but it seems I am attached with it now :-)
Thanks, nice to hear :-)
I'm still trying to find out why JavaGuard doesn't work correctly under JDK 1.4; I hope to have some results the next days....
Our company is having this particular problem with RetroGuard right now. If your program was based on that, you might find this helpful.
> The javac byte-code compiler has a new -source option that enables
> support for compiling source code containing assertions. Also, default
> compilation is for -target 1.2. Previously, the default was 1.1. The
> compiler now correctly detects unreachable empty statements, as
> discussed in bug 4083890. Javac also recognizes the new -Xswitchcheck
> option that checks switch blocks for fall-through cases and provides a
> warning message for any that are found
In other words, up until 1.4 Java compiled 1.1-compliant classes. Now they compile for 1.2 compliancy, and include assert bytecode, which is what kills RetroGuard (at least for us, it fails thinking the classes are 'corrupt').
You can use -target 1.1 to remove the errors. Obviously it would be better to support asserts in your obfuscator, though.
Thanks for your hints, but the problems are already solved inside JavaGuard - it even obfuscates classes compiled with "-target 1.2" or higher :-)
Since my Applet class (in the jar) was not found,
I specified it in the script like this
Now my Applet is found but all classed that this
Applet depends on are not found.
To have more details on the problem I decompiled the output of JavaGuard.
So I found that the problems occour when a class is referenced, e.g. MyClass.class.
As the class is obfuscated (e.g. "a") but the reference is not (still "MyClass.class") the class cannot be found by the reference.
Is this a bug???
Currently JavaGuard doesn't process classes that are used in references such as "Class cls = MyClass.class". Your obfuscated code will cause a "ClassNotFoundException" in that case.
To circumvent that behaviour you should add the following line to your script file:
This tells JavaGuard to not obfuscate the names of _all_ classes that are used in such references. This makes sense for example if you're obfuscating a huge Jar file and don't know all these classes.
If you know which classes are used in such a way you could also tell JavaGuard to either not obfuscate their names or to fully ignore them:
I'm currently working on a solution so that JavaGuard also processes these references correctly.
I run javaguard and it works fine but the produced jar file doesn't work. In the produced log file I found : warning ... class not found ... verify your classpath and my classpath is well defined... I think !
any help please?
I'd Like to know if those problems are fixed on beta4. I got this problem. After obfuscating my classes, my MANIFEST was not atualized corrected, and a noDefMainclass exception was launched...
If I ignore this class, all subsequent classes it calls I get an error of classnotfound...
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.