Is there a way to protect Java class files from decompilation or at least make decompilation more difficult?
You’ll never prevent it, as decompilation is literally just recreating source code from the bytecode instruction stack. So, if a VM can run the code, that same code can be decompiled.
The best thing you can do is make your resources/variables as ugly and meaningless as possible. AKA obfuscation
Also why are you trying to protect your source code?
If the reason is that you don’t want other stealing / copying your code, then you shouldn’t bother, code is cheap and easy to write, if there is someone capable of decompiling your code, its highly likely it’ll be easier for them just to write code that does the same thing without even looking at your code.
Interesting statement.
well saying that mainly in comparison to art assets, as there is tons of free source code available compared to free game art/sprites.
Well, it is, really. Maybe not massively cheap or massively easy but certainly not the valuable scarce resource programmers like to pretend it is.
Cas 
IMHO it’s like saying “products are cheap”, making no distinction among products whatsoever.
Sure, most code is cheap and easy to write. There is code that is extremely hard and extremely expensive, because very few people can write such code, demanding lots of investigation and/or high salaries, or simply because lots of programmers with regular salaries did it (slightly) wrong before.
Oh well, we’re getting offtopic
Take a look at yGuard. It’s an obfuscator that’s comparatively easy to use, and it’s free.
A fun feature is that it can produce bytecode, that when decompiled, doesn’t compile back. Class names like “for (int = 0; …” etc. Interesting that the JVM can actually handle a lot worse than what the compiler allows.
Get ready for totally meaningless stack traces, though Really, it’s one of those “if you have to ask, don’t worry about it” types of things. It’s a good bit of trouble to go through.
The compiler actually exploits that extra flexibility in the VM spec for inner classes. But any decent decompiler renames identifiers.
[quote=“pjt33,post:9,topic:36530”]
Right. Was just interesting to me that reserved keywords and the like were ok as class names as far as the JVM is concerned. I suppose inner classes are in part why that extra flexibility is there?
I believe that bad named variabels are enough to make your code unreadable 
[quote=“avm1979,post:10,topic:36530”]
I suspect it’s actually because there’s no need to limit identifiers in the VM spec. In the language spec you have to worry about parsing ambiguities, but in a class file the identifiers are all stored in the string table, IIRC as Pascal-style strings (character count followed by characters).
Ah, that would make sense.
Don’t forget that quite a few of us can read byte code and assembly as well. I really wouldn’t bother with “protecting” the source other than basic variable renaming. I don’t do this for decompiling protection, but because it makes the jar quite a bit smaller and i even notice a small speedup in startup time. Since it costs nothing…
However i do concern myself with it just a little. Not because someone could “steal” my code. Hell i intend to release it GPL later anyways. But for cheaters. Pirates and co don’t matter much. But cheating can really ruin the ability of a game to do well.
Problem is that even i can write cheats easy enough just from the byte code, or from some live mem dump tools. So I am not even sure it can be done without active measures.
If you want to ‘protect’ your integers from being found by a mem-dump analyzer, use this wicked class:
/*
* Created on Apr 7, 2011
*/
import java.util.Random;
public class RazzleDazzleInteger extends Number
{
public static void main(String[] args)
{
RazzleDazzleInteger i = new RazzleDazzleInteger();
System.out.println(i + " => " + i.get());
System.out.println(i + " => " + i.get());
i.set(1337);
System.out.println(i + " => " + i.get());
System.out.println(i + " => " + i.get());
}
private static final Random XOR_SOURCE = new Random();
private int stored;
private int xor1;
private int xor2;
public RazzleDazzleInteger()
{
this(0);
}
public RazzleDazzleInteger(int value)
{
this.xor1 = XOR_SOURCE.nextInt();
this.xor2 = XOR_SOURCE.nextInt();
this.set(value);
}
public int set(int value)
{
this.barrelshift();
this.stored = this.xor(value);
return value;
}
public int get()
{
return this.set(this.xor(this.stored));
}
@Override
public String toString()
{
return RazzleDazzleInteger.class.getSimpleName() + "[value=" + this.get() + ", stored=" + this.stored + "]";
}
// methods from java.lang.Number
@Override
public double doubleValue()
{
return this.get();
}
@Override
public float floatValue()
{
return this.get();
}
@Override
public int intValue()
{
return this.get();
}
@Override
public long longValue()
{
return this.get();
}
// conv.
private final int xor(int value)
{
return value ^ this.xor1 ^ this.xor2;
}
private final void barrelshift()
{
int shift;
shift = 3;
this.xor1 = (this.xor1 << shift) | ((this.xor1 >> (32 - shift)) & 0x07);
shift = 1;
this.xor2 = (this.xor2 << shift) | ((this.xor2 >> (32 - shift)) & 0x01);
}
}
Because one modifying XOR key is not enough! 
I think the big problem with doing something like this is (as mentioned) that your stack traces become totally borked. I for one find stack traces incredibly important. You can maybe do something that basically creates a dsym file and something that can translate for you, but it all seems like it’s more trouble than it’s worth. Whether or not code is cheap, you’re the one who wrote it and so you are by far the best one to improve and add to it. I could get your code and make my own changes to it, but it wouldn’t be your code anymore, it would be a mod.
@OP: but once again the first thing that will be do is to replace those encrypter class (decompile/modyfing/recompile)… definitly nothing really safe you can do client side
yGuard provides a pretty handy utility that lets you paste obfuscated stack traces into a console and get back readable ones, provided you keep around the file with the mappings. It’s still a big pain, though.
The xor trick does kinda work. Quite a few games do it, so folks look for it (your xor fields tend to be next to the relevant field). But probably not double XOR power!! :o
Well, the code of one game is only good for making that one game. I’m also only aware of one case where 2 Flash games were illegally reskinned. Typically complete games get stolen, because… y’know… reskinning requires some actual work.
Reusing parts of some code also doesn’t look very feasible.
Media is probably more useful, but that stuff is typically only used as placeholder or it’s used for some tiny hobby project. No real damage there.