Finding resources on classpath specific entry

[Karsten Wutzke]

Hello,

my classpath consists of several entries: the first entry is either
the JAR that the application was started from or (when run from the
local dev tree) the classes build dir plus some others for images,
language packs etc. Both (Ant) run configs share ~5 libraries for the
application code, plus ~40 optional look and feel JARs.

I want to find specific resources now. Some look and feels come with
so-called themes, but there's no standard way how these are delivered:

1. Some JARs include them as some custom file format inside the JAR
2. Some offer special classes
3. Some don't include theme files at all, they have to be loaded from
the local user's disk somewhere.

#3 is easy by listing files in some search dir. #2 is even easier,
because Class.forName can handle it.
My problem is with #1. Usually each look and feel comes with files
("*.theme") placed in a specific sub dir, like "themes".

How do I find these files when the JAR was loaded via the classpath?
Since every look and feel comes at least with its own *LookAndFeel
class, Class.forName tells me the class was found and loaded, but when
trying to use that class' .getResource("/") for getting an URL to that
JAR to open a URL connection, the first classpath's entry URL is
returned, so finding the theme files becomes impossible.

How do I find the JAR file of a class that was loaded? Do I have to
split the classpath string into its parts, and iterate over each JAR
entry or just try some specific JARs?

Are there any straightforward ways to do what I need?

TIA
Karsten

 

[Lothar Kimmeringer]

How do I find the JAR file of a class that was loaded? [...]
Are there any straightforward ways to do what I need?

String classname = "/" + TheClass.class.getName().replace('.', '/') + ".class";
java.net.URL url = getClass().getResource(classname);

When looking for java.lang.Object, "here" the following URL
is returned:
jar:file:/C:/Programme/Java/jdk1.6.0_13/jre/lib/rt.jar!/java/lang/Object.class


Regards, Lothar
--
Lothar Kimmeringer E-Mail: (e-mail address removed)
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!

 

[Lew]

my classpath consists of several entries: the first entry is either
the JAR that the application was started from or (when run from the
local dev tree) the classes build dir plus some others for images,
language packs etc.

One purpose that JARs serve is as self-contained deployment artifacts, to be
run using "java -jar yourapp.jar". With the "-jar" option, the "java" command
ignores all classpath information not from the JAR file's manifest.

The notion is that the manifest contains all necessary information to run the
JARred application, as it should when used this way. That means that it would
look in a reliable location, i.e., the JAR itself or a subdirectory of the
JAR's deployment directory, for all libraries and resources, and not count on
the client environment for anything save the Java environment itself.

To ensure that themes are where you can find them, deliver them with the
application to a subdirectory of the JAR's location, and instruct the user to
store additional plugins there.

 

[Karsten Wutzke]

One purpose that JARs serve is as self-contained deployment artifacts, to be
run using "java -jar yourapp.jar".  With the "-jar" option, the "java" command
ignores all classpath information not from the JAR file's manifest.

The notion is that the manifest contains all necessary information to run the
JARred application, as it should when used this way.  That means that it would
look in a reliable location, i.e., the JAR itself or a subdirectory of the
JAR's deployment directory, for all libraries and resources, and not count on
the client environment for anything save the Java environment itself.

To ensure that themes are where you can find them, deliver them with the
application to a subdirectory of the JAR's location, and instruct the user to
store additional plugins there.

While you're right, the things is, I'm looking for a solution to work
with applets. I can't package a JAR that includes look and feels as
this would result in a JAr that's ~10 times the size of the actual
JAR. So I must somehow find ways to search other places.

I haven't found a satisfying approach so far. All I want is to make
use of look and feel JARs that are available on the downloader's
system. Where to look, I haven't made a final decision yet. I'm still
trying to find out. Input welcome.

I started out with running it from the classed from the dev tree,
adding the look and feel JARs to the classpath. I can also produce a
fat JAR which includes everything, this would be the approach to use
with applications. I can start my applet as one locally, but I can't
distribute that JAR, since it would require the user to download 15 or
20MB just for the applet.

What would be the right approach for applets?

Karsten

 

[markspace]

While you're right, the things is, I'm looking for a solution to work
with applets. I can't package a JAR that includes look and feels as
this would result in a JAr that's ~10 times the size of the actual
JAR. So I must somehow find ways to search other places.

I haven't found a satisfying approach so far. All I want is to make
use of look and feel JARs that are available on the downloader's
system. Where to look, I haven't made a final decision yet. I'm still
trying to find out. Input welcome.

I started out with running it from the classed from the dev tree,
adding the look and feel JARs to the classpath. I can also produce a
fat JAR which includes everything, this would be the approach to use
with applications. I can start my applet as one locally, but I can't
distribute that JAR, since it would require the user to download 15 or
20MB just for the applet.

What would be the right approach for applets?

You *should* be able to download them from your server, automatically,
with getResource(), just like Jar files on the command line. All you
have to do is set a "path" on the <applet> tag (or <object> tag, etc.)
that points to the correct directory on your server, and they'll be
found and loaded.

Of course, the files must actually be able to be accessed externally for
this to work. You may have to install the extra Jar files in a special
subdirectory so that the system can find them from the web. I'm not an
expert on every server configuration and use case, but there is good
information out there how to set this up. If you could be more
specific, you might be able to get some help here. At least, do some
searches on apples and libraries and tag configuration, you'll get some
hints at minimum.

 

[Arne Vajhøj]

While you're right, the things is, I'm looking for a solution to work
with applets. I can't package a JAR that includes look and feels as
this would result in a JAr that's ~10 times the size of the actual
JAR. So I must somehow find ways to search other places.

I haven't found a satisfying approach so far. All I want is to make
use of look and feel JARs that are available on the downloader's
system. Where to look, I haven't made a final decision yet. I'm still
trying to find out. Input welcome.

I started out with running it from the classed from the dev tree,
adding the look and feel JARs to the classpath. I can also produce a
fat JAR which includes everything, this would be the approach to use
with applications. I can start my applet as one locally, but I can't
distribute that JAR, since it would require the user to download 15 or
20MB just for the applet.

Would it be an option to pack different L&F's in different jar files
and load the correct one explicit via URLClassLoader ?

Arne