Referring to the class from a static method

[Chris Berg]

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 .

Still, I can't see any reason why there couldn't be a thing such as
'thisclass' in java, that would give you a Class object, and which
could be referred to from a static context.

Well, there isn't, so why bother?

Chris

 

[Dale King]

You are right about that - you don't.

Which is why I replied in the form of a question, orginally. I don't presume
to know your reasoning and now I do.

(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.

Then I'm not sure I see your reluctance to the command line parameter
option. Some script somewhere is going to have to kick off the server in the
boot process and adding a command line parameter (at least as an option)
seems to be a good way to go.

Assuming that your user can put the file where the jars are installed would
be bad practice. I can see that as a fallback. I think you should really
have several options.

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.

It already became. Implementations are provided for different OS's. The
windows one uses the registry. The linux one stored it in files. Not sure
what the Mac one does.

This may or may not be viable for your scenario. In this case instead of
editing a file the user would use a GUI that you provide (either as a
separate application or integrated into your app) to edit the configuration
which is then persisted with the Preferences API.

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?

An acceptable solution for a server app.

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

Actually, it may hamper it. Once again I think it is wrong to assume that
placing code and user data in the same place is good practice. What if the
user wants several servers and all of them get the code from the same share
on the network. There is no reason to unnecessarily force them to have
separate copies of the source just for the purpose of finding the
configuration for that server.

 

[Adam Jenkins]

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.

Actually the java.util.prefs package does come with a concrete
implementation, which stores preferences as XML files. To get a
concrete Preferences object, call one of the static methods systemRoot,
systemNodeForPackage, userRoot, or userNodeForPackage, as in

import java.util.prefs.*;

....
Preferences prefs = Preferences.userRoot();

This still doesn't solve your problem of where you want to store prefs
though.

Adam

 

[Andrew Thompson]

| Chris Berg wrote:

<application preferences/properties>

| > I know Sun has made the
| > java.util.prefs package for this purpose,
....
| import java.util.prefs.*;
|
| ...
| Preferences prefs = Preferences.userRoot();
|
| This still doesn't solve your problem of where you want to store prefs
| though.

Someone suggested using the Properties
class to store a single String for TheApp.jar
(whatever), giving the location of the
Preference file.

[ I still have not tried it myself though. ]

Would that not solve the last part and
wrap it up neatly?