JAR in a JAR

[JPractitioner]

Hi guys, I have no problems of creating a JAR. However, it happends
that the JAR i am creating will depend on other JARs. I have no
problems with this either, since i know how to set the class-path on
the manifest file.

However, I am trying to keep all .class .xml .dtd .jar that my program
is depending on ... into one big JAR only. This way, I can hide the JAR
file and xml file that i am depending on.

Anyone knows how to do this??

TIA

 

[Philip Reimer]

Hi guys, I have no problems of creating a JAR. However, it happends
that the JAR i am creating will depend on other JARs. I have no
problems with this either, since i know how to set the class-path on
the manifest file.

However, I am trying to keep all .class .xml .dtd .jar that my program
is depending on ... into one big JAR only. This way, I can hide the JAR
file and xml file that i am depending on.

Anyone knows how to do this??

TIA

If you're using Eclipse you might want to take a look at the fatjar plugin.

HTH,
Philip

 

[Andy Dingley]

Anyone knows how to do this??

Nope.

You can place JARs into JARs, but class loaders don't like it and you
can't (practically) run JARs within JARs. So although you can do this,
you can really only use them as a kind of "labelled ZIP file", just as
a transport medium for deployment. Once you get them onto the users
machine then you have to unpack them before use. So why not just use
ZIP files ?

If you use IzPack you can make the outer JAR a self-extracting IzPack
JAR, so long as it could run the install without dependencies on
anything in the contained JARs. This certainly wokrs, and it's
certainly "JARs within JARs", but it's just a deployment wrapper, it's
not especially exciting.

 

[Andrew Thompson]

JPractitioner wrote:
......

However, I am trying to keep all .class .xml .dtd .jar that my program
is depending on ... into one big JAR only. This way, I can hide the JAR
file and xml file that i am depending on.

That strategy will fail. Someone that wanted to know
could crack open the files (each successive layer)
with (a program as generic as) Winzip.

What is it about the code that is so bad
you want to hide it, anyway?

Andrew T.

 

[Furious George]

JPractitioner wrote:
.....

That strategy will fail. Someone that wanted to know
could crack open the files (each successive layer)
with (a program as generic as) Winzip.

Correct. Obviously cracking open the files will be trivial.

What is it about the code that is so bad
you want to hide it, anyway?

I assumed that the OP meant his clients were brain-damaged imbeciles
who could not deal with the concept of multiple jar files.

It is trivial to put everything into one jar file. One way would be to
make the project using multiple jar files. Then extract everything
from all jar files to a single directory. Then jar that directory.
Voila. The resulting jar has the entire project.

 

[Andrew Thompson]

Correct. Obviously cracking open the files will be trivial.


I assumed that the OP meant his clients were brain-damaged imbeciles
who could not deal with the concept of multiple jar files.

Ohhh.. right. That concept had not occured to me.

It is trivial to put everything into one jar file.

Good point, that would achieve just the same
effect fir the situation that you described, ...

But I still disagree with that strategy, when this
can be done more effectively using WebStart.
WebStart can not only 'hide' all the disparate
jar's behind a single URL, but ..

a) if any one of those jars is required by a second
(or further) project/s, the end user can get both
projects on-screen while only dowloading the
common classes once.
b) If the classes in one (e.g. small) jar are updated,
the user can get an (automatic) update of just that
one jar. Much more efficient.

Andrew T.

 

[JPractitioner]

That strategy will fail. Someone that wanted to know

could crack open the files (each successive layer)
with (a program as generic as) Winzip.

hehe... i am aware of that.

What is it about the code that is so bad
you want to hide it, anyway?

nothing bad, just dont want the customer to know what library (actually
a 3rd-party open source library) we are using to cater their needs. But
its OK now, I'm not going to proceed this due to time constraint.

thanks for the reply

 

[JPractitioner]

That strategy will fail. Someone that wanted to know

could crack open the files (each successive layer)
with (a program as generic as) Winzip.

hehe... i am aware of that. was thinking to hide them as much as
possible..

What is it about the code that is so bad
you want to hide it, anyway?

nothing bad, just dont want the customer to know what library (actually
a 3rd-party open source library) we are using to cater their needs. But
its OK now, I'm not going to proceed this due to time constraint.

thanks for the reply

 

[Andrew Thompson]

JPractitioner wrote:
...

...dont want the customer to know what library (actually
a 3rd-party open source library) we are using to cater their needs.

To acheive that goal, it would be more effective to
obfuscate.

Andrew T.

 

[JPractitioner]

Hi all,
just want to say thanks for the replies.

bye for now.

 

[Rogan Dawes]

Hi guys, I have no problems of creating a JAR. However, it happends
that the JAR i am creating will depend on other JARs. I have no
problems with this either, since i know how to set the class-path on
the manifest file.

However, I am trying to keep all .class .xml .dtd .jar that my program
is depending on ... into one big JAR only. This way, I can hide the JAR
file and xml file that i am depending on.

Anyone knows how to do this??

TIA

There are utilities that will unwrap all of your dependent jars, and
include all the files in one large JAR that you can then execute.

e.g. google for ProGuard

Alternatively, you might want to take a look at UberJar, or OneJar,
which use clever classloader tricks to access resources inside nested
jars (only one level of nesting allowed, AFAICT).

Rogan