how to decompile jars programmaticaly?

[misterX]

well, that's the question!
does anyone of you have a code sample or know of a good link?

[jbanes]

Decompile a JAR? Do you mean unjar/read all the files inside? You can do that with the java.util.jar package. For decompiling class files programatically, check out the Byte Code Engineering Library.

[misterX]

yeah, that's what i meant. To programatically copy contents of a jar file into a classic folder. I guess that now that i know 'java.util.jar' should be used, i'll be able to find my way out. thanks!

Games published by our own members! Check 'em out!

[misterX]

I just found this on the web, which seems to be the solution to unjar a jar:

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25   26   27   28   29

/* put the absolute file name of the jar file which is to be unjarred*/ String strJarFileName="dir1/dir2/jarfilename"; flJar=new JarFile(strJarFileName); Enumeration enuJarEntries= flJar.entries(); while (enuJarEntries.hasMoreElements()) { JarEntry jeOneFile=(JarEntry)enuJarEntries.nextElement(); //strTempDir is the Dir where the files are to be unjarred flOneFile=new File(strTempDir+"/"+jeOneFile.toString()); if (jeOneFile.isDirectory()) { flOneFile.mkdir(); } else { CheckedInputStream cisOneFile=new CheckedInputStream (flJar.getInputStream(jeOneFile),new CRC32()); fw=new FileWriter(flOneFile); bw=new BufferedWriter(fw); for (int i=0;i<jeOneFile.getSize();i++ ) { bw.write(cisOneFile.read()); } bw.flush(); bw.close(); fw.close(); } }

I haven't tested it yet but i suppose it should work.

[jbanes]

That code should work fine.

If you don't mind my asking, what do you need it for? Other than archive managers, there are usually very few reasons to extract a JAR file to disk.

[misterX]

it's because of webstart! :-P everything must be packaged in jars, including game elements such as level data. So once downloaded, it'll "unjar" the level data files in some directory and when starting the game, the player chooses the level to play by selecting a level data from the list of files in the given directory. That way, custom or self made levels can be added afterwards.

but i'm starting to hesitate doing this because the directory be either an "annoying one", or a self chosen where are only the track data, which is not very nice either. And duplicate data!

[jbanes]

There's no need for this sort of design. If you have everything packed in a JAR file, just create a meta file explaining the levels. You game can read the meta file directly from the JAR, then load the level files as appropriate. For example, let's say your meta file is a Properties file called "levels.properties". You could load it with the following code:

1   2

Properties props = new Properties(); props.load(getClass().getResourceAsStream("/levels.properties"));

You can use the same "getResourceAsStream()" method for all the files you need to load from the JAR. Just make sure that your level files point to JAR paths, not filesystem paths.

[misterX]

i guess this is perfect for "constant things"...

here is another example to illustrate why i way thinking of the unjar mechanism:
do you know starcraft? here when you launch a game, you'll have to choose the map you'll be playing on. Since it's in a known directory, it's easy to make custom maps with the map editor and add them into it, or to download additionnal maps on the net and put them in the folder and it's also where downloaded maps are put in when you're in a multiplayer game with a map you don't have yet.

but, as said before, i'm  hesitating to do this because the directory will either be an "annoying one", or a self chosen where are only the track data, which is not very nice either. And duplicate data!

But thanks for the tip above... it can maybe be usefull... is it also possible to write things that way? (without having JWS replacing the jar each time?)

[blahblahblahh]

For the specific problem of downloadable maps etc, I would suggest the webstart muffins, recently demonstrated by Onyx. For a webstart game you REALLY shouldn't be downloading big chunks of stuff onto a random place on the hard disk.

[misterX]

1. why?
2. who said they were big?
3. what have muffins to do with a file system? You won't be able to do what was explained just before!

Games published by our own members! Check 'em out!

[pepe]

MisterX: Since you are willing to use Webstart, i think you might better have a look at what it proposes.
Look there:
http://java.sun.com/j2se/1.5.0/docs/guide/javaws/jnlp/javax/jnlp/package-tree.html
where you'll even find classes that will give secure access to any file you might create on client , without any hassle of user directory.
That page should provide any info and classes you will need.

[kevglass]

The problem with FileContents and the PersistanceService is you have no idea when the actual files end up tho.

Kev

[blahblahblahh]

1. why?

Because webstart apps shouldn't be installing random crap on people's computers in places such that when the app is removed the crap remains behind.

2. who said they were big?

You talked about maps. Maps are almost never small. Small is hundreds of bytes. Maps often come with extra resources (art, sound effects), often making them big.

3. what have muffins to do with a file system? You won't be able to do what was explained just before!

Why not? (confused)

[misterX]

yeah, that's true, i had in mind that removing the app without removing that folder would be annoying. Even if the user knows where it is, he should remove it manually. As for maps or other level datas, i think it's more usual to just save the data and let the pictures/models/sounds be shared ressources already in the game. But i agree this cannot always be done, depending of the kind of game. In my case, i only save data, so level datas are just some kb.
And using muffins, you just can't add a level data file in a folder to play it, and anyway, you would need a folder too. (the aim was that a user could place a file in a folder to play it after all!) 

I guess the best thing to do is to place the default levels in a jar downloaded together with the game, and place an "import button" to open a custom level data file somewhere on the disk.

[blahblahblahh]

i think it's more usual to just save the data and let the pictures/models/sounds be shared ressources already in the game.

What you find is that you often need to make some modifications for each new level - an extra skin here, an extra model there, etc - so that in general most levels have at least *some* extra resource. There are several ways of dealing with this (one of which is webstart's own way - i.e. you just have every level reference the assets it needs, and sometimes the user will already have them, sometimes they won't - but that requires a lot of organization, which may not be possible if you accept packs from many sources).

I guess the best thing to do is to place the default levels in a jar downloaded together with the game, and place an "import button" to open a custom level data file somewhere on the disk.

I was kind of assuming you'd want to download the levels in-game anyway, since that's nicer for the user - they don't need to work out which folder (I've had problems where you can never work out precisely which folder to drop something in - and when it doesn't work you don't know if that's because it's broken or you put it in the wrong place, etc), and it feels more professional.

Like with battle.net, or Wurm Online, where the plugin etc management is all in-game...

PS: this is something Kev and I have been mulling over recently (or at least *I* have) because it's a PITA if you design it badly, and we need to sort out how survivor will do it from now on. The current system is too kludgy and hacked together . Although...I have to say, it does EXACTLY what you were originally asking for - and I apologise that we haven't posted the source code for it yet (it's in a folder marked "source code to post on JGF as soon as JGF gets a code section").