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
Related
We Have a Multi-threaded Application in JAVA which has multiple threads running in parallel. Now we want to run all these threads on a single core. Currently application is running on a system having more then one Cores.
We know there is a technique available ProcesAffinity in .Net Framework to set process affinity.
But we don't want to depend on .Net Framework, because our application is build in java.
Do we set Process affinity using Bat file and run our application executable jar file through Bat file?
Currently our application is running on Window XP. So we need a solution that should be working fine on XP platform.
EDIT:
It's possible: See Java thread affinity
Pure Java doesn't support running a thread on specific processor. Check the SO question linked above.
Personally, I don't think that the fact that this cannot be set in pure Java is a bad thing, as to me, how an app is run does very much depend on the OS, so therefore a OS-specific solution isn't a bad thing.
You can use the MS psexec utility to set the affinity:
psexec -a 1 java -jar myapplication.jar
Would instruct that all of the threads created by java would be run on the lowest CPU.
And this line would be your .BAT file...
You cannot do it in pure Java. But on some versions of Windows, you can do it via operating system utilities; see https://superuser.com/questions/309617/how-to-limit-a-process-to-a-single-cpu-core ... and you might be able to do this by calling native libraries via JNI.
I'm developing a web application with Eclipse and Tomcat on windows. When testing my efforts I sometimes crash Tomcat, and the only option left is to kill the jvm hosting Tomcat, but that can only be done with windows' task manager.
The process to kill is a java process but eclipse is also on a java process and basically the only thing I can do determine which java process to kill is toss a coin and hope for the best. It seems that I choose the wrong (eclipse) java process more often than the tomcat java process. Of course I can and should write down the id of the only java before starting Tomcat but that is sometimes forgotten
Is there a way to determine which java process is for eclipse and which for Tomcat? when eclipse is up an running for a long time I can discriminate on the cpu time, but for short running instances this is no candidate for heurstics.
I use Process Explorer which is free and I can easily see in its GUI (in process tree view) that eclipse is a super node of Tomcat's JVM.
Use the Process Explorer from Sysinternals. It shows the hirarchy of processes, and since the Tomcat got started by Eclipse, you can see it as a “subprocess”.
You could start jvisualvm from the bin of your JDK directory. There each MainClass is listed with the corresponding pid.
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.
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).
If I'm using javaw.exe to launch a Java application, the shutdown hook isn't executed when users log off from their Windows account. The application is actually launched using a launch4j generated .exe file but I know it uses javaw.exe to start it.
This seems to be a known bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4302814
Has anyone else had this problem? If so, how did you fix it?
Thanks!
The application is actually launched using a launch4j generated .exe file but I know it uses javaw.exe to start it.
I haven't used launch4j in a while, but I'd be fairly suprised if it directly did this. Most of these apps start the jvm themselves, rather than shelling out to javaw.
The only difference between java.exe and javaw.exe is that java.exe automatically attaches a console. The bug that you reference (and the others referenced by it) were closed as Sun doesn't appear to be interested in making the handling of Windows logoff events better. From what I can tell, it only works with java.exe, because the console itself handles the WM_MESSAGES in such a way that it slows down the shutdown process.
It appears that the only easy workaround at the moment is to change the "headerType" in your launch4j config to "console". Obviously, this brings with it an ugly console.
I think the other alternative would be to use some sort of native wrapper of your on that handles windows messages in a cleaner way.