I am having issue running a Java program.
There's a line of code in a jar file that opens the FileInputStream to some file from "/apps/somefile" location,
however I do not have access to the root directory.
The issue is that I am unable to change the code since it is provided in a jar file, as such is there anyway to change to root directory that "/" points to when running the java program?
Here's the line for reference:
FileInputStream fileInputStream = new FileInputStream("/apps/somefile");
The line of code you present does not do anything directly. It is Java source code, and Java is ordinarily compiled to bytecode and presented in that form to the JVM. It sounds like your jar may contain source files along with the compiled class files, which is sometimes done. If that's the case then you can simply unpack the Java sources from the jar, modify them, recompile, and make a new jar from the results.
If you don't have source then you could try decompiling, as another answer suggests. That's a bit nasty, but it probably would work.
Alternatively, what you actually ask is
is there anyway to change to root directory that "/" points to when running the java program?
In fact, there may be, depending on the system on which the code is running. You could conceivably run your program under chroot, which has precisely that effect. That's a distinctly non-trivial exercise, however, and if you don't have access to the root directory (though I'm not sure how you can do anything in that case) then you very likely do not have sufficient access to set up or use a chroot environment, either.
you need to do a decompiler to that jar. You can use : http://jd.benow.ca/
Then you need to change that class that have the InputStream and then compile again and make the Jar file.
Related
In my project i need to take jsons from folder located in resources. For it I implemented this method:
protected def getListOfJsonFromResources(path: String): List[String] = {
val source = Source.fromInputStream(Thread.currentThread().getContextClassLoader.getResourceAsStream(path))
println(source)
val list = source.getLines().map{file =>
Source.fromInputStream(Thread.currentThread().getContextClassLoader.getResourceAsStream(path + file))
.mkString
}.toList
source.close()
list
}
It's work fine in IDE but return nothing when I run my jar.
I know that problem is in val source as in jar it return empty iterator.
I tried already use this.getClass().getResourceAsStream(), this.getClass().getClassLoader().getResourceAsStream() and rewrite this method as java method.
I generate JAR in Idea (Build>Build Artifacts>Build). This files is inside JAR with correct path.
I use Apache Maven 3.6.3
My res folder: resources/folder/json/jsonFolder path:folder/json/jsonFolder/
How should I change this method to get list of jsons from given folder?
Thank, in advance.
The proper usage is actually MyClass.class.getResourceAsStream. After all, getClass().getRAS() would fail if your code is subclassed. However, I assume it isn't - so that change will improve the style of this code and future proof it, but it probably won't directly fix the issue.
What MyClass.class.getRAS does, is look in the exact same place that the MyClass.class file is at. For example, if you have a jar with:
META-INF/MANIFEST.MF
com/foo/app/MyClass.class
app-icon.png
com/foo/app/save.png
And you run MyClass, then MyClass.class.gRAS("save.png") will work out. As weill MyClass.class.gRAS("/app-icon.png") - note the leading slash.
Thus, if gRAS isn't working for you here, the conclusion is that you're either specifying the wrong path, or the file you need to be included with your app is not being included by your build tooling.
You haven't shown anything relevant from your build scripts, so there's not much to say about how to fix this. But I can give you the tools you need to debug the problem so you can fix it yourself, with this useful trick:
MyClass.class.getResource("MyClass.class")
works for any class. Print it (System.out.println the URL that falls out of the above call), and you will see the URL, which tells you exactly which of the no doubt many variants of MyClass is actually being used (by your IDE's build-on-save, by sbt's build tooling, in the jar file produced by sbt during the dist phase, and who knows how many more exist somewhere on disk!).
Now use standard computer tools (Mac: Finder, windows: Explorer, or just use the command line) to navigate to the actual location and check for the existence of this resource file. Note that jar files are just zip files; unzip -l somejar.jar is useful here.
If you see the file, well, now you know where that file is relative to MyClass.class, and now you know what to feed to the gRAS call. Note that .. is not a good idea; if it's not in the same dir as your class and not in any subdir, then use the leading slash to go off of the 'root' of the jar file or classpath root directory.
If you don't see the file, well, now you know that your build is broken. Search the web (or ask in a separate question here on SO) on how to fix that, and now you don't need to repeatedly build and run the entire app to figure it out; you can simply keep scanning the jar file produced by the build tool until the resource file shows up in the right spot.
NB: ClassLoader.getSystemCLassLoader.getResource, getThreadContext().getResource, getClass().getResource - these are all wrong. Don't do that. It'll probably also work, but it's more code and will break in various circumstances. MyClass.class.getResource does exactly what you want, is idiomatic, and is one of the shortest forms.
At the moment I create a file like this:
new File("C:\\Users\\user\\Projects\\javaProject\\src\\com\\javaProject\\package\\file.xml");
So far listing the whole path is the only way I can get the file to be create inside 'package' otherwise if I just use:
new File("file.xml");
it just gets created in the source directory and if I use:
new File("package\\file.xml");
it just throws errors
Have you tried using a relative path?
new File("com\\javaProject\\package\\file.xml");
Your Java code should not be creating files in your package directory.
Eventually, you're going to want to deploy your code, which usually means packaging it in a Jar file. You cannot modify a Jar file from within the code running in the Jar file.
Even if that might be physically possible, don't do it. Besides, the code to modify a Jar file is way different from your current code.
Yes I did in the same way like janos but i think File.separator is better then / or \ because someday your program might run on a platform developed in a far-off land, a land of strange things and stranger people, where horses cry and cows operate all the elevators. In this land, people have traditionally used the ":" character as a file separator, and so dutifully the JVM obeys their wishes.
Hello all I am trying to run help file(.chm) from netbeans directory with the help of this code
Process proc= Runtime.getRuntime().exec("hh.exe src/MOVECG_Pro.chm");
but problem arises when I try to run outside netbeans because inside jar src folder is not there. Kindly help me how to code it properly
You have placed your chm file inside your source code directory. Clearly that directory is not there when you run the JAR. I guess you want to have a standalone JAR which contains the help file bundled within it.
Since exec delegates to the native platform to interpret the command string as something it can start a subprocess with, you can imagine that there will be trouble with transparently accessing a file buried inside the JAR archive.
So either provide the help file separately, or write code which will extract the help file from the JAR at runtime. Then pass its location to hh.exe.
Let me also make a general statement: since you are writing a Java program here, which is supposed to be platform-independent, your approach with a Windows-specific help file isn't exactly by the book.
I have been googling around, trying to understand what the Java Classpath and Path are. However, I am stil not quite sure if I have understood it or not. If feel that this topic is one of those grey areas.
Can someone explain me what those are? I mean, where do I find and set them (where is the actual text file on Mac/Windows)? Is there only one instance of each one? If so, how do I set the path for multiple classes?
As you might have notices, I am totally confused right now after reading so many different tutorials... So now I really would like to have a straight forward explanation.
Please help me, I just trying to learn :)
Thank you all
A path is just a folder location. The path is where your OS will look for programs by default. If java, javac, javap, etc, etc, are in your path then you can just type their names without the entire folder location.
Your classpath is similar. It is a set of folders that contain .class files describing classes(hence the name) and .jar files, which are basically files that contain .class files. All code that you're running is either out of the classpath, generated, or out of the java libaries(also part of the classpath, techncically).
With each run of a java program you can specify a classpath by parameters passed to the java executable. It also grabs classes out of "extension folders,", special folders Java keeps around to act as a system classpath, and finally, the "bootstrap classes", which are a set of important classes almost any Java program needs to run.
Simple mean of path is location of file system. if you want to access any file then you have to manually needs to go there location.
just example: d:\text1.txt then needs to go that d:\ location. same way java program have command like
javac -for compile
java - for run
.
.
.
etc.
that inside java-jdk\bin folder
so if you don't set into classpath. then you can execute java program like
run->cmd
c:\jdk1.6\bin> javac test.java
so without going explicit way you can set it into classpath, and direct execute java program from anywhere.
You can set java path as environment variable of computer.
The PATH is basically where your JDK is installed; this is essentially what your IDE will look for when trying to compile or create Javadoc or such; it's basically just the location of a folder on your hard drive, set as a Windows (or other OS) environment variable to make it easier to use.
The CLASSPATH is a property that tells the compiler where to look for classes. Basically if you download a library or such from somewhere, you need to add it to the CLASSPATH for the compiler to use it. Usually you can do this in your IDE, however, you should not need to directly access the CLASSPATH variable.
By the way, the Wikipedia article is pretty helpful.
1)java Path: it is location of binary executable files
example :javac , java
this file are used for compile and run
2)class Path: it is location of .class file(file create after compile your source code .java file)
I have this Java application and I'm using an external Jar and one of the functions is throwing a java.io.FileNotFoundException. I have the file that it's looking for but I have no idea where I'm supposed to put it. Is there any program I can use that can give me the location of the path that it's trying to look at? Thanks.
if you run the application in a debugger, most debuggers allow you to break when an exception is thrown. you could then inspect the local state of the application to determine the relevant path.
you should also probably report this as an enhncement request to the original library author (to include the file name in the thrown exception).
Don't you have to the .class file of the Java class containing that method.If yes, decompile it to view the source code. This is one such decompiler
Also, try to look for any config file like a property file that may have the path information.
You can find the current working directory from System.getProperty("user.dir") and do some hit-trial by placing the file there.
If the exception stack does not give you a hint on where it is looking for the file, and placing it in common places e.g.
in user directory
home directory
current directory etc
does not work, I guess you can decompile the jar and see where it is looking for the file
Well, I doubt it is hardcoded so this will probably not show you exactly where it is looking...but you may want to decompile the class using JAD. This may clue you in on where it is looking.