As the other reply alluded this isn't a JVM problem but a problem with poorly written libraries. If a library sticks something in a ThreadLocal, creates a Thread, registers a JDBC driver, or several other tasks using classes from the webapp class loader and then DOESN'T CLEAN THEM UP when the webapp context is destroyed you get a ClassLoader leak. Just like any other Java memory leak it stems from having classes in the loader still reachable from the GC root.

Tomcat has made some great changes to their webapp classloader to watch for this bad behavior and forcibly remove/cleanup these references when a webapp shuts down, solving this problem in many cases.

Never frees ... unless you are using the CMS collector (any app that does that much class loading/creation/unloading is likely a great candidate for CMS) and you turn on CMSClassUnloadingEnabled in which case the JVM unloads Class objects which are NOT in use just fine.

It isn't slowing down to much and stopping the engine (stalling)

Isao is right on, any modern car (not sure when it started) simply turns off the injectors if it is in gear and the car's momentum is making the engine turn. The alternator and all the accessories are still running fine since the engine is being turned by the wheels, no fuel is being provided to the engine.

Its really easy to tell when the ECU on my outback does this by listening and watching the MPG readout. When I start coasting down a hill while in gear and the clutch engaged you can hear the engine sound change as the fuel shuts off and the MPG readout goes to all 9s.

In short, don't coast in neutral, the ECU is smart enough to save you gas when you coast in gear.

Man I wish I had mod points. +1

So you have no snow cover in the winter? Not being to flippant, just curious how big of a band of the US has cold enough weather to require heat but not enough snow to generally have your roof be white all winter anyways?

I had the same question but it is very well addressed in the PDF:

The PDF also goes into how this tech could have serious applications in things like home AC and refrigerator heat exchangers as well.

It is completely up to the site serving the resources. A quick look unsurprisingly shows twitter not being stupid about it and setting the correct headers to get the browser to cache resources served over HTTPS for as long as the browser can. Here are the response headers from getting their logo over HTTPS:

Date Wed, 16 Mar 2011 14:52:00 GMT
Content-Length 1159
Content-Type image/png
Etag "c53472495d431cceef1c715732db12c9"
Expires Wed, 18 May 2033 03:33:20 GMT
Last-Modified Tue, 15 Mar 2011 21:20:55 GMT

Note that it provides both an Etag and a far-future Expires date.

The problem is TechWorld having no idea what this tool is for. The announcement by Google http://google-opensource.blogspot.com/2011/02/contracts-for-java.html never mentions the word "buffer" and accurately describes this as a tool for pre/post validation of method arguments and return values. Some how TechWorld decided to tie in JVM level buffer overflow issues with a pure Java DbC tool, anyone actually familiar with Java knows at a glance that the two are unrelated.

I think that is a poorly written summary. You can't (in pure java and ignoring JVM bugs) overflow buffers. You can however forget to do sanity checking on inputs based on the business rules of your app. That is where this will help. Codifying even simple things like "The argument should never be null" in an annotation on the interface definition helps both document and consistency for implementations of that interface.

There have been several projects that have tried to do this before but the developers never saw it through. When annotations were added in JDK5 this was one of the features I've been looking for. Being able to define invariants on the interface will make implementations much more safe and consistent!

If external entities knowing that big random strings are used as passwords and sudo is used for doing things as root is viewed as a security problem by my employer I believe I have bigger problems.

That is how all of our servers are setup. I'm just a "developer" that uses them but I believe no one knows the root password for our systems. It is a *big* random string that is printed out by the sysadmin that sets up the machine, sealed in an envelope with that person's signature on both sides and stuck in a safe. In the event that a machine is so hosed that the root password is needed it is used and then a new one is generated and sealed away again.

Everyone uses sudo for everything. All sudo access is logged.

The system isn't perfect of course, nothing is, but it goes a long way to the worry of one person having root keys for things.

It probably isn't much work for the ECU to include a little logic to measure battery voltage and only do the shutoff when there is enough juice to start back up and also to restart if the battery drops low due to things like AC. I'd also be unsurprised if it doesn't do the shutoff at idle until the engine temp reaches a certain point. None of that seems like anything complex for a system like that.

Wrapping C/C++ in Java is doable but a pain. I'd argue that Java has such a large set of available libraries and built in APIs that you can generally do a lot more with a lot less code than in other languages.