Problem with editing jar

[DanielR]

Hey, as you know it, i'm very, very new to Java. Its really cool and fun.
But lets get to the problem.

Okay, so i'm editing this .jar file, and it has multiple .class files. I want to edit a class file, so I decompiled it with a decompiler. So, I got the source. Now what i'm trying to do is recompile the edited .java file. The console gives me errors, (Cannot find symbol errors), and it cannot find different values and variables located in different class files. So, I am wondering how to get those values from the class files, so the console does not return errors and compiles it.

If you need a sample problem, here:

*.java:215: cannot find symbol
symbol  : variable yd
location: class *
      this.yd = (float)(this.yd - 0.02D);

Variable "yd" is explained in another file.
Is there an addition to the command for it to use the other files' variables?
Theres a ton of these problems, and all the variables are contained in the other files.

I'm sorry if i'm missing something obvious. Its hard to explain this, i'm a beginner.

[Junky]

Where did you get the jar file from?
Are you allowed to modify it or is it covered by copyright?

[DanielR]

Where did you get the jar file from?
Are you allowed to modify it or is it covered by copyright?

Its 100% not copyright. Its accually an example jar. (Meant to be edited).

[DanielR]

Err... can someone help? Sorry about double post...

[DanielR]

Ok, then, looks like this seems impossible.

[pbrockway2]

When you recompile a source file be sure to specify the classpath correctly so that the compiler can correctly resolve things.

*.java:215: cannot find symbol
symbol  : variable yd
location: class *
      this.yd = (float)(this.yd - 0.02D);

This is intriguing/unbelivable. I wouldn't have thought * was a valid class name. If it is then Windows developers are in for a hard time!

One thing to bear in mind is that decompiled code is not always valid.

[DanielR]

When you recompile a source file be sure to specify the classpath correctly so that the compiler can correctly resolve things.

*.java:215: cannot find symbol
symbol  : variable yd
location: class *
      this.yd = (float)(this.yd - 0.02D);

This is intriguing/unbelivable. I wouldn't have thought * was a valid class name. If it is then Windows developers are in for a hard time!

One thing to bear in mind is that decompiled code is not always valid.

Oh no. I just used "*" for an example jar/class. It could be anything. And how would I define a classpath? Does that tell the compiler where to find those variables?

[pbrockway2]

The javac man page has details. The -cp -d and -sourcepath options should all be thought about.

[DanielR]

The javac man page has details. The -cp -d and -sourcepath options should all be thought about.

... Man page.... Ok... well, it seems that it includes a lot of helpful information.

[DanielR]

Ok, another problem.

Heres an example of the problem:

I have test.jar in my /bin directory. I also have my test.java in the same directory.

I put in:

javac -classpath test.jar test.java

It still gives me "Cannot find symbol: yd" and so on.

...Am I doing something wrong? Doesn't classpath define the jar for variables...?

[pbrockway2]

It's quite hard to say seeing the code, the command and the exact messages that are output.

Back in you original post the missing yd symbol was used as part of the expression this.yd and the compiler complained about that. You said that the variable was "explained in another file". I guess you meant it was declared in another class. But the thing is if a file being compiled includes the expression "this.yd" then there must be a yd variable declared in the very class where that expression occurs.

A variable yd in some other class won't even be considered. That's the intent of "this" in the expression this.yd

The -classpath tells the compiler where to find classes.

[DanielR]

It's quite hard to say seeing the code, the command and the exact messages that are output.

Back in you original post the missing yd symbol was used as part of the expression this.yd and the compiler complained about that. You said that the variable was "explained in another file". I guess you meant it was declared in another class. But the thing is if a file being compiled includes the expression "this.yd" then there must be a yd variable declared in the very class where that expression occurs.

A variable yd in some other class won't even be considered. That's the intent of "this" in the expression this.yd

The -classpath tells the compiler where to find classes.

Hmm... So, I need to decompile all the class files and recompile them at the same time?

[pbrockway2]

So, I need to decompile all the class files and recompile them at the same time?

Not at all.

If it were me I would extract the contents of the jar archive. Decompile the class I wanted to change. Alter the source. Recompile.

(But note my comment above that decompilers are not 100% accurate - or so I have found. It is *much* nicer to work with the actual source. You say that this jar was *meant* to be edited: in that case suggest to whoever provided it that they include the source files within the jar archive.)

[DanielR]

Not at all.

If it were me I would extract the contents of the jar archive. Decompile the class I wanted to change. Alter the source. Recompile.

(But note my comment above that decompilers are not 100% accurate - or so I have found. It is *much* nicer to work with the actual source. You say that this jar was *meant* to be edited: in that case suggest to whoever provided it that they include the source files within the jar archive.)

I indeed did that, but I felt better with a decompiler, but now you say that....

But anyways, wouldn't that give me errors also? Wouldn't it not find the classes/variables/etc?

[pbrockway2]

But anyways, wouldn't that give me errors also? Wouldn't it not find the classes/variables/etc?

This is sort of going around in circles. You will get errors reporting a class not found if the classpath is not correctly specified or if the decompilation is not accurate.

You will get symbol not found errors if the decompiled source uses a variable that has not been declared. (And, for valid .class files this will be an inaccuracy in the decompilation.)

So... You make sure the classpath (and other compiler options) are exactly what you want them to be. And you fix errors in the decompiled source in the same way as any other source code: by debugging it.

For instance the error you begin the thread with is saying that a variable yd was not declared as a class or instance variable of the class where the expression occured. (The class you called *). So you fix that by either declaring that variable or changing the expression so that it does not use the variable, whichever better expresses your intent.

[DanielR]

This is sort of going around in circles. You will get errors reporting a class not found if the classpath is not correctly specified or if the decompilation is not accurate.

You will get symbol not found errors if the decompiled source uses a variable that has not been declared. (And, for valid .class files this will be an inaccuracy in the decompilation.)

So... You make sure the classpath (and other compiler options) are exactly what you want them to be. And you fix errors in the decompiled source in the same way as any other source code: by debugging it.

For instance the error you begin the thread with is saying that a variable yd was not declared as a class or instance variable of the class where the expression occured. (The class you called *). So you fix that by either declaring that variable or changing the expression so that it does not use the variable, whichever better expresses your intent.

I see what you mean by declaring, but it already is declared in another file, I think.

I.e. Variable yd is described in test.class while *.class needs yd, already in the other file...

Does everything have to be described in one class file? Or can it be separate?
If it can't be separate, well, thats what I mean. If not, then we are screwed.

[pbrockway2]

In the error you posted yd occurs as part of the expression this.yd

As I said before there must be a variable yd declared as a class or instance variable of the class containing the method or constructor using the expression. No other class will do! Even if another class declares a different yd, it won't be considered by the compiler when trying to determine what "this.yd" means.