problem running the new jar

Help
Amit Rana
2002-04-30
2004-05-12
  • Amit Rana

    Amit Rana - 2002-04-30

    Hi,
    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?

    TIA.

     
    • Thorsten Heit

      Thorsten Heit - 2002-05-03

      You're absolutely right :-)
      The current version doesn't rename that attribute, but it will be implemented the next couple of days.

      Thorsten

       
      • Thorsten Heit

        Thorsten Heit - 2002-05-03

        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:

        .class my/package/MyClass
        .method my/package/MyClass/main

        The 'Main-Class' attribute isn't touched currently so your Jar file should start the usual way.

        Thorsten

         
        • Amit Rana

          Amit Rana - 2002-05-07

          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?

           
          • Thorsten Heit

            Thorsten Heit - 2002-05-07

            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.

            Thorsten

             
    • Amit Rana

      Amit Rana - 2002-05-08

      JavaGaurd seems to be quite promising tool. I havent looked in much but it seems I am attached with it now :-)

       
      • Thorsten Heit

        Thorsten Heit - 2002-05-08

        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....

        Thorsten

         
        • Nobody/Anonymous

          Our company is having this particular problem with RetroGuard right now.  If your program was based on that, you might find this helpful.

          > http://java.sun.com/j2se/1.4/docs/tooldocs/tools-changes.html


          > 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.

          JQ@Polexis
          http://www.polexis.com

           
          • Thorsten Heit

            Thorsten Heit - 2002-06-11

            Thanks for your hints, but the problems are already solved inside JavaGuard - it even obfuscates classes compiled with "-target 1.2" or higher :-)

             
    • Nobody/Anonymous

      Since my Applet class (in the jar) was not found,
      I specified it in the script like this
      .class mypackage.subpackage.MyApplet

      Now my Applet is found but all classed that this
      Applet depends on are not found.

      Any hint?

      Thanx!
      Marcus

       
      • Nobody/Anonymous

        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???

        Regards,
        Marcus

         
        • Thorsten Heit

          Thorsten Heit - 2002-07-14

          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:

          .preserve hardcodedreferences

          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:

          .class myPackage/MyClass

          or

          .ignore myPackage/MyClass

          I'm currently working on a solution so that JavaGuard also processes these references correctly.

           
    • Nobody/Anonymous

      Hello,
      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?

       
    • Nobody/Anonymous

      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...
      thanks...

       

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks