The following bug fix:

    6604091 4/4 OpenJDK jvm.dll property has incorrect VM version

appears to have broken the HotSpot version string when the workspace
is built with JPRT. Here is an excerpt from e-mail from Keith:

Keith McGuigan via RT wrote:
> > Ok, I've confirmed that this is indeed the problem. In c2_baseline, the sources
> > associated with putback 20070913113153.never.6604006, when built with JPRT,
> > results in a binary with a version of
> > "11.0-b07-2007-09-20-000214.km88527.workspace" (this is correct)
> >
> > The next sources for the next putback to c2_baseline,
> > 20070913133049.kvn.6604091, when built with JPRT, results in a binary with a
> > version of:
> > "11.0-b07" (this is wrong)
> >
> > Apparently the builds done with PRT result in a different version string, for if
> > I install the 20070913133049.kvn.6604091 binaries directly, the version string
> > appears correct.
> >
> > This appears to explain the remaining issue. This is a regression in the
> > workspace. The bug occurs somewhere in the JPRT build path in the workspace --
> > the reason this baseline caught it is likely only because it was the first
> > baseline to build with JPRT.
> >
> > JPRT should be absolved for the time being. I'll leave the rest of the
> > resolution of this to you guys unless new jprt install problems arise.
> >
> > --
> > - Keith
> >

Since this breakage does not affect Win* builds, our guess
is that the changes to build/linux/Makefile and
build/solaris/Makefile caused this problem.

Please see the following GTEE ticket for the gory details.

https://gtee.sfbay.sun.com/rt/Ticket/Display.html?id=514&user=guest&pass=guest