Mehmet Gunacti

Hi all,

On page 5 of Chapter 2 'Operators', in table 2.1 third column, it says that the Pre-unary operators' evaluation is "Left-to-right", shouldn't it be "Right-to-left"?

This is evaluated from right-to-left, no?
--cookies

edit: the more I think about it, the more confusing it gets.

Since we cannot chain the pre- and post-unary operators (++--x wouldn't compile), does it even make sense to talk about the evaluation order?
Please someone clarify!

Graham Weatherup wrote:I am very interested to know if you found the code malcolmmc mentioned that writes the header to the beginning of the file or could point me to where it would be on the old sun site he speaks of. Or can anyone else tell me how this is done.

Sorry, but I went native.
Never worked with ODB files either.

Good luck with finding a solution. Btw. consider going native

Deepak Bala wrote:

run binary-bytecode...

Assembly you mean ? Here are some links that can clarify the matter for you

Was just wondering why they didn't come up with a method to prevent decompiling Java classes.

It's not possible, I guess, that's why.

Yes, I meant assembly (or machine code). sorry for the inappropriate term.

Thanks for the links.

Campbell Ritchie wrote:

Mehmet Gunacti wrote:. . . an option (parameter maybe ?) that would prevent decompilation ?

As Rob has already told us, if you can execute the bytecode you can decompile it. So it is not possible to prevent decompilation.

You mean, if you can interpret the code, you can decompile it.

Still, there should be a mechanism like, compiling the java source code to binary instead of bytecode. the JVM should then be able to run binary-bytecode...

ok, I was just thinking loud.

AFAIK one is able to decompile .net code (intermediate language ?), too, right ? So I guess MS would have prevented that, if there would be a way to do it.

the question is, why did the designers of Java allow that ?

they must have discussed this, and accepted the fact that Java code will be decompilable.

Shouldn't they have included an option (parameter maybe ?) that would prevent decompilation ?

it's important to know that the left-most brackets get evaluated first.

this produces 7 :
public class Twisty { { index = 0; } int index; public static void main(String[] args) { new Twisty().go(); } void go() { int[][] dd = { { 9, 8, 7 }, { 6, 5, 4 }, { 3, 2, 1, 0 } }; System.out.println(dd[index++][++index]); } }

whereas this code produces 5 :
public class Twisty { { index = 0; } int index; public static void main(String[] args) { new Twisty().go(); } void go() { int[][] dd = { { 9, 8, 7 }, { 6, 5, 4 }, { 3, 2, 1, 0 } }; System.out.println(dd[++index][index++]); } }

well, create an empty project in your favorite IDE and put the original jar file into the build-path.

decompile the class, put the .java file into your source folder (preserve package structure).

after compilation just update the original jar file using Winrar, drag and drop the new class file and overwrite the original one.

That should do the trick ;)

AFAIK there's no guaranty for a 100% success. I wouldn't rely on it.

Take a look at http://java.decompiler.free.fr

Hi,

I think you shouldn't call that 'widen', primitives are getting widened or narrowed, but not objects.

since int[] is also an object and can be assigned to a reference of type Object, it does not get autoboxed and not get 'widened'.

autoboxing happens only between primitives and their wrapper types, so the array hold by the variable "c" actually holds primitive integers as its members.

That's interesting, I just tried this :

public class ABCTest { public static TestStatic ts; public static void main(String[] args) { System.out.println(ts.i); } } class TestStatic { public static int i = 5; }

the output is 5.

now I feel a lot better

Thanks, Nitin !

well, it's just strange that null.someoperation is valid in Java.

I won't write code similar to that for sure, because it's everything but readable.

For the exam, simply memorizing this as a rule should be the best I think.

Hi Nitin,

I just searched for every occurrence of the word 'enum' in the java spec 3.0, but I'm not very good at reading the java specs, and I couldn't find a rule for that behavior.
So I'm still confused.

I get your point with the instance method getSound().

Your explanation clarifies it best :

the compiler substitutes a.DOG.sound with Animals.DOG.sound as it considers DOG as a static object belonging to the Animals class. So, the JVM would not be able to see a.DOG.sound. Hence, a being null is immaterial in this case and the NullPointerException would not be thrown.

IMHO they should have prevented the invocation of static methods / fields over a reference, like in C#.

Thanks for you explanations.

So I just take it as a rule then; enum's can never throw NullPointerExceptions ! (since they are not considered objects (?)).

Hi,

because at runtime "a" refers to an "Animal" object, which you can't cast to a Horse.

This one would work :

Animal a = new Animal(); Horse h = new Horse(); a = h; Horse ha = (Horse) a; ha.eat();