Develop Reference

Remote debugging runtime library in a JVM from a different vendor

Is there a good approach to remotely debug and step through JVM classes (think rt.jar) of the target JVM? For example if my main development environment is on Windows Oracle HotSpot JVM and I want to remotely debug the application running on the AIX IBM JVM? The bytecode/internal classes are different so the line numbers don't exactly match up to what my IDE is showing me.

IBM offers their SDK for Windows here - https://www.ibm.com/developerworks/java/jdk/java8/.

Are there any Distributed JDK's (JVM) around? (or Stub JDK or Remote JDK/JVM)

I want to know if there exist a way to use a JVM of a remote machine? \
For example I need to do some compilation on a not-so-powerful machine with not much CPU crunching power, like in my IntelliJ IDE I can select a JDK to use for a specific project. However there are times that the workstation cannot handle the compilation process and so forth.
Now I have a very powerful server in the network, plus other resources around. Is there a "stub" JDK that will actually call on a remote JDK from another machine?

How to enable Memory monitors in Eclipse (Java project)?

I am trying to inspect the memory contents (bytes) of an object in a Java project.
The program is paused in the Eclipse IDE.
How ever: the Memory view is disabled - as in: the Add Memory monitor + button is greyed out.
Why?

This question seems to be unanswered for quite a while and the one above sure doesn't help. This is the only post about it I could find.
In the Eclipse Help platform information about Memory view can be found in the C/C++ Development User Guide > Reference > Debug Views > Memory View but that isn't useful when were on Java. In the Java Development Guide it isn't as easy to find. Adding just Java Development Guide to the scope and searching for memory returns information about the Memory View in Running and Debugging but doesn't help very much. It is a view but isn't found in the same > Reference > Debug Views > as the C/C++ Guide.
When running a program in Debug mode in Eclipse C\C++ the + in the Memory view lights up and you can add addresses. However, running your program in Debug view doesn't seem to do the same in Eclipse Java. I'm assuming it can't be used in Java Eclipse or has a special case use that isn't mentioned.

Using JConsole
The JConsole graphical user interface is a monitoring tool that complies to the Java Management Extensions (JMX) specification. JConsole uses the extensive instrumentation of the Java Virtual Machine (Java VM) to provide information about the performance and resource consumption of applications running on the Java platform.
In the Java Platform, Standard Edition (Java SE platform) 6, JConsole has been updated to present the look and feel of the Windows and GNOME desktops (other platforms will present the standard Java graphical look and feel). The screen captures presented in this document were taken from an instance of the interface running on Windows XP.
Starting JConsole
The jconsole executable can be found in JDK_HOME/bin, where JDK_HOME is the directory in which the Java Development Kit (JDK) is installed. If this directory is in your system path, you can start JConsole by simply typing jconsole in a command (shell) prompt. Otherwise, you have to type the full path to the executable file.
Command Syntax
You can use JConsole to monitor both local applications, namely those running on the same system as JConsole, as well as remote applications, namely those running on other systems.
source : http://docs.oracle.com/javase/6/docs/technotes/guides/management/jconsole.html

Vagrant for a Java project: should you compile in the VM or on the host?

Here’s the question: When using Vagrant for a Java project (or any compiled language project for that matter), should you compile in the VM or on the host? Also, would you want your IDE and all your development tools to be run from inside the VM as well, or on the host?
It seems to be not very well defined exactly how a Java IDE and the compile/deploy process work with a Vagrant VM. Generally my impression is that code is edited on the host, and run on the VM, which works great for non-compiled languages. Other answers on Stackoverflow have implied that Vagrant is less useful for compiled languages because of the extra compile step, but I still want to see what can be done.
Some things I’ve thought through already:
Why compile on the VM
if compiling on host, java is one more piece of software to install
if compiling on host, the java version on host must be manually kept up to date with that on the VM
the corresponding java version on the host might be unavailable (say, on a Mac)
Why have IDE on the VM
tighter integration between environment and IDE, can use shortcuts to run the application
can connect debugger for java applications without remote debugging (one step run/debug)
Why compile on the host
faster compile times
want to keep the VM as close to what production looks like as possible
Why have IDE on the host
it’s the vagrant convention to edit code on the host and run it on the VM
better UI performance (X forwarding and VNC are slow)
What are your thoughts: should I run my IDE from inside the VM or the host? Should I compile from inside the VM or the host?

After much thought and experimentation, I've decided on where to use Vagrant and how it integrates with the Java development workflow.
For JavaEE / deployed applications, configuring a web server and a database server are definitely things that have "enough" complexity to warrant the use of Vagrant. With two servers and the myriad ways to configure them, it's easy for configuration to get out of sync from one developer to another, bringing about the "works on my machine" syndrome. For this kind of software, it would work best to edit and compile the code on the host, and deploy to a Vagrant VM that mimics your production environment. The deployment folder for the web server could even be symlinked to a compile target on the host, removing the need to manually redeploy. So Vagrant could be an important part of your development lifecycle, but the cycle time for code/compile/deploy from the host and run on the VM with Java would be longer than the cycle time for code on the host and run on the VM that we see with PHP/Ruby/Node/etc.
For standalone Java applications (like libraries or desktop applications) the story changes a bit. In this case it makes the most sense to edit, compile, and run on the host machine, eschewing the use of Vagrant altogether. If you're using one of the big Java IDE's (Eclipse, Netbeans, IntelliJ...), you already have Java installed on the machine. At that point there is very little advantage compared to the overhead of using Vagrant, and only serves to put an extra layer of complexity in your development process. This is because by the time you are able to edit Java with an IDE you are able to run everything on the host anyway. One issue is that the version of Java required for the project may not match the version running the IDE on the host. In general (hopefully) this is not too much of a problem; as of this writing JDK6 is end-of-lifed and JDK8 is not yet released (guess where that leaves us). But if you did need to run multiple versions, you should be able to set JAVA_HOME on the host as needed. Though this does introduce extra complexity, it is less complexity than maintaining a Vagrant runtime just to work with projects using different versions of Java.
The interesting question is what to do with containerless web applications. Should the web server (in this case internal to the application) be run inside the VM as we did for the external web server? Or run on the host as we did for the standalone application? For containerless web applications, there is no external web server to worry about, but there is still likely a database. In this situation we can take a hybrid approach. Running a containerless web app is essentially the same as running a standalone application, so it would be effective to compile and run your code on the host machine. But with a database involved there is still enough complexity and configuration there that it makes sense to have the database server be on its own Vagrant VM.
Hopefully this gives Java developers who are interested in Vagrant some context about how to use it.

I was interested to this topic during the last year :)
My solution is to have a vagrant machine configurable with flags.
For example one of this flag enable the desktop gui because some developer prefer to code on the host machine while others prefer to have a much more integrated environment with the desktop and the IDE in it.
To face the desktop slowness you should install a very useful vagrant plugin (yeah... vagrant has plugins that greatly improve the development environment) in this way: vagrant plugin install vagrant-vbguest
This plugin will install virtual box guest addition on every guest to make it usable while using the virtualbox interface.
Then to enable the gui edit the Vagrantfile in this way:
config.vm.provider "virtualbox" do |vb|
vb.gui = true
end
Instead to speed-up the shared folder performances I suggest to use rsync:
config.vm.synced_folder "./git", "/home/vagrant/git", type: "rsync", rsync__exclude: ".git/"
In this way the source code is edited on the host and then rsync-ed to the guest.

How to profile a headless Java application, running remotely?

I have a headless Java application, running on a remote server as a daemon-style process.
I want to extract Java level profiling information from the process, of the sort displayed by JVisualVM. For example, it should show method invocation times and so on.
What is the best way of doing this? My understanding is that JVisualVM does not profile when connecting remotely.
Ideally, the profiling information would be stored in a file for later inspection, in a manner similar to Java heap generation (with jmap) and later analysis (with a heap inspector).

You can use NetBeans profiler remote profiling capability.
Remote Profiling
Profile an application that is running on a different system than your NetBeans IDE. The profiler's remote pack can be installed on a remote system, allowing you to profile an application that is started on that system.
In fact, VisualVM is based on it.
Beside various monitoring features, the tool contains a built-in profiler based on the NetBeans profiler. While the profiler UI in VisualVM looks simple (especially when compared to the NetBeans profiler), the profiling capabilities are almost as powerful as in NetBeans.
Here is a detailed blog post about Profiling a Java remote server using Netbeans.

According to the link you will have to set up jstatd and jmx:
http://javadevsoup.blogspot.de/2012/02/remote-java-profiling-using-visual-vm.html

I just found another product that I think does this: http://chrononsystems.com/products/chronon-recording-server