VisualVM in IcedTea

VisualVM, the lightweight profiler and troubleshooting tool is now available to build as part of IcedTea6 for 32 and 64 bit arch :). The whole thing builds from source — NetBeans platform7 and profiler2 (visualvm_preview2), and finally VisualVM 1.0. A binary launcher `jvisualvm` is put in the ${JDK}/bin directory along with the rest of the tools.

Screenshots:

To get building, you’ll need to pass –enable-visualvm to ./configure. Subsequent builds should take advantage of –with-visualvm-src-zip, –with-netbeans-platform-src-zip, and –with-netbeans-profiler-src-zip options, to prevent re-downloading of the NetBeans and VisualVM sources. Once the zips/tarballs are downloaded for the first time, my VisualVM options passed to ./configure typically looks like this:

./configure ... --enable-visualvm --with-visualvm-src-zip=visualvm-20080728-src.tar.gz --with-netbeans-platform-src-zip=netbeans-6.0.1-200801291616-platform-src.zip --with-netbeans-profiler-src-zip=netbeans-profiler-visualvm_preview2.tar.gz

Also, you’ll probably need the ant-nodeps package installed for some bootstrapping when building.

Hopefully in the near future we’ll be able to see some of VisualVM in Fedora once NetBeans platform is packaged 🙂

EDIT: You do not need to build OpenJDK to /build/ VisualVM on it’s own. To just build VisualVM, you will need either an existing OpenJDK (like your system one, enabled with –with-openjdk in configure), or an IcedTea-ecj build. After that, typing `make visualvm` will build visualvm, but will not be *nicely* usable until you build IcedTea. VisualVM will only work nicely when dropped into a JDK-style directory, and this is done after IcedTea is built (dropping the visualvm build into j2sdk-image).

NetX Improvements

Finally my own blog 🙂 (thank lillian)

My latest bit of work with IcedTea and NetX was pushed into the IcedTea repo last night. While it’s not totally complete (yet), a large part of javaws security has been implemented. Let’s take a look…

Running a signed application always shows a dialog now, regardless if the code verification was successful or not. In this case, it shows that JDiskReport has an expired certificate.

Clicking on the More information button shows the details:

… and clicking on the Certificate Details button shows the info from the certificate used in signing:
Note that “Karsten Lentzsch” is the publisher of the software and “Thawte Server CA” is the 3rd party that did the signing.

In the case that an application is self signed, only one certificate is shown:

Should an application be unsigned, permission for security-sensitive operations are requested from the user, as shown in the Notepad application:

Right now only file-open, file-save, clipboard-read and clipboard-write are available as jnlp services. The rest should be coming hopefully soon :-).