The new JDK 1.5 / J2SE 5 comes with a new set of experimental tools. There are performance monitoring tools: jconsole, jps, jstat, jstatd. Also, some new troubleshooting tools are available. These tools show memory maps, generate stack traces on threads, and print config info for a process or core.

Monitoring and Management Tools

• jconsole: J2SE Monitoring and Management Console - JMX-compliant graphical tool for monitoring a Java virtual machine. It can monitor both local and remote JVMs.
• jps: JVM Process Status Tool - Lists instrumented HotSpot Java virtual machines on a target system.
• jstat: JVM Statistics Monitoring Tool - Attaches to an instrumented HotSpot Java virtual machine and collects and logs performance statistics as specified by the command line options.
• jstatd: JVM jstat Daemon - Launches an RMI server application that monitors for the creation and termination of instrumented HotSpot Java virtual machines and provides a interface to allow remote monitoring tools to attach to Java virtual machines running on the local system.

Troubleshooting Tools

• jinfo: Configuration Info for Java - Prints configuration information for for a given process or core file or a remote debug server.
• jmap: Memory Map for Java - Prints shared object memory maps or heap memory details of a given process or core file or a remote debug server.
• jsadebugd: Serviceability Agent Debug Daemon for Java - Attaches to a process or core file and acts as a debug server.
• jstack: Stack Trace for Java - Prints a stack trace of threads for a given process or core file or remote debug server.

Read more about the tools at: JDK Tools and Utilities

So awesome. Like a wishlist come true !

So much to learn !! Feel like a newbie again !

EJB for Architects

Improve planning, trouble-shooting, and Sept. 17-21 Aug. 27-31
architect consulting skills in a unique Dec. 10-14 Oct. 15-19
forum to discuss problems common to EJB Dec. 10-14 Nov. 26-30
and related technologies.
----------------------------------------------------------------------

All courses cost $2395 except EJB for Architects. EJ for Architects costs $2995, and is not recommended for beginners. Register online or get course details about The Middleware Company training events at http://www.middleware-company.com/schedule.shtml? Pr908

jstack: Stack Trace for Java - Prints a stack trace of threads for a given process or core file or remote debug server.

<br>
This will be great. Getting a stack trace out of a JVM is relatively easy (kill -3 or Ctrl-break), but finding the place that sysout is getting directed to can be a bear. Plus, ususally developers won't have the authority to shell in and run a "kill -3" on a production server. Having a specialized command that can get stack traces from a remote server will be very handy.

I'm usually pretty criticle of SUN work and features, but this is pretty bad ass.

Very cool guys...

Give us the native compiler. Please. That would be a tool I would realy like

isn't there gcj?

I use it for my SWT apps. I find it difficult to set up and I haven't figured out quite yet how to get rid of the 10mb libgcj.dll. You would want a tool, say jnc.exe (Java Native Compiler) that analizes what java classes are used and only complie those ones. Don't know if that posible, but would be cool. Excelsior does that I believe, not sure though. Anyway why should those tools be external to a JDK

Give us the native compiler. Please. That would be a tool I would realy like

Use Hotspot. Comes automatically with modern JDKs, and compiles into native machine code.

Hotspot doesn't write the compiled code into a file, it compiles into memory and immediately executes the compiled code. That is the better way, as it allows for more optimizations.

There are static Java compilers around, but they aren't used much since the code they produce isn't as good as that of a dynamic compiler.

The problem is that you have to distribute the huge JRE. It's the same problem you have with .Net.

For .Net there might be a solution:
http://www.remotesoft.com/linker/

For Java it might be Excelsior. GCJ might be a solution as long as you don't use Swing... with SWT or XUL-frameworks it might just work out.

Sun tries to get a huge installed userbase, that's why they don't have a static compiler. I still think it's wrong to place the burden on the developer however. The best language to write cross-platform shareware, where download size matters a lot, is still C++ :-/.

Yes, this is better news than experimental language features.

Note also the new pack200 jar file format.
<quote>pack200 is a Java application that transforms a JAR file into a compressed pack200 file using the Java gzip compressor. The pack200 files are highly compressed files that can be directly deployed, saving bandwidth and reducing download time.</quote>

Isn't it ironic that they reinvented the good'old .tar.gz in Y2K4 (jars were previously .zip files)? :-) At least, they could have gone the bzip2 way; gzip is based on 1977 work, when cpu power was quite limited... sigh...

Note also the new pack200 jar file format.<quote>pack200 is a Java application that transforms a JAR file into a compressed pack200 file using the Java gzip compressor. The pack200 files are highly compressed files that can be directly deployed, saving bandwidth and reducing download time.</quote>Isn't it ironic that they reinvented the good'old .tar.gz in Y2K4 (jars were previously .zip files)? :-) At least, they could have gone the bzip2 way; gzip is based on 1977 work, when cpu power was quite limited... sigh...

This is totally wrong. The pack200 consists of a separate, java-specific package operation, resulting in a "pack" file about 50% the size of the original. Then this file is gzipped to a "pack.gz" file about 50% of the size of the pack file.
(These are my numbers, the official numbers are 25% :)

Note that gzip and zip is essentially the same: The compression methods are more or less the same, just header information etc is different.