app path

[Chameleon]

I want to know in which path is application.
Until now I use the following super_dumb code:
application.jar : the jar file
subtitle/MainFrame.class : the main() class

try {
// get application path
rootPath =
URLDecoder.decode(ClassLoader.getSystemResource("subtitle/MainFrame.class").getPath().replaceAll("(application\\.jar!/)?subtitle/MainFrame\\.class$|^(file\\?/",
""), "UTF-8");
} catch (UnsupportedEncodingException ex) {
rootPath = "";
}

Is there a better approach?
Thanks!

 

[Daniel Pitts]

I want to know in which path is application.
Until now I use the following super_dumb code:
application.jar : the jar file
subtitle/MainFrame.class : the main() class

try {
// get application path
rootPath =
URLDecoder.decode(ClassLoader.getSystemResource("subtitle/MainFrame.class").getPath().replaceAll("(application\\.jar!/)?subtitle/MainFrame\\.class$|^(file\\?/",
""), "UTF-8");

} catch (UnsupportedEncodingException ex) {
rootPath = "";
}

Is there a better approach?
Thanks!

What's your ultimate goal? I don't see any motivation for knowing
where the current class file is from, perhaps if you gave use your
motivation, we could suggest an even better approach

 

[Chameleon]

What's your ultimate goal? I don't see any motivation for knowing
where the current class file is from, perhaps if you gave use your
motivation, we could suggest an even better approach

My goal:
I have the "application.jar" inside a directory, for instance (windows)
C:\Program Files\My Application

I want a String with value: "C:\Program Files\My Application".
With the code above I have it. But code is a little bit confusing.

 

[Guest]

I want to know in which path is application.
Until now I use the following super_dumb code:
application.jar : the jar file
subtitle/MainFrame.class : the main() class

try {
// get application path
rootPath =
URLDecoder.decode(ClassLoader.getSystemResource("subtitle/MainFrame.class").getPath().replaceAll("(application\\.jar!/)?subtitle/MainFrame\\.class$|^(file\\?/",
""), "UTF-8");
} catch (UnsupportedEncodingException ex) {
rootPath = "";
}

Is there a better approach?

I don't think so.

I use the following rather similar code:

private String getPath(Class cls) {
String cn = cls.getName();
String rn = cn.replace('.', '/') + ".class";
String path =
getClass().getClassLoader().getResource(rn).getPath();
int ix = path.indexOf("!");
if(ix >= 0) {
return path.substring(0, ix);
} else {
return path;
}
}

Arne

 

[Real Gagnon]

I want to know in which path is application.
Until now I use the following super_dumb code:
application.jar : the jar file
subtitle/MainFrame.class : the main() class

try {
// get application path
rootPath =
URLDecoder.decode(ClassLoader.getSystemResource("subtitle/MainFrame.cla
ss").getPath().replaceAll("(application\\.jar!/)?subtitle/MainFrame\\.c
lass$|^(file\\?/", ""), "UTF-8");
} catch (UnsupportedEncodingException ex) {
rootPath = "";
}

Is there a better approach?
Thanks!

Try this :

import java.io.File;
import java.io.IOException;
import java.net.URI;
import java.net.URISyntaxException;
import java.net.URL;

public class FromWhere {
public static void main(String args[]) throws Exception{
FromWhere s = new FromWhere();
s.getHome();
}

public void getHome() throws IOException, URISyntaxException{
URL u =
getClass().getProtectionDomain().getCodeSource().getLocation();
File f = new File(u.toURI());
System.out.println(f.getParent());
}
}

Bye.

 

[Andrew Thompson]

[quoted text clipped - 17 lines]

where the current class file is from, perhaps if you gave use your
motivation, we could suggest an even better approach

My goal:
I have the "application.jar" inside a directory, for instance (windows)
C:\Program Files\My Application

I want a String with value: "C:\Program Files\My Application".

Though it might be a strategy that you think
might achieve some goal - it is *not* a goal in
and of itself.

Try to think of the 'goal' as the 'X' of..
"I want to offer the *end* *user* 'X'".

What is the 'X'?

With the code above I have it. But code is a little bit confusing.

So is your approach. There are very few end goals
that require knowing the codebase that the application
is using, and attempts to find that codebase often
indicate poor (and fragile) design.

--
Andrew Thompson
http://www.athompson.info/andrew/

Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.aspx/java-general/200708/1

 

[Chameleon]

O/H Andrew Thompson έγÏαψε:

I want to know in which path is application.
Until now I use the following super_dumb code:

[quoted text clipped - 17 lines]

where the current class file is from, perhaps if you gave use your
motivation, we could suggest an even better approach

My goal:
I have the "application.jar" inside a directory, for instance (windows)
C:\Program Files\My Application

I want a String with value: "C:\Program Files\My Application".

Though it might be a strategy that you think
might achieve some goal - it is *not* a goal in
and of itself.

Try to think of the 'goal' as the 'X' of..
"I want to offer the *end* *user* 'X'".

What is the 'X'?

you right.
1. I want to open a "config.ini" file which is in JAR's path.
2. I want to open an "index.html" which is in JAR's path.

So is your approach. There are very few end goals
that require knowing the codebase that the application
is using, and attempts to find that codebase often
indicate poor (and fragile) design.

a better solution, but it works ONLY for JAR's and not for unpacked classes:

// get application path
try {
rootPath = new File(System.getProperty("java.class.path")).
getCanonicalFile().getParent() + File.separator;
} catch (IOException ex) {
rootPath = "";
}

 

[Andrew Thompson]

O/H Andrew Thompson έγÏαψε:

you right.
1. I want to open a "config.ini" file which is in JAR's path.
2. I want to open an "index.html" which is in JAR's path.

That *still* does not quite come up to a statememnt
of a 'user feature', but it is close enough.

OK - *why* are these files in the Jar's path?
Who, or what, caused them to be there?

For example, some apps. are supplied as Zip
archives, with the instructions to 'unzip to a new
directory on your system' - that might be one way
these files all happen to be in the same place.

But is does not *have* to be that way.
You might write a simple 'unzipper - installer'
that puts the config.ini and index.html into
a *known* path, that can be easily found later,
while putting everything else in a single (hidden
or otherwise) directory.

Web start also offers mechanims to 'install'
files or do other such things at first application
start.

..and 'fragile'. Every time devlopers seem to come
up with a 'rock solid' way to get the app. path, Sun
(seems to*) changes the rules. * They are really just
trying to design a robust and fast plug-in, but things
happen in that process that affect Java apps.

 

[Daniel Pitts]

O/H Andrew Thompson :

I want to know in which path is application.
Until now I use the following super_dumb code:
[quoted text clipped - 17 lines]
where the current class file is from, perhaps if you gave use your
motivation, we could suggest an even better approach
My goal:
I have the "application.jar" inside a directory, for instance (windows)
C:\Program Files\My Application
I want a String with value: "C:\Program Files\My Application".

Though it might be a strategy that you think
might achieve some goal - it is *not* a goal in
and of itself.

Try to think of the 'goal' as the 'X' of..
"I want to offer the *end* *user* 'X'".

What is the 'X'?

you right.
1. I want to open a "config.ini" file which is in JAR's path.
2. I want to open an "index.html" which is in JAR's path.

So is your approach. There are very few end goals
that require knowing the codebase that the application
is using, and attempts to find that codebase often
indicate poor (and fragile) design.

a better solution, but it works ONLY for JAR's and not for unpacked classes:

// get application path
try {
rootPath = new File(System.getProperty("java.class.path")).
getCanonicalFile().getParent() + File.separator;

} catch (IOException ex) {
rootPath = "";
}

Ah, perhaps you should look into ClassLoader.getResource(), or
Class.getResource(). That is probably what you are really looking
for.

 

[Chameleon]

O/H Andrew Thompson έγÏαψε:

That *still* does not quite come up to a statememnt
of a 'user feature', but it is close enough.

"config.ini" keeps the application's configuration (Settings dialog)
"index.html" is the file which load in browser as HELP with
"BrowserLauncher" class and it is outside the jar because not all
browsers support the "jar:http://......."

OK - *why* are these files in the Jar's path?
Who, or what, caused them to be there?

I want "config.ini" in the directory where I place the JAR file.
I want "index.html" and some other help files, outside the JAR file
because not all web browsers can open these files inside the JAR.

For example, some apps. are supplied as Zip
archives, with the instructions to 'unzip to a new
directory on your system' - that might be one way
these files all happen to be in the same place.

My application installation package is a zip file contains a JAR file
and some help files.
Or a JAR file only (forget about help).

But is does not *have* to be that way.
You might write a simple 'unzipper - installer'
that puts the config.ini and index.html into
a *known* path, that can be easily found later,
while putting everything else in a single (hidden
or otherwise) directory.

Yes. "config.ini" created inside directory which contains the JAR file
and "index.html" and other help files are placed in the same directory
plus "/help/"

Web start also offers mechanims to 'install'
files or do other such things at first application
start.

I believe the problem is very easy.

.and 'fragile'. Every time devlopers seem to come
up with a 'rock solid' way to get the app. path, Sun
(seems to*) changes the rules. * They are really just
trying to design a robust and fast plug-in, but things
happen in that process that affect Java apps.

the code works from version 1.4 to today. I don't know keyword "java"
before the version 1.4! I am newbie ;-)

Sorry for the "<present simple> *before* ..." and other related things.
My english sucks!