How to find physical path of current java class using java code....

[Pras Tiwari]

Hello all,

I am creating a java class & packaging it into jar. Now I want to add some code into my java class so that it will print its current physical path in file system (either jars path in which it is packaged or java files path if its not packaged in jar) on console.

Any idea?

Many thanks in advance.

Pras

[Nicholas Jordan]

Very simple.

package demo;
 
/*
 * ( from David Singer )
 * 44,100 can be Factored as 2^2 * 3^2 * 5^2 * 7^2, i.e.,
 * the product of the squares of the first four prime numbers.
 * //
 *
 */
 
 public class CurrentPhysicalPath extends java.io.File
 {
     private static String pathname = ".";//
     CurrentPhysicalPath()
     {
         super(pathname);//
     }
     String getResult()
     {
         return pathname;//
     }
     public static void main(String[] args)
     {
         CurrentPhysicalPath cpp = new CurrentPhysicalPath();//
         System.out.println(cpp.getResult());
         ;//
     }
 }

Sorry bout the irrelevant comment, I am in the middle of a project - I use these answer question programs as handy utiilty code.

[Jim Yingst]

Hm, that seems like a convoluted (and dysfunctional) way to get the current working directory. As simpler way that actually works would be

System.out.println(new File("").getAbsolutePath());

or

System.out.println(System.getProperty("user.dir"));

However, that's not what Prashant asked. He's apparently looking for the location of the class file. He's a way that can be found (assuming the current class is called Test.class):

System.out.println(Test.class.getResource("Test.class"));

[ February 07, 2008: Message edited by: Jim Yingst ]

[Rob Spoor]

That won't work if the JAR file is run from another location. E.g.:

C:\>java -jar SomeFolder\SomeJar.jar

It would print C:\\, ot C:\\SomeFolder.

There is a trick that works with MOST class loaders; not all though. It is based on the idea that a .class file itself can mostly also be treated as a resource:

public static URL getClassLocation(Class<?> c)
{
    URL url = c.getResource(getShortName(c) + ".class");
    if (url == null)
    {
        return null;
    }
    String s = url.toExternalForm();
    // s most likely ends with a /, then the full class name with . replaced
    // with /, and .class. Cut that part off if present. If not also check
    // for backslashes instead. If that's also not present just return null
 
    String end = "/" + c.getName().replaceAll("\\.", "/") + ".class";
    if (s.endsWith(end))
    {
        s = s.substring(0, s.length() - end.length());
    }
    else
    {
        end = end.replaceAll("/", "\\");
        if (s.endsWith(end))
        {
            s = s.substring(0, s.length() - end.length());
        }
        else
        {
            return null;
        }
    }
    // s is now the URL of the location, but possibly with jar: in front and
    // a trailing !
    if (StringUtils.startsWith(s, "jar:", true) && s.endsWith("!"))
    {
        s = s.substring(4, s.length() - 1);
    }
    try
    {
        return new URL(s);
    }
    catch (MalformedURLException e)
    {
        return null;
    }
}

Some notes:
1) getShortName returns the class name without the package.
2) you can try to convert the URL to a File using "new File(url.toURI())"

This works (as tested) with both URLClassLoader and the system class loader.

[Jim Yingst]

[Rob]: That won't work if the JAR file is run from another location.

Hm, I think my error was more general than that - I included an extra getClassLoader() call that made it only work for classes in the default package. The Class remembers the relevant package, and looks in appropriate subdirectorries, but the ClassLoader does not. I edited my above post to omit that extra call now. The above code works fine on my system even for a jar file in another directory - e.g.

$ java -jar bar/test.jar
D:\cygwin\home\jim
jar:file:/D:/cygwin/home/jim/bar/test.jar!/foo/Test.class

As for parsing the result, well that's up to the user what form they want it in; I didn't really care much about the details of that.
[ February 07, 2008: Message edited by: Jim Yingst ]

[Rob Spoor]

Originally posted by Jim Yingst:
[Rob]: That won't work if the JAR file is run from another location.

I was referring to Nicholas' solution; your solution was a simplified version of mine, which definitely works.

As long as you don't use some custom class loader that returns something completely different when calling getResource() that is. Fortunately, the default class loaders available in Java do not.

[Jim Yingst]

[Rob']: I was referring to Nicholas' solution; your solution was a simplified version of mine, which definitely works.

No, your solution is a complexified version of mine.
[ February 08, 2008: Message edited by: Jim Yingst ]

[Nicholas Jordan]

Originally posted by Jim Yingst:
[Rob']: I was referring to Nicholas' solution; your solution was a simplified version of mine, which definitely works.

Well was I dysfunctional)? -

[Rob Spoor]

Your solution only works if you are in the path where the JAR file or package folder is located, since it prints out the current working directory. And as Jim has shown, you don't need a separate class for it; just using new File(".") works just as well.

[Jim Yingst]

Nick's code doesn't work at all. It just prints ".". With minor tweaking, it could print the current user directory, but that's not what the original poster asked for, is it?

[Nicholas Jordan]

Originally posted by Jim Yingst:
Nick's code doesn't work at all.

(...snip...)

I have used it several times - it works so reliably that I do not need to defend my dysfuctional() ... it works, see java.io.File() line 183: public File(String pathname). It may be different on your shell which is designed to resemble the unice, but on winnie '.' resolves to current directory. You can do super("."); on an extends java.io.File and if(isDirectory()) evaluates to true. datfunctonal() ( your shell ) may not work but dysfunctional() does work.
[ February 10, 2008: Message edited by: Nicholas Jordan ]

[Jim Yingst]

Nick, try running the program you posted. I don't care if you've run a similar program - it's obvious that you haven't run the one that you actually posted. This has nothing to do with shells or operating systems. Your program is equally useless on any system.

[Henry Wong]

You can actually argue that the fact that it extends java.io.File is an obfuscation (and not a very good one). All the code does is call a method which prints a string that is set to a period. In effect, all it does is print a period.

Henry

[Nicholas Jordan]

Okay, I see your point - rewrote it but cannot get a test run: keep getting no class definiton for main.

/*
 *
 */
 
 public class CurrentPhysicalPath extends java.io.File
 {
     CurrentPhysicalPath()
     {
         super(".");//
     }
     String getResult()
     {
         return toString();//
     }
     public static void main(String[] args)
     {
         CurrentPhysicalPath cpp = new CurrentPhysicalPath();//
         System.out.println(cpp.getResult());
     }
 }

[Jim Yingst]

Which, again, prints "."

[Nicholas Jordan]

Then replace return toString();// with return super.getAbsolutePath()