Having said that there is still the odd case where either by omission or decision Java seems to be missing something important. Often this is when the API hits grey area for operating system level functions and it isn't clear that there is a way to 'generify' the API to make it work the same across multiple operating systems.
One simple example we run into now and again is an API which has been present in C for decades - forking.
Say for example your user wants to change languages in your app, you have two options:
1) write or modify your app so that the language can be changed live throughout your entire app (this would require some impressive forethought) or
2) change the language and relaunch
In terms of developer-hours spent (2) is the clear favourite here but unfortunately (and unlike much older C) Java won't help you out much with the relaunch.
Our best guess is that Java developers don't really like the idea that you are going to be managing JVMs much inside your Java app and want you to stay inside the one JVM, so although you get nice APIs to launch processes, send them input, gather their output and wait for them to terminate whats notably absent is a way to get the current JVM process arguments and executable so you can launch a copy of your app (maybe configured slightly differently to do some other job).
This is exactly the kind of case that we bump into now and again at JWrapper and when we do it bothers us. The JVM API might at some point address this but that could be a long wait and even if it does we don't necessarily want to ship the (undoubtedly larger) newer JRE, so if we do want to get it done might often have to resort to methods that don't feel supported or safe.
JWrapper is best thought of not just as an installer to get your app dumped on the client system, but as an app framework, a soft friendly wrapper around your app that takes the sharp pains from trying to have your app sit directly on the operating system, much like the JVM takes away the hassle of trying to develop directly for the OS.
Because of this whenever you run your app we make certain really useful APIs we've written available to your app at all times. Whenever your app runs these APIs have already been set up and are just there waiting to be used, on Windows, Linux and Mac.
Forking is a good example. In JWrapper you define your JVM options and one or more virtual apps. Because JWrapper has this info and is already dealing with launching and managing your JVM you don't need to go searching in the unsafe corners of your JVM APIs and avoiding OS-level quirks to figure out how to build a command to launch a new JVM with a new app (either the one you are already running or a new one). Instead you can just call:
and presto! a new app with its own JVM turns up regardless of what OS you are on. To make life even easier you can specify command line args in a variant of the above method and to avoid OS difficulties you can also pass in a Properties file which your new app can query. This properties file doesn't have size or character limits like the command line arguments do so you don't get caught out thinking that because the arguments you set work on MacOS it will work on Windows XP, only to find that limits are causing issues.
There's a whole bunch of useful APIs that your app gets for free when you run inside JWrapper but if there are frequently used bits of API missing from the Java API that you'd love to see available let us know and maybe we can add them.