What are the differences in starting an application through the plain java command, against directly invoking the JVM through libjvm.so in Linux or jvm.dll in Windows ?
Recently I saw on a forum that starting eclipse using the dll or .so file will give better performance. I would like to get to know how this happens.
Thanks.
Typically folks build against jvm.dll if they want to wrap their own functionality around a Java core, where sometimes it's hard to do things that look "native" from Java. A good example is indeed Eclipse, where they want to pop up a splash screen and do some other actions before starting up. For other products, it's that Java is only a small part of their workload (eg: large C++ app that needs to bridge into Java at some point).
From a performance perspective, it's irrelevant. It's all about how you want the "fit and finish" for things like Eclipse.
The link discusses Eclipse start-up; it is likely that this is faster because, by using the -vm argument to specify the JRE, the Eclipse executable doesn't have to search the system for an appropriate JRE to launch (which would incur disk I/O and possibly involve detecting the version of the JRE). You aren't speeding up Java, you're speeding up the native launcher.
Related
I've recently been experimenting with Processing (https://processing.org/).
It's a sort of IDE used to make GUI design in Java easier. Since I'm not a fan of swing or AWT, I found it quite fun to use.
Something interesting to note though. When I "export" the Application for windows, it creates both a 32-bit and 64-bit version.
I'm a little confused as I thought after Java source code is compiled to Java bytecode, it can be run anywhere as long as that place as a JVM. (Write once, run anywhere).
So why are both a 32 bit and 64 bit version of the app created? Shouldn't the bytecode be platform independent and only be translated using Just-In-Time compilation to whichever architecture the JVM is on, during runtime? At least, I know that's how .NET does it with the CLR.
I'm going to attempt to answer my own question by saying since the applications created are .exe files, the translation to native architecture happened ALREADY, since windows was specified as a target-platform...I guess to increase efficiency?
Otherwise, I'm confused. The only time I've seen a compilation happen twice is when I was programming C++, and needed to compile twice for 32-bit and 64-bit.
Thank you!
Processing is built on top of JOGL which is (basically) a Java wrapper of OpenGL, which is a device-specific graphics library.
Also, Processing (can) include a whole JVM with its exported applications, so end users don't have to worry about downloading Java. The JVM itself is OS-dependent, so the exported application is as well.
You can confirm this by taking a look at the files that Processing creates. Specifically, notice these files:
jogl-rt-natives-windows-amd64.jar
jogl-all-natives-windows-amd64.jar
These .jar files contain the native files required by JOGL.
As a hobby I have been writing a shell in java. It's very basic, it include the creation, deletion, reading of files through a command line or through a desktop-like environment if a plugin is installed (which I also wrote).
Now my question is a very complicated one, but I hope someone can point me to the right direction.
Is there a layer or an operating system out there that has java
support, so I can run my java application on top of it, to serve as a
shell? Something minimal?
I don't fully understand the library inheritance in java to its full extent yet, and I'm not sure if AWT and swing applications are something that is built for the major OSs out there.
Can someone point me in the right direction? I just want to learn here, and I don't fully understand the full details of the layers underneath my java program.
There are (at least) 2 examples where Java is supported at the operating system level
Sun had a bare-metal operating system called JavaOS which is no longer available. I don't recall the exact details but I think that the target architecture was some kind of embedded processor.
There is an open source bare-metal Java operating system called JNode that runs on x86. It already has a command shell (the "bjorne" shell) and a primitive GUI.
The bad news with JNode is that it doesn't have a working "isolates" implementation, so it is impossible to stop a buggy applications from bringing the operating system to its knees. This has become a roadblock to progress ... especially since a viable isolates implementation probably would require a redesign of the system architecture to support a separate address space for each isolate.
Java doesn't interact directly with the OS, instead it uses the Java VM that serves as a mediator between the Java app and the hosting OS. Having this VM allows Java apps to be portable since it abstracts away the OS specifics. Java VM implementations differ for different OSs but that's probably not something you should be worrying about; the VM is available and distributed for most major OSs, just download and install the one for yours from http://www.java.com. After that you're free to go with your app.
I working on a Java based application which can be carried around by the user in a USB flash Drive. At the startup I want to check for existing JVMs on the machine the USB is plugged-in.
How can I achieve it ???
Investigate JSmooth -- http://jsmooth.sourceforge.net/ --
or Java Web Start in newest Java 6.
http://java.sun.com/j2se/1.5.0/docs/guide/javaws/developersguide/cdinstall.03.06.html
If you wrap the program in an .exe wrapper - as Launch4j - it can check for JVM installation,
before each execution.
Isn't this a chicken-and-egg situation?
Your Java program needs to be launched in a JVM before it can run its logic to look for JVMs. And at the point it can look, a JVM has already been found so I don't think you could do anything particularly useful with it. (Unless your "main" app is actually a tiny bootstrapper, which chooses the JVM it wants and uses Runtime.exec to launch the real application.)
In any case, I would suggest that it's not the responsibility of the application to choose which JVM it wants to run in; the user will set up his environment to run with the JVM he wants, and I'd consider it rude to ignore this and force your own choice on him (which is likely to be made with less knowledge about the relative merits of those JVMs).
I've noticed that when I start Netbeans it shows up in the task manager as netbeans.exe as all my own Java applications show up as java.exe or javaw.exe.
How can I change that so my process names shows up as myapp.exe?
The process name is the name of the JVM. So if you rename the jvm you have an other process name. There are some tools which can do that for you. For example Launch4J
IMO the best option is to choose one of the many open source launchers. They all provide a nicer deployment container than java.exe and a batch file.
I've compiled a list of them after a brief search on google (in no particular order and may not be exhaustive):
NSIS
Janel (dead link)
JSmooth
Launch4J
WinRun4J
(full disclosure: i work on winrun4j)
Not easily. The easiest way (but not nice!) would be to simply copy the java.exe (only 68k on my system, so perhaps practical!)
If you're worried about identifying which java process is which (e.g. is one consuming memory/CPU etc.), use the standard tool jps to identify the Java processes
Netbeans and Eclipse both ship with an .exe file that in turns launches a JVM. The exe itaself probably does nothing after launching the VM. You see the NetBeans javaw.exe in the Task Manager also, I suspect.
So you'll need to write a native exe (using some windows tool) that does a similar thing.
Just answered this a second ago here: Get JVM to grow memory demand as needed up to size of VM limit?
It's actually a lot easier than folks are saying (but you do have to have a c/c++ compiler handy).
There are mainly 2 approaches: one is as already described: using tools like Launch4j, WinRun4J to create native Windows launchers.
Another approach that seems better is to use Apache Procrun to wrap the java application as a Windows service. During the install service process, we can give the process an meaningful name such as OurApp.exe.
All we need do is rename prunsrv.exe to OurApp.exe and replace every occurrence of prunsrv.exe in our install|start|stop|uninstall service scripts to MyApp.exe.
See more from Using Apache Procrun to Rename Process Name of a Java Program in Windows
I want a Java IDE with a compiler for Linux and that does not require a a big amount of RAM.
I have 256 MB of ram, so my options are limited
In my first programming courses, we used BlueJ as our "IDE". Really basic, yet gets the job done. It honestly don't have a lot of features, but it's lightweight, portable and effective
You have to link it with an external compiler though, but it shouldn't be a problem if you already develop in Java with this computer.
Eclipse would be the last thing you want. I can gather you've probably already tried it from the title. For a small footprint I'd suggest JEdit. It's much smaller, mature and extensible. There's also Kate if you run KDE. While it doesn't have the embedded compiler support you could add one in as an external command.
What do you mean by "IDE".
You could use Emacs with that kind of memory foootprint, use Ant for the builds and emacs would allow you to debug in the editor, and also take you to compile errors...
But it would not have a GUI development component.
For more detail on using Emacs as a full featured Java IDE, read this IBM document:
http://www.ibm.com/developerworks/java/library/j-emacs/
Does the 256MB of RAM also include program space, or will the code be stored elsewhere in flash or another memory type?
You can get embeddable java machines, and small java compilers for linux. The IDE, however, is tricky as you don't merely say editor, but you want a whole integrated environment.
Since you have Java installed already, I suggest Eclipse. It seems bulky and resource intensive on PCs, but you can cut it back significantly by removing features (classes) you don't want/need.
-Adam
jEdit will work easily.
Eclipse 1.x will work in that amount of RAM. Depending on your version of java, Eclipse 1.x will definitely work in that RAM.