Referring to the class from a static method

[Chris Berg]

In a non-static method one can do:

Class clazz=getClass();

Is something similar possible in a static method? One possibility is

Class clazz = Class.forName("mypackage.MyClass");

But it implies that I know the class name. Of course i know that, but
if I ever change the class name, or move it to another package, then I
propably forget to update this statement. Any other suggestions?

Chris

 

[Andrew Thompson]

| In a non-static method one can do:
|
| Class clazz=getClass();
|
| Is something similar possible in a static method? One
possibility is
|
| Class clazz = Class.forName("mypackage.MyClass");

this.getClass().getName();

...or the example at the bottom of the API docs
for Class would do it for any arbitrary object.

[ You may also need to 'getPackage().getName()'
for the full package name.. ]

HTH

 

[nos]

In a non-static method one can do:

Class clazz=getClass();

Is something similar possible in a static method? One possibility is

Class clazz = Class.forName("mypackage.MyClass");

But it implies that I know the class name. Of course i know that, but
if I ever change the class name, or move it to another package, then I
propably forget to update this statement. Any other suggestions?

Chris

use a tool to change the name
one that changes all references to it as well

 

[Jon A. Cruz]

Is something similar possible in a static method? One possibility is

Class clazz = Class.forName("mypackage.MyClass");

One slight refinement I know for that is (assuming that this is in the
MyClass class in mypackage)

Class clazz = MyClass.class;

 

[Chris Berg]

| In a non-static method one can do:
|
| Class clazz=getClass();
|
| Is something similar possible in a static method? One
possibility is
|
| Class clazz = Class.forName("mypackage.MyClass");

this.getClass().getName();

..or the example at the bottom of the API docs
for Class would do it for any arbitrary object.

[ You may also need to 'getPackage().getName()'
for the full package name.. ]

HTH

Won't work. 'this.' is not legal in a static context, where there is
no Object to refer to.

Chris

 

[Chris Berg]

One slight refinement I know for that is (assuming that this is in the
MyClass class in mypackage)

Class clazz = MyClass.class;

Heureka! That's it!

Actually, I knew that already, but forgot it.

MyClass.class actually gets compiled into Class.forName("MyClass"),
you can see that if you compile it, then decompile it.

Chris

 

[Chris Berg]

One slight refinement I know for that is (assuming that this is in the
MyClass class in mypackage)

Class clazz = MyClass.class;

Oh! Actually that doesn't quite solve the puzzle, I still have to
write "MyClass".

Oh well.

 

[Andrew Thompson]

| On Tue, 20 Jan 2004 20:17:56 GMT, "Andrew Thompson"
.....
| >| Is something similar possible in a static method? One
| >possibility is
| >|
| >| Class clazz = Class.forName("mypackage.MyClass");
| >
| >this.getClass().getName();
...
| Won't work. 'this.' is not legal in a static context, where
there is
| no Object to refer to.

D'Oh! I missed that 'static' bit.. :-(

 

[Jon A. Cruz]

Oh! Actually that doesn't quite solve the puzzle, I still have to
write "MyClass".

Oh well.

Yes, but at least it turns things into a compile-time check, not just a
runtime one.

Plus it will make refactoring easier.


Why do you need to know the name of the class anyway? Most often when
I've found it hard to do something, it's because it's not a thing that's
the most efficient to do.

 

[Oscar Kind]

Oh! Actually that doesn't quite solve the puzzle, I still have to
write "MyClass".

Unfortunately, this is as good as it gets. It's not possible to
dynamically query the current class because:
- There is no object in a static context
- Static methods reside in their defining class, even though you can call
them using the name of a subclass.

Thus for a class Foo, the current class is always Foo.class .


Oscar

 

[Chris Berg]

Why do you need to know the name of the class anyway? Most often when
I've found it hard to do something, it's because it's not a thing that's
the most efficient to do.

I need to know the directory where the Java program's .jar file is.
I've puzzled a lot with it, and the best solution that I've come up
with was:

[inside a static method in class wbserver.WBServer]

String dir = ClassLoader.getSystemClassLoader().getResource(
"wbserver/WBServer.class").getFile();
/*
if it's a .jar file, dir looks like this:
"file:/D:/mydir/MyJar.jar!/wbserver/WBServer.class"
if it's separate class files, dir looks like:
"/D:/mydir/wbserver/WBServer.class"
*/
if(dir.startsWith("file:")){
dir = dir.substring(5);
}
if(dir.startsWith("/")){
dir = dir.substring(1);
}
int u = dir.indexOf('!');
if(u>=0){
dir = dir.substring(0, u);
}
dir = dir.replace('/', File.separatorChar);
dir = new File(dir).getParent();
defDir = dir;

This gives med the acual directory that my .jar / .class file is in.
(I doubt it will work under Linux, by the way. Comments?)
So, if anyone has alternatives to this, I'll be just as happy.

Chris

 

[Oscar Kind]

I need to know the directory where the Java program's .jar file is.
I've puzzled a lot with it, and the best solution that I've come up
with was:

[...]

Which is not trivial, as classloaders can instantiate a class from
different sources:
- From a class file in a directory
- From a class file in a .jar file (most common with installed programs)
- From a class file in another archive (.war, .zip, ...)
- From a URI (i.e. read-only)
- By any other method using a custom classloader.

More often than not, your requirement is needed to store settings.
It's easier to use the preferences system of Java for that.

Personally, whenever I needed to know the location of a class file, my
design was wrong. So check it again: do you really need what you ask?


Oscar

 

[Chris Berg]

Personally, whenever I needed to know the location of a class file, my
design was wrong. So check it again: do you really need what you ask?

The grand purpose is to read a file that is placed in the same
directory as the .jar file. Of course I could tell the program where
it is with a parameter, but that seems to be a bit redundant; the
program shall be installed by customers, so it must be as easy as
possible.

The solution that I described actually works alright, and, come to
think of it, it also ran ok on Linux once.

Anyway, I think I should follow the golden rule here: "If it's not
broken, don't fix it!"

Chris

 

[Andrew Thompson]

| On 21 Jan 2004 09:36:59 GMT, Oscar Kind <[email protected]>
wrote:
....
| >Personally, whenever I needed to know the location of a class
file, my
| >design was wrong. So check it again: do you really need what
you ask?
....
| The grand purpose is to read a file that is placed in the same
| directory as the .jar file.

So why all the arbitrary restrictions?

Instantiate an object of _any_ class
in the jar and use Class.getResource(),
it works for classes, gifs, property files..

|...Of course I could tell the program where
| it is with a parameter, but that seems to be a bit redundant;
the
| program shall be installed by customers, so it must be as easy
as
| possible.

The customer can't have it easier than that..

| The solution that I described actually works alright, and, come
to
| think of it, it also ran ok on Linux once.

Apple, Unix, Solaris...?

| Anyway, I think I should follow the golden rule here: "If it's
not
| broken, don't fix it!"

If you use non-standard ways of doing
things, your code may well break in
future releases.

 

[Dale King]

The grand purpose is to read a file that is placed in the same
directory as the .jar file. Of course I could tell the program where
it is with a parameter, but that seems to be a bit redundant; the
program shall be installed by customers, so it must be as easy as
possible.

Is there some reason why this file is in the same directory as the jar
instead of being in the jar (e.g. you need to read and write it)? Reading a
file inside the jar is much easier.

 

[Chris Berg]

Is there some reason why this file is in the same directory as the jar
instead of being in the jar (e.g. you need to read and write it)? Reading a
file inside the jar is much easier.

Yes, because the .jar file contains the code that I distribute. The
user sets up the application by providing a file with the necessary
info for the program to run (it has about 20 parameters, so in stead
of supplying these on the command line, the app gets them from the
setup file.) If this file should be inside the .jar file, the user
should open it an put the new file into it, which I think is a really
bad idea.

Chris

 

[Chris Berg]

Instantiate an object of _any_ class
in the jar and use Class.getResource(),
it works for classes, gifs, property files..

Does getResource() also find files outside the .jar file?

Chris

 

[Andrew Thompson]

| On Wed, 21 Jan 2004 16:11:42 GMT, "Andrew Thompson"
|
| >Instantiate an object of _any_ class
| >in the jar and use Class.getResource(),
| >it works for classes, gifs, property files..
| >
|
| Does getResource() also find files outside the .jar file?

In the same directory it certainly will,
you'll have to give it a try for sub-directories,
I'm a bit fuzzy on the details.

I could give it a try, ..but then, so could you!

 

[Dale King]

Yes, because the .jar file contains the code that I distribute. The
user sets up the application by providing a file with the necessary
info for the program to run (it has about 20 parameters, so in stead
of supplying these on the command line, the app gets them from the
setup file.) If this file should be inside the .jar file, the user
should open it an put the new file into it, which I think is a really
bad idea.

That's why I asked the question. It doesn't make sense to have this as part
of the jar as it is user configuration. But assuming it should be placed in
the same directory that the jar is seems to be a pretty bad design.

Typically when you install a program on Linux it goes in a shared directory
that only the root has access to. Any user configuration files go in the
user's home directory not in the installation directory. The same is
somewhat true of Windoze. Programs are installed in Program Files. User data
should not be stored there. I like it that way on Windows so I don't have to
back up my Program Files directory since I can just re-install the programs.

There are various ways that it should be done, including passing it on the
command line, but I don't know enough about your app to tell you the best
way. I can tell you some users will probably not be happy with putting it in
the same directory as the jar. I certainly wouldn't be.

 

[Chris Berg]

There are various ways that it should be done, including passing it on the
command line, but I don't know enough about your app to tell you the best
way.

You are right about that - you don't.

(We are changing the subject radically now, but what the heck - it's
still interesting).

There can be many reasons for choosing a particular
design/layout/install procedure. In this particular case, it _does_
make sense to do it my way, for various reasons:

1) It is a server application, not your everyday GUI application. It
runs without any user intervention, with no user logged-in.

2) The exact same app shall be installable on any platform that has a
Java VM (even on a Mac, for that matter). Thus, I cannot assume
anything about the presense of user/system repositories such as the
Windows Registry or Linux shared directory. I know Sun has made the
java.util.prefs package for this purpose, but that is, at the present
stage, only a framework which has to be implemented for the particular
platform. I'll wait and see what becomes of it.

3) Having the setup assembled in a single text file gives me the
advantage that I don't have to write an editor program for the
settings, the installer simply edits the settings file using a text
editor. Of course, she must study the installation manual to do that,
but what do I care?

4 This approach makes it extremely simple to move the app to another
disk/cpu/system/platform.


Chris