We Keep Coding

Java translate reflection-invoked program's file API paths

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.

Java reflection property works in Linux but not Windows

I'm working on some code that is acting strange. The code is using the Java reflection property, loading the method name from a JSON file. Works perfectly in Linux, yet, importing and running the same code in the same IDE, with the code running in the same version and profile of a Websphere Application server setup, they are both using the same source files through a file server mount. Other parts of the application manipulate these files without a problem in both environments. Yet, somehow in Windows, it is unable to load the method from the file while Linux can. Stepping through the debugger in Windows I find that the null pointer error occurs at the time of trying to dynamically load the method, while stepping through the code in Linux in the same manner it simply proceeds where Windows gets stuck without issues. I'm getting this null pointer error from the application pointing to a method that does not exist due to the failure to load:
java.lang.NullPointerException
at com.mpi.factory.ToolStateFactory.getToolStateExtended(ToolStateFactory.java:19)
at com.mpi.factory.ToolStateFactory.getToolStateExtended(ToolStateFactory.java:33)
at com.mpi.factory.ToolStateFactory.getToolStateExtended(ToolStateFactory.java:41)
Given that the JRE is supposed to be portable and it shouldn't matter in what environment it runs, I suspect it's related to the OS. Has anyone experienced this issue before? I'm wondering if it's something that needs to be addressed at the OS level, or Java security settings? I know Windows is a bit more glitchy when it comes to drive mounts than Linux. I'm wondering if it's an obvious, well known issue with J2EE projects trying to use reflection in Java. I really don't think this has to do with the Webpshere, or project settings (Classpath, Deployment Descriptor, etc) since they are identical in both environments. Can't really find anything online about this quirk.

"java.lang.UnsatisfiedLinkError: no awt in java.library.path" in running JWS Swing app

We are sometimes getting this strange error from clients (automatically, no user report was filled until now), and none of us can make sense of it. A user starts our Swing Java-Web-Start "fat client" on a Win7 machine, eventually use some action that should produce a PDF document (using an ancient, modified Apache FOP version), and end up getting this error. So far, it's not reproducible on our side. Google did not help on this one either.
The big question is, how can awt dll be missing, when the awt dll is required to activate the action that causes the error?
Could something be unloading the awt dll? The stack-trace is pretty much always the same, and we found no evidence that this was preceded by some other error. Could this be the result of a non-logged preceding native error?
EDIT: The PDF generation runs in a background thread, while a blocking "wait" dialog prevents the user from closing or otherwise operating the UI.
java.lang.UnsatisfiedLinkError: no awt in java.library.path
at java.lang.ClassLoader.loadLibrary
at java.lang.Runtime.loadLibrary0
at java.lang.System.loadLibrary
at sun.java2d.cmm.lcms.LCMS$1.run
at java.security.AccessController.doPrivileged
at sun.java2d.cmm.lcms.LCMS.getModule
at sun.java2d.cmm.lcms.LcmsServiceProvider.getModule
at sun.java2d.cmm.CMMServiceProvider.getColorManagementModule
at sun.java2d.cmm.CMSManager.getModule
at java.awt.color.ICC_Profile.getInstance
at java.awt.color.ICC_Profile.getInstance
at org.apache.fop.pdf.PDFICCBasedColorSpace.setupsRGBColorProfile
at org.apache.fop.pdf.PDFICCBasedColorSpace.setupsRGBAsDefaultRGBColorSpace
at org.apache.fop.render.pdf.PDFRenderingUtil.addsRGBColorSpace
at org.apache.fop.render.pdf.PDFRenderingUtil.setupPDFDocument
at org.apache.fop.render.pdf.PDFDocumentHandler.startDocument
at org.apache.fop.render.intermediate.IFRenderer.startRenderer
at org.apache.fop.area.RenderPagesModel
at org.apache.fop.area.AreaTreeHandler.setupModel
at org.apache.fop.area.AreaTreeHandler
at org.apache.fop.render.RendererFactory.createFOEventHandler
at org.apache.fop.fo.FOTreeBuilder
at org.apache.fop.apps.Fop.createDefaultHandler
at org.apache.fop.apps.Fop
at org.apache.fop.apps.FopFactory.newFop
at org.apache.fop.apps.FopFactory.newFop
at ...
at javax.swing.SwingWorker$1.call
at java.util.concurrent.FutureTask.run
at javax.swing.SwingWorker.run
at ...
at java.util.concurrent.ThreadPoolExecutor.runWorker
at java.util.concurrent.ThreadPoolExecutor$Worker.run
at java.lang.Thread.run
EDIT: I found the code that causes the error (in grepcode.com):
/* the class initializer which loads the CMM */
static {
java.security.AccessController.doPrivileged(
new java.security.PrivilegedAction() {
public Object run() {
/* We need to load awt here because of usage trace and
* disposer frameworks
*/
System.loadLibrary("awt"); // HERE!
System.loadLibrary("lcms");
return null;
}
}
);
// ...
}

This is probably not the cause of the OP's errors, but this is something for others that get here with the same error for another reason.
This error can happen if the version of Java runtime environment updates while the application is still running; e.g. if it is updated through an MSI/EXE installer on Windows, or yum/apt-get/etc. on *nix. After the update, the DLL (Windows) or SO (Linux/Unix) that the running Java application is looking for may no longer be available at the location it knows about, and thus it is not found.
This is more likely in a Unix-like environment, where file locks do not necessarily prevent file deletions, and on a server, where long-running services that only need particular functionality that depends on these DLLs once in a while.
In such cases, a restart of the application is necessary.

VLC dying when called from inside Java

I'm having a problem that, at this moment, I don't even know how to investigate properly. Any recommendations on how I can get more information are welcome and appreciated.
My company sells a product with a WinXP PC at its core. One of the product's tasks is being able to start a video player on demand -- VLC, in this case. (To be specific, VLC 0.8.6d; it's several years out of date, but upgrading is problematic for a few reasons.) The application responsible for starting the player and performing many, many other tasks is written in Java.
I have a test rig sitting next to my desk. It used to work just fine. But for some reason, it now gives a "Send Error Report" window when the Java app tries to start VLC: "VLC media player has encountered a problem and needs to close...." You know the one.
Clearly, I've done something that buggered things up. Problem is, I know neither what it could be nor how I would go about fixing it.
Stuff I know:
It's not a code bug. I run the same software on my development desktop machine, and it doesn't have this issue.
It's not the VLC install, nor is it a malformed video file. When I capture the command used to start it from Java and manually enter that command from a "cmd" window, it works fine.
It's not that sneaky bastich bug where Java punishes you if you don't manually drain STDERR and STDOUT when making a system call. I've got that covered.
I'm not getting any error messages or output when it fails; it just fails and gives me that pop-up window.
I'm stumped. Recommendations for either what it could be or how I can figure out what it is are very welcome.

Well, I’m not familiar with java and VLC, but I would do the following things:
Check that you have identical java virtual machines in both of your desktops. Just in case…
Check the process’s environment variables. They depend on parent process. Maybe VLC uses some of them.
Try to debug crashing with native debugger like WinDbg. Perhaps the call stack will give you more ideas.
Good luck!

My suggestions:
Create a simple java app that just launches VLC
Use your app to launch a simple command line windows program
Use your app to launch a complex program
Check to see if there is a memory constraint issue. Is VLC getting too little memory to run?
This really sounds like a memory/environment issue.

A number of things I would try
Make Sure both test and development machines are identical in every respect, the operating syste(if possible installed from same OS Disk), same JVM version, same memory allocation to JVM (you know those -X-ms stuffs). My fear is not with Java/JVM per se, it is with windows.
Make sure you can lunch for example Notepad from a Java app, and then something like Windows Media Player or MS Word.
Try and launch other versions of VLC to see if it is a VLC version problem.
Finally try and wipe the test box and re-install it(with Windows, you can never tell, a fresh installation might just do it!!)

How to debug/log/trace an applet loading problem?

Recently two of our clients have reported problems with our applets. Looking at the java plugin console it is full of ClassNotFoundException so none of our code is executed.
I've been able to reproduce the stack trace using a virtual pc image with 0 free space on disk, but the problem goes away as I restore some disk space, and the users tell me that their disk is not full; they are able to create new files.
Our applet requires java 6, and the problem has appeared with updates 1, 10 and 14 of the jre. We have also tried different browsers (IE and Firefox), clearing the browser and java caches, ...
How can I debug or trace what is the jvm doing to load our applet?
I suppose that the problem lies on some security directive on windows so I'm using Sysinternal's Process Monitor to log the activity but I don't really know where to look at.

The Java cache is most likely messed up. Open Java in the Control Panel and get rid of all temporary files to see if it goes away.
Logging in the Java Console for loading applets can be enabled which helps quite alot (even if the plugin is extremely cryptic). See http://java.sun.com/javase/6/docs/technotes/guides/deployment/deployment-guide/tracing_logging.html

I've been looking at the plugin source from the JDK and I've found that there is additional debug info available in the logs setting the environment variable JPI_PLUGIN2_DEBUG.
Unfortunately I still only see ClassNotFound exceptions.
I've found a piece of the plugin code that swallows all exceptions, so maybe my users problem is there...

had similar problems a while ago. In our case, the problem seems to be how the applet tag is set up on the web page. If it is in a wrong order or contains the codebase attribute, it fails with 6u10+. This works for us:
<applet name="DMGANTT" archive="DMGantt.zip" code="dm.applet.DMGanttApplet"
width='100%' height='100%' mayscript="mayscript">

We had a similar problem with one of our clients. We discovered that it was a strange bug in some versions of Java related to proxy configuration on the client. See this article for the details
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6723715
Also, our applet failed with new versions for a different reason.
Now, in similar cases I ask them to check javatester.org, so that I can see if applets (in general) load OK in their browser. If that page loads OK, its a problem on our applet (or page). Else it's a problem in their configuration. I help them anyway but it's easier to debug.