new convention for hsx project repository names
volker.simonis at gmail.com
Fri Sep 6 08:09:35 PDT 2013
On Fri, Sep 6, 2013 at 4:28 PM, Staffan Larsen
<staffan.larsen at oracle.com> wrote:
> On 6 sep 2013, at 16:16, Volker Simonis <volker.simonis at gmail.com> wrote:
>> On Fri, Sep 6, 2013 at 3:18 PM, Staffan Larsen
>> <staffan.larsen at oracle.com> wrote:
>>> What if there was a one-to-one relationship between HotSpot and the JDK? I
>>> think that is the direction we are heading in.
>> That would be an ideal world:)
>> But we shouldn't unnecessarily complicate the process of doing it
>> nevertheless if it is useful or necessary.
>> And developing the HotSpot independently of the JDK with faster
>> release cycles isn't a bad idea in my opinion. As we've seen in JDK7
>> and especially JDK6 it is possible to deliver quite a lot of benefits
>> to the user with a new VM without having to go trough the heaviweigt
>> process of releasing a new JDK version.
> From a customer's point of view I have always found this extremely questionable.
> The customer applies an update version of the JDK (supposedly containing
> only bug fixes), but gets a whole new version of he JVM (including many new
That's of course a problem, but is manageable. But customers are also
extremely happy if they get some new features or better performance
for free (e.g. the new JSR292 implementation in hsx24 which will be in
jdk7u40). And not all JVM features have to be covered by the JCP, most
of them are just implementation details.
> I hope instead that we can get the release cycle of the JDK to be fast enough
> that we can deliver timely Hotspot updates within that cycle.
But the problem is (and believe me, this statement is backed up by
experience) that costumers are very reluctant to update to new JDK
versions. For many customers even the current release cycles are too
fast. They rather update their hardware than updating their software
More information about the hotspot-dev