System.getProperty("user.dir") cannot rerturn the package directory.

[Cheok Yan Cheng]

i have a class belong to package suyuan

the class file is located at
D:\Profiles\cyc025\Desktop\suyuan\test.class

i try to execute System.getProperty("user.dir") inside test.class.

i get D:\Profiles\cyc025\Desktop

but i wish there is a java api which can return

D:\Profiles\cyc025\Desktop\suyuan

how can i do so?

thank you.

regards
yan cheng

 

[Paul Lutus]

i have a class belong to package suyuan

the class file is located at
D:\Profiles\cyc025\Desktop\suyuan\test.class

i try to execute System.getProperty("user.dir") inside test.class.

i get D:\Profiles\cyc025\Desktop

This is because that is the root directory for the package to which your
class belongs. If you want a different directory, move your package.

but i wish there is a java api which can return

D:\Profiles\cyc025\Desktop\suyuan

Explain why you think you need to do this.

how can i do so?

First things first. What are you trying to do? If you think this has already
been explained, then you need to post replies to the thread you have
already started.

 

[Tony Morris]

You can't. And you don't want to either.

Can too!
But it is more than likely (yet) another broken requirement.
Define your complete requirement, not a (almost certainly) broken solution.

String package = test.class.getPackage().getName();

 

[Jacob]

i have a class belong to package suyuan

the class file is located at
D:\Profiles\cyc025\Desktop\suyuan\test.class

i try to execute System.getProperty("user.dir") inside test.class.

i get D:\Profiles\cyc025\Desktop

but i wish there is a java api which can return

D:\Profiles\cyc025\Desktop\suyuan

You can't. And you don't want to either.

If you can describe *why* you want to this, we'll suggest
an alternative approach.

 

[Tor Iver Wilhelmsen]

but i wish there is a java api which can return

D:\Profiles\cyc025\Desktop\suyuan

how can i do so?

Use test.class.getResource("test.class"); This returns an URL (in this
case a file: URL) you can extract the path from.

 

[John C. Bollinger]

Cheok Yan Cheng wrote:




This is because that is the root directory for the package to which your
class belongs. If you want a different directory, move your package.

No. This is because that is the OS' idea of the "working directory" (or
equivalent) applicable to the JVM process at startup. The concept of a
root directory for a package is nonsensical -- even when at least one
class of the package is stored on disk (as is typical, but not
necessary), different classes in the package may reside in disjoint
directory trees, or they may be split among any number of Jars, etc..

Determining the location of class files on the system has of late been a
topic of some discussion here. Although it is an oversimplification, I
think it fair to say that Java very much deemphasizes physical class
locations, and that it is altogether reasonable in that respect.


John Bollinger
(e-mail address removed)

 

[Paul Lutus]

No. This is because that is the OS' idea of the "working directory" (or
equivalent) applicable to the JVM process at startup. The concept of a
root directory for a package is nonsensical --

On the contrary. Packages typically live in a directory hierarchy. In this
case, it is literally true, and it is the source of the OP's "problem".

Whether this is nonsensical in a design sense is another matter entirely. It
is certainly the source of the immediate complaint.

 

[John C. Bollinger]

John C. Bollinger wrote:




On the contrary. Packages typically live in a directory hierarchy. In this
case, it is literally true, and it is the source of the OP's "problem".

You have snipped out the reasons I gave for my assertion without
responding to them, and then contradicted me without offering any
argument of your own. I admit that's a strategy that tends to quell
debate, but I can't say I find it very persuasive. In the new spirit of
this discussion, then, I will simply reassert that no, packages do not
live on a filesystem. Class files may, and typically do, reside on a
filesystem. More often than than not they even reside on a local
filesystem with respect to JVMs that load classes from them. But a
package is simply a collection of classes (NOT class _files_), with no
physical representation of its own at all. It certainly does not have a
"root directory".

Whether this is nonsensical in a design sense is another matter entirely. It
is certainly the source of the immediate complaint.

Getting back to the OP's question, then, which pertained to the
"user.dir" system property: my main point was that you have
misidentified the nature of that property. That your explanation had
any semblance of correctness at all was an artifact of the environment
in which the OP started his program. If the OP attempted to develop a
solution based on your claims he would at best find that it didn't work,
and at worst find that it _appeared_ to work, only to realize later that
whether or not it works depends on how the program is run.


John Bollinger
(e-mail address removed)

 

[Sudsy]

Paul Lutus wrote:

You have snipped out the reasons I gave for my assertion without
responding to them, and then contradicted me without offering any
argument of your own. I admit that's a strategy that tends to quell
debate, but I can't say I find it very persuasive. In the new spirit of
this discussion, then, I will simply reassert that no, packages do not
live on a filesystem. Class files may, and typically do, reside on a
filesystem. More often than than not they even reside on a local
filesystem with respect to JVMs that load classes from them. But a
package is simply a collection of classes (NOT class _files_), with no
physical representation of its own at all. It certainly does not have a
"root directory".

John Bollinger

I'm not about to cross swords with J. Bo.: I've worked with him before
and he DEFINITELY knows what he's talking about. Accept what he has
to say, not as gospel, but as close as you can get. That is unless you
honestly believe that you know more than he does...
If that's the case then I salute you!
I remain to be convinced, however.

 

[Paul Lutus]

You have snipped out the reasons I gave for my assertion without
responding to them, and then contradicted me without offering any
argument of your own.

See above the the argument you think I did not provide: "packages typically
live in a directory hierarchy."

I admit that's a strategy that tends to quell
debate, but I can't say I find it very persuasive.

It would be better if your conclusion did not follow from your flawed
premise.

In the new spirit of
this discussion, then, I will simply reassert that no, packages do not
live on a filesystem.

This is an assertion no one but you has presented. Produce the evidence --
find the quote your assertion contradicts: "packages do not live on a
filesystem".

Class files may, and typically do, reside on a
filesystem.

And class files are typically member components of packages, and those
package names are typically reflected in the directory names that contain
the class files.

More often than than not they even reside on a local
filesystem with respect to JVMs that load classes from them. But a
package is simply a collection of classes (NOT class _files_), with no
physical representation of its own at all. It certainly does not have a
"root directory".

Congratulations on that clarification. Now take note that the OP has a
problem related to the fact that his packages are represented by the
directories in which the class files are located, and he finds it difficult
to force recognition of a specific directory in those package directories.

Getting back to the OP's question, then, which pertained to the
"user.dir" system property: my main point was that you have
misidentified the nature of that property. That your explanation had
any semblance of correctness at all was an artifact of the environment
in which the OP started his program.

And compiled his program, and prepared his program for delivery, etc. etc..
IOW it was and is correct and germane.

If the OP attempted to develop a
solution based on your claims he would at best find that it didn't work,
and at worst find that it _appeared_ to work, only to realize later that
whether or not it works depends on how the program is run.

That is certainly true, but is is far afield of the OP's immediate request.

 

[Tor Iver Wilhelmsen]

On the contrary. Packages typically live in a directory hierarchy. In this
case, it is literally true, and it is the source of the OP's "problem".

Formally, that is just the suggested implementation for a ClassLoader.
But a ClassLoader can just as well read classes from a database table.

The OP's problem is that the concept of "working directory" is not
related to the concept of "classpath", and classes are relative to the
latter, not the former.

 

[Paul Lutus]

Formally, that is just the suggested implementation for a ClassLoader.
But a ClassLoader can just as well read classes from a database table.

Yes, quite true, but not true in this typical case.

The OP's problem is that the concept of "working directory" is not
related to the concept of "classpath", and classes are relative to the
latter, not the former.

All true, and my post addressed the reality of the poster's situation, not
the very useful, albeit abstract truth you have pointed out.

 

[John C. Bollinger]

The bulk of this argument is going nowhere. Here, again, is the
original problem and the original claims:


If the OP opened a command shell, made C:\ the working directory, and
executed his program via:

java -classpath D:\Profiles\cyc025\Desktop suyuan.test

then he would get C:\


If he changed to D:\Profiles and executed his program via

java -classpath cyc025\Desktop suyuan.test

then he would get D:\Profiles


How are those things changing the "root directory of the package"?


If he jarred the the class files into c:\suyuan.jar, erased them from
their original directory, changed to directory
D:\Profiles\cyc025\Desktop, and executed his program via

java -classpath c:\suyuan.jar suyuan.test

then he would get D:\Profiles\cyc025\Desktop

(the same thing he originally reported). How is that NOT changing the
"root directory of the package"?


John Bollinger
(e-mail address removed)