Home > Archive > Java Help > April 2004 > App does not work in a Jar, NoClassDefFoundError
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
App does not work in a Jar, NoClassDefFoundError
|
|
| VisionSet 2004-04-14, 10:43 am |
| I really shouldn't be having these problems, but I so rarely Jar anything
up...
App works fine accessing other 3rd party jars.
When I jar my app up, it throws NoClassDefFoundError for the 1st class it
trys to access in the 3rd party jar. It finds my main-class fine.
structure from root of my jar is:
com/blah/myClassFiles.class
kunststoff.jar
manifest is:
Manifest-Version: 1.0
Main-Class: com.blah.MainClass
Class-Path: kunststoff.jar .
Exception in thread "main" java.lang.NoClassDefFoundError:
com/incors/plaf/kunststoff/KunststoffLookAndFeel
When not jarred up the 3rd party jars are only present as jars, so it is not
getting the classes elsewhere.
I hear that I must use lib/ext for 3rd party jars, but I'm unsure why.
I want to distribute my jar, jar.exe does not copy them to my .jar and it
didn't help anyway.
TIA
--
Mike W
| |
| Roedy Green 2004-04-15, 7:34 pm |
| On Wed, 14 Apr 2004 14:41:29 +0100, "VisionSet" <spam@ntlworld.com>
wrote or quoted :
>com/blah/myClassFiles.class
>kunststoff.jar
Java does not understand jars inside jars. See
http://mindprod.com/jgloss/manifest.html
and follow links.
Your kunstoff.jar must be installed separately and referenced in the
manifest with relative path to it.
--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
| |
| VisionSet 2004-04-15, 7:34 pm |
|
"Roedy Green" <look-at-the-website@mindprod.com> wrote in message
news:nm4u70tcotndaf09pma1hhn5phmpv9lpof@
4ax.com...
> On Wed, 14 Apr 2004 14:41:29 +0100, "VisionSet" <spam@ntlworld.com>
> wrote or quoted :
>
>
> Java does not understand jars inside jars. See
> http://mindprod.com/jgloss/manifest.html
> and follow links.
>
> Your kunstoff.jar must be installed separately and referenced in the
> manifest with relative path to it.
>
Well it's about time they did!!
I've unpacked everything in to one jar
I use your site alot, very useful!
I suggest you include:
> Java does not understand jars inside jars.
explicitly on your JAR page.
--
Mike W
| |
| Roedy Green 2004-04-22, 2:38 am |
| On Fri, 16 Apr 2004 01:06:26 +0100, "VisionSet" <spam@ntlworld.com>
wrote or quoted :
>Well it's about time they did!!
>I've unpacked everything in to one jar
you can combine jars into one, but you have to add the contents of the
sub jar element by element to the master jar. You can't just add the
whole jar as a single element to the master jar.
--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
| |
| VisionSet 2004-04-22, 5:41 pm |
|
"Roedy Green" <see@mindprod.com.invalid> wrote in message
news:1fle809ic9qqk9d67fsttmq8kop5nfr4f3@
4ax.com...
> On Fri, 16 Apr 2004 01:06:26 +0100, "VisionSet" <spam@ntlworld.com>
> wrote or quoted :
>
>
>
> you can combine jars into one, but you have to add the contents of the
> sub jar element by element to the master jar. You can't just add the
> whole jar as a single element to the master jar.
Yes, that what I meant by unpacked everything in to one jar.
You gotta agree, it is daft that you can't have a jar in a jar though ?
--
Mike W
| |
| Roedy Green 2004-04-22, 10:33 pm |
| On Thu, 22 Apr 2004 21:54:54 +0100, "VisionSet" <spam@ntlworld.com>
wrote or quoted :
> it is daft that you can't have a jar in a jar though ?
Not really. It would be slow to read. You would have to run the
unpacking algorithm over and over for each nesting layer. It is more
efficient to have a single layer.
Even to find out what was in it, you would have to decompress the
inner jars. with the outer level, that info in not compressed and
lives at the end of the jar in convenient dense form.
--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
| |
| Andrew Thompson 2004-04-22, 11:33 pm |
| On Fri, 23 Apr 2004 01:52:28 GMT, Roedy Green wrote:
(Zips/Jars)
> Even to find out what was in it, you would have to decompress the
> inner jars. with the outer level, that info in not compressed and
> lives at the end of the jar in convenient dense form.
Really? I had been wonderring how efficient
it was to pull the ZipEntries straight out of
(for instance) the 1.5 rt.jar (a chunky 31Meg
of jar file, that!) to examine the entries*.
[ * Something I have been playing with recently,
...as soon as I can figure out why one might make
a web page of that, I'll put it up at my site. ;-) ]
I was wonderring if I should extract the
Enumeration of ZipEntries and serialize
them separately. I'll have to do some
more tests, but it sounds like it will
not be worth it.
--
Andrew Thompson
http://www.PhySci.org/ Open-source software suite
http://www.PhySci.org/codes/ Web & IT Help
http://www.1point1C.org/ Science & Technology
| |
| Roedy Green 2004-04-23, 12:32 am |
| On Fri, 23 Apr 2004 02:10:37 GMT, Andrew Thompson
<SeeMySites@www.invalid> wrote or quoted :
>
>Really?
Study the format of a zip/jar files. See
http://mindprod.com/jgloss/zip.html
You can get at the indexing information very quickly, e.g. name of
member, size, date. To get the contents, you have to run a
decompression algorithm.
The indexing information is actually stored redundantly in the file,
once with each member, and once in a summary at the END, yes, the end.
It is a little bit tricky to find the beginning of the summary, but
once you do, you can zoom along very fast finding out what you have,
e.g. looking for a particular class to load. One of my long standing
peeves is the lack of a pointer at the head of the zip to the summary
offset. The excuse is zip files can be created on the fly in a stream
with no backtracking.
There are java classes to manipulate the jar/zIp format for you. But
if you study what the format is like, or if you wrote asm on zips in
the old DOS days, you have a better idea of what takes the time.
--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
| |
| Roedy Green 2004-04-23, 12:32 am |
| On Fri, 23 Apr 2004 03:04:29 GMT, Roedy Green
<see@mindprod.com.invalid> wrote or quoted :
>It is a little bit tricky to find the beginning of the summary, but
>once you do, you can zoom along very fast finding out what you have,
>e.g. looking for a particular class to load. One of my long standing
>peeves is the lack of a pointer at the head of the zip to the summary
>offset. The excuse is zip files can be created on the fly in a stream
>with no backtracking.
for fast classpath loading, a classloader can build an in-ram HashMap
of the contents of each jar. That way it can instantly find out if any
class lives in a particular jar. Once it knows it is in there, it
could linearly scan the summary for the corresponding entry, or more
likely cache that info too to get the offset of the data member.
--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
| |
| Andrew Thompson 2004-04-23, 1:32 am |
| On Fri, 23 Apr 2004 03:04:29 GMT, Roedy Green wrote:
> On Fri, 23 Apr 2004 02:10:37 GMT, Andrew Thompson
> <SeeMySites@www.invalid> wrote or quoted :
>
> Study the format of a zip/jar files. See
> http://mindprod.com/jgloss/zip.html
>
> You can get at the indexing information very quickly, e.g. name of
> member, size, date. To get the contents, you have to run a
> decompression algorithm.
>
> The indexing information is actually stored redundantly in the file,
> once with each member, and once in a summary at the END, yes, the end.
Uhuh..
> It is a little bit tricky to find the beginning of the summary, but
> once you do, you can zoom along very fast finding out what you have,
> e.g. looking for a particular class to load. One of my long standing
> peeves is the lack of a pointer at the head of the zip to the summary
> offset. The excuse is zip files can be created on the fly in a stream
> with no backtracking.
It is a pity, but seems logical.
...Maybe me saving the ZipEntries
separately is not such a bad
idea after all.
If I make use of it, it will be the
rt.jar's (now 1.1 thru 1.5) on my
_site_ that I am doing it, so I had
better check some of these possible
optimizations.
> There are java classes to manipulate the jar/zIp format for you. But
> if you study what the format is like, or if you wrote asm on zips in
> the old DOS days, you have a better idea of what takes the time.
Ahh, no. Only ever had a convenient
'interface' to the files via WinZip/Java
so never got into the arcane internals.
[ As far as I was concerned..
'Magic, make big, small - me use' ]
Thank you for the informative (and important)
extra details on them. I will give that link
of yours close study.
--
Andrew Thompson
http://www.PhySci.org/ Open-source software suite
http://www.PhySci.org/codes/ Web & IT Help
http://www.1point1C.org/ Science & Technology
| |
| Andrew Thompson 2004-04-23, 1:32 am |
| On Fri, 23 Apr 2004 03:21:50 GMT, Roedy Green wrote:
....[color=darkred]
> for fast classpath loading, a classloader can build an in-ram HashMap
> of the contents of each jar.
I was using the fully qualified class names
as the key, seemed the logical thing..
>...That way it can instantly find out if any
> class lives in a particular jar.
(grins) Yep. But that is where I was
running into problems with what I intended.
What I wanted was to represent the entire
class/methods/attributes of the core Sun
rt.jars in HTML as a kind of 'JavaDoc Style'
comment/information, with links back to the
API docs at Sun, and links forwards/backwards
in the versioning ( a 1.3 method would have
links back to 1.2/forward to 1.4 )
I was experimenting w/ an URLClassLoader
that attempted to get the bytes of the
classes as a Class. The JVM did not like
me attempting to create a 'java.lang.Object'
from another jar.. but then I suspected
at the time I recognize the reason.. ;-)
I'll have to get back to it sometime soon..
--
Andrew Thompson
http://www.PhySci.org/ Open-source software suite
http://www.PhySci.org/codes/ Web & IT Help
http://www.1point1C.org/ Science & Technology
| |
| Andrew Thompson 2004-04-23, 6:32 am |
| On Fri, 23 Apr 2004 04:25:21 GMT, Andrew Thompson wrote:
> What I wanted was to represent the entire
> class/methods/attributes of the core Sun
> rt.jars in HTML as a kind of 'JavaDoc Style'
> comment/information,
Dropped all the stuff with class loaders
when (slaps forehead) I realized I could
do something much more like ..this
<http://www.physci.org/codes/display.../jar/src1_4.zip!/java/lang/Object.java>
Straight to the 'Source'. :-)
But I'll tidy it up and shorten the URL first..
--
Andrew Thompson
http://www.PhySci.org/ Open-source software suite
http://www.PhySci.org/codes/ Web & IT Help
http://www.1point1C.org/ Science & Technology
|
|
|
|
|