I am trying to implement something like virtual machine in Java. Yes, it NEEDS
to be made in java, since it wraps some already-coded java library and implements
it's abstractions. But on the problem...
The actual problem is that it is intended to run java programs written to be run
on UNIX platforms (e.g. They need to log to /var/log). I can load the jar, and launch it by invoking main method... But the real problem lies that whenever the file tries to access the filesystem, it crashes because the filesystem is not in proper format (e.g. It is missing /var/volatile as it is used commonly on embedded systems but rarely on full desktops). I am looking for a solution to translate default Java java.nio.File abstract pathnames to some other locations, or to make virtual FS in a file (like loop device), or anything similar, that would work like chroot for the program. I couldn't find a single soultion to this problem around the web. The real reason behind that is to allow users of any platform to run the VM without modifing the source code of the program being run in the VM.
Many Thanks.
Related
I would like to get the path to the working directory of a specific process (for example for the PID of the process). I am Not Talking about the working or current Directory of the process where my Java Code is running. Its a simple task with Linux, but for Windows i cant find a proper solution. Furthermore, it would be nice, if its a Command or a Framework for Java, because i will need the path in my Code. I am not looking for the path to the executable, also Not for a solution with wmic or process explorer.
Already thanks for the help.
I already tried commands like tlist and wmic, but those solutions cant be utilize in my code. I am looking for a solution that i can use without special installations on Windows.
JNI and JNA provide means to call directly into native libraries from Java code, and it is feasible to use these to call out to Windows libraries.
There is a github project that appears to be close to the need: https://github.com/kohsuke/winp. Perhaps you can add the needed code and send up a pull request, or fork the project.
Note that any solution here is going to be windows-specific, meaning the application using it will not run on another platform. Given the nature of the question, that doesn't sound like it would ever be a concern.
Is there a way to change working dir for JVM when running Java Webstart?
When i use system.setProperties("user.dir", newDir) it sets it(system.getProperties() shows it does) but ignores it.
Is this a limitation in Java Webstart to always use the working dir where i started the jnlp file?
I am using all permissions in the jnlp file.
Please help!
EDIT: Whatever i do now, my webstart always uses user.dir to save files. Frustrating!
I've had this question in the past myself, but I've always found that, in the end, I didn't need it. Why do I say this?
Because your java web start app is not like an executable run from Program Files. It doesn't even exist on your computer like most programs (it is broken up into a bunch of different files and reassembled by the JVM). Therefore, you cannot say that the program has its own directory to do what it needs.
But it doesn't need to. Here's why:
Java has the Preferences API to help when you need to store data. The under-workings of the Preferences API is as mysterious as JWS, thus they are really a perfect fit. Either way, if you need to write things to a file, you should check this API to see if it can meet your needs.
If you need to write files for the user, then prompting them and allowing them to choose the location obviously means you won't use your current working directory to read/write files.
If you need to serialize objects, you should just create a program directory using the user.home resource as #AndrewThompson suggested. This will be "your" directory and is as good (in fact, better) than a directory in Program Files (if you're running on Windows, as an example).
In conclusion, in all cases (that I've come across), there's no need to change your current working directory. If you need your own folder, create one in user.home (because you won't run into file permissions issues there).
..all my settings file i use is created in the user.dir.
There is the mistake. Put them in a sub-directory of user.home & the problem is solved.
In the hypothesis you really really need to divert user.dir property for Java WebStart execution, here is the only option I have found: set this system environment variable (so system wide):
_JAVA_OPTIONS="-Duser.dir=C:\Temp"
But care about it, this option is read and applied to any JVM executions.
Why was it required in my context ? Because Java WebStart ClassLoader was looking for any single resource (class, properties...) in user profile before getting it from jar files in cache. As the user profile has been moved to a network storage, application start up became terribly slow. I am still investigating Java sources to understand (and avoid) this behavior. So my applications work perfectly without setting user.dir but that was the only work-around for the performance issue we got at the moment.
The recommended way to pass runtime parameters or user specific setting is through the jnlp argument
<application-desc main-class=".....">
<argument>user.home</argument>
..............
I would like to associate a specific file type with my application, so when I double-click one of the files of this specific type, my application opens. This works just fine, but the file I double-clicked does not get passed as an argument to my program.
If I for instance associate my application with txt files and I double-click todo.txt, my application opens, but I have no idea which txt file I double-clicked.
From what I can read, this is how it's supposed to work on OS X, and instead of relying on the default behaviour (how it works on e.g. Windows), I should use ApplicationListener.handleOpenFile(); from com.apple.eawt. When I attempt this, however, I'm being told that I'm not allowed to do so:
Access restriction: The type ApplicationListener is not accessible due
to restriction on required library
/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/ui.jar
In another question here, one guy says he found the solution on some Chinese website, and the other says it isn't legal according to Java's license agreement terms.
I can find no mention of it in the Mac OS X Developer Library, and whatever links might seem useful on this site about JAR Bundler just sends me to a dead page on Apple's Developer site.
What am I missing? Is it supposed to be nearly impossible to do this, even though it's trivial on other operating systems?
It's probably worth mentioning... since JARfiles can't be associated with programs on OS X, I've created an OS X Application Bundle using JAR Bundler; an Apple tool made specifically for the purpose of being able to treat Java applications as native OS X applications. Using this is what allowed me to associate the file type with my application in the first place.
I've used OSXAdapter for preferences, about, and quit functionality. You might be able to leverage it's introspective approach to avoid the restriction. As com.apple.eawt.ApplicationListener is deprecated, you might try com.apple.eawt.OpenFilesHandler instead.
I have made a java program that creates PDF files based to GnuPdf. It runs perfectly when run using native java code (on windows or iSeries QSH), however, when run through an RPGLE interface, the program crashes (at what seems like random intervals) when processing images. I tracked down one of these down to loading an image from a .jar file and removed the call from the code. It worked for a while but is now crashing for images loaded from IFS. Maybe RPGLE is locking the files somehow, and ideas? The code is called from a Service Program.
Here is the stacktrace
java.lang.NullPointerException
at gnu.jpdf.PDFImage.write(PDFImage.java:286)
at gnu.jpdf.PDFOutput.write(PDFOutput.java:114)
at gnu.jpdf.PDFDocument.write(PDFDocument.java:307)
at gnu.jpdf.PDFJob.end(PDFJob.java:182)
at com.mysite.pdf.PdfDocumentStateValid.endDocument(PdfDocumentStateValid.java:657)
at com.mysite.pdf.PdfDocument.endDocument(PdfDocument.java:36)
java.io.IOException: Descriptor not valid.
at java.lang.Throwable.<init>(Throwable.java:196)
at java.lang.Exception.<init>(Exception.java:41)
at java.io.IOException.<init>(IOException.java:40)
at java.io.FileOutputStream.writeBytes(Native Method)
at java.io.FileOutputStream.write(FileOutputStream.java:260)
at java.io.ByteArrayOutputStream.writeTo(ByteArrayOutputStream.java:112)
at gnu.jpdf.PDFOutput.<init>(PDFOutput.java:96)
at gnu.jpdf.PDFDocument.write(PDFDocument.java:302)
at gnu.jpdf.PDFJob.end(PDFJob.java:182)
at java.awt.PrintJob.finalize(PrintJob.java:60)
at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:116)
at java.lang.ref.Finalizer.access$100(Finalizer.java:47)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:193)
Changing my answer here now that I can see the stack trace. The problem happens when you hit native code (native meaning you are basically drilling into OS level or OS custom code).
You are getting an IOException of Descriptor not valid (and by that I'm assuming it means the file descriptor (ie, FileDescriptor). Now the big difference between running it in QShell and running it from RPG is that the Java code invoked from RPG is probably invoked under a different ID and/or privilege level. You may have to make modifications to the iSeries to your program to grant it authority for Java to have the right authorities to do what it needs. (I know you would think that is something the SecurityManager in Java would have picked up...but I know wierd things can happens sometimes when you are using a custom JVM (read IBM's) on a custom OS (i5/OS). You are left to the mercy of the vendor (in this case IBM). Give that a shot (the permissions thing) and see if that solves your problem.
Also...I googled and just found this related to iSeries: https://www-304.ibm.com/support/docview.wss?uid=nas379538999e744aad1862575b0006e28ab
So it might be that the jt400 library used by the OS may have a flaw and you may need to PTF it and/or your JVM too. Just another thought of something to try.
I have a Java program that is mostly GUI and it shows data that is written to an xml file from a c++ command line tool. Now I want to add a button to the java program to refresh the data. This means that my program has to call the c++ functionality.
Is the best way to just call the program from java through a system call?
The c++ program will be compiled for mac os and windows and should always be in the same directory as the java program.
I would like to generate an executable can the c program be stored inside the jar and called from my program?
If you have access to the code and want an 'interactive' experience with the external program (e.g., make call, get results, make additional calls), investigate JNI, which allows you to call C or C++ code from a Java application by including & linking JNI juice to your C or C++ app with .
See:
http://en.wikipedia.org/wiki/Java_Native_Interface
http://www.acm.org/crossroads/xrds4-2/jni.html
If you really just need a "launch app and get results" sort of solution, check out Runtime.exec(), which lets you launch an external program & capture its output.
See:
http://www.javaworld.com/javaworld/jw-12-2000/jw-1229-traps.html?page=1
http://www.rgagnon.com/javadetails/java-0014.html
Assuming no better communication method is available (SOAP, ICE, Sockets, etc), I'd call the executable using Runtime.exec(). JNI can be used to interface directly, but I wouldn't recommended it. No you can't put an executable in the jar. Well you can, but you can't run it, since the shell doesn't know how to run it.
You may also want to look at the Java Native Access API (JNA).
To answer your final question, you can't run an executable from within your jar.
However, you can store it within your jar and extract it to a temporary directory/file prior to running it (check for its presence the first time and extract if necessary). This will simplify your distribution somewhat, in that you only have the jar to distribute, and ensures that you're running an executable that matches your jarred Java code.