Java7 and loops - Before FUD gets out of hand...

289 views
Skip to first unread message

Fernando Cassia

unread,
Jul 30, 2011, 7:08:17 AM7/30/11
to java...@googlegroups.com
I have run several apps that I´m sure contains loops, and didnt
experience any crash. So what is this fud all about and why can´t
Oracle just release a 7.01 with the optimizations disabled by default
if it does indeed affect some of the code?

see the current activity on Twitter. it´s still small but I´m sure
Oracle and Java foes can have a field day if no answer is given.

https://twitter.com/#!/search/%23java%20loops

FC

Fabrizio Giudici

unread,
Jul 30, 2011, 7:34:31 AM7/30/11
to java...@googlegroups.com, Fernando Cassia
May ask two things, especially to the Lucene guys?

1. Were these loop-breaking optimizations introduced by default only in
7.0GA - so they weren't in betas?
2. If answer#1 is "no", did they try Lucene with betas?


--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
java.net/blog/fabriziogiudici - www.tidalwave.it/people
Fabrizio...@tidalwave.it

Fernando Cassia

unread,
Jul 30, 2011, 7:40:32 AM7/30/11
to Fabrizio Giudici, java...@googlegroups.com
On Sat, Jul 30, 2011 at 08:34, Fabrizio Giudici
<fabrizio...@tidalwave.it> wrote:
> On 07/30/2011 01:08 PM, Fernando Cassia wrote:
>>
>> I have run several apps that I´m sure contains loops, and didnt

As everything with Java ... I bet there´s a healthy dose of FUD and
politics thrown in to try to ruin Oracle´s Java 7 launch.

H*ck even Red Hat says Java is "resurging"
http://www.ctoedge.com/content/java-resurgence

FC

Fernando Cassia

unread,
Jul 30, 2011, 8:26:36 AM7/30/11
to Fabrizio Giudici, java...@googlegroups.com
On Sat, Jul 30, 2011 at 08:34, Fabrizio Giudici
<fabrizio...@tidalwave.it> wrote:
> 1. Were these loop-breaking optimizations introduced by default only in
> 7.0GA - so they weren't in betas?
> 2. If answer#1 is "no", did they try Lucene with betas?

I was able to find some more info and it turns out that:

1. that Oracle learned about it 5 days before GA release, and promised
a fix for the first JDK7 security update

2. that Java 6 users are also affected, if they enable
-XX:+OptimizeStringConcat or -XX:+AggressiveOpts
http://pages.citebite.com/d9y2u1i5bnjm

3. That this doom and gloom bug (according to tweets) actually affects
very specific conditions, and there is a work-around. In the words of
the poster:

-----
> These problems were detected only 5 days before the official Java 7 release, so Oracle had no time to fix those bugs, affecting also many more
> applications. In response to our questions, they proposed to include the fixes into service release u2 (eventually into service release u1, see
> [http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2011-July/005971.html]).
> This means you cannot use Lucene/Solr with Java 7 releases before Update 2! If you do, please don't open bug reports, it is not the committers' fault! At least disable loop optimizations using the -XX:-UseLoopPredicate JVM options
-----

4. As usual h-online has some of the best, in-depth reporting when it
comes to Java, without apocalypse headlines that I´m sure will appear
in other sites like TheReg...

Java 7 paralyses Lucene and Solr
http://www.h-online.com/open/news/item/Java-7-paralyses-Lucene-and-Solr-1288210.html

5. "Don´t use Java 7 for *anything*" seems to me like just bad faith,
specially given the availability of a work-around (point #3 above).

6. I wonder if, in situations like this, it wouldn´t be possible just
to issue a 7.01 that runs with the work-around parameter (
-XX:-UseLoopPredicate ) all the time, whether present and passed by
the user or not.

FC

Fernando Cassia

unread,
Jul 30, 2011, 8:29:09 AM7/30/11
to Fabrizio Giudici, java...@googlegroups.com
On Sat, Jul 30, 2011 at 09:26, Fernando Cassia <fca...@gmail.com> wrote:
> 5. "Don´t use Java 7 for *anything*" seems to me like just bad faith,
> specially given the availability of a work-around (point #3 above).

This blog post puts things in perspective:

Don´t use Java 7, are you kidding me?
http://blog.eisele.net/2011/07/dont-use-java-7-are-you-kidding-me.html

FC

Mark Derricutt

unread,
Jul 30, 2011, 9:02:44 AM7/30/11
to java...@googlegroups.com
I believe the code in Lucene which breaks, along with the tests that exercise that code ( and the breaking test ) were written within the last month.

I'm wondering if these optimizations were left off by default in OpenJDK, but only enabled in the Sun JDK build.

Does anyone know what differences there actually are being OpenJDK and the Sun JDK beyond version numbering/naming?

mbien

unread,
Jul 30, 2011, 3:27:22 PM7/30/11
to The Java Posse
2 of those 3 bugs are already fixed. just wait a few days and oracle
will release a EA build with this fixes - you'll see.

just don't panic and don't join the yellow press journalism :)
we all know nobody would use a .0 release for anything serious anyway,
most of us are happy to be able to use java 6 or even 5.

regards,
-michael

Mark Derricutt

unread,
Jul 30, 2011, 6:17:27 PM7/30/11
to java...@googlegroups.com
And NOT in production on day 0 ;-)

Fernando Cassia

unread,
Jul 31, 2011, 1:13:52 AM7/31/11
to Fabrizio Giudici, java...@googlegroups.com, Dalibor Topic
On Sat, Jul 30, 2011 at 09:26, Fernando Cassia <fca...@gmail.com> wrote:
> As usual h-online has some of the best, in-depth reporting when it
> comes to Java, without apocalypse headlines that I´m sure will appear
> in other sites like TheReg...

Oh well, let the games begin...

Oracle releases "buggy" Java SE 7
http://news.cnet.com/8301-1001_3-20085536-92/oracle-releases-buggy-java-se7/

FC

opinali

unread,
Jul 31, 2011, 8:23:42 AM7/31/11
to The Java Posse
7. That this bug is specific to HotSpot Server. It doesn't exist in
HotSpot Client (which doesn't even have the loop optimization that is
buggy...). So the JRE, which only includes the Client VM, is safe.
All desktop apps (ok... dev apps like Eclipse/NB etc.) are safe. The
JDK doesn't have auto-update, people running server apps always need
to explicitly and manually install a new JDK typically, and (unless
they are insane) they don't adopt a major new JVM without at least a
modicum amount of testing and evaluation; so in this case just add -
XX:-UseLoopPredicate - not doom&gloom even for servers.

A+
Osvaldo

On Jul 30, 8:26 am, Fernando Cassia <fcas...@gmail.com> wrote:
> On Sat, Jul 30, 2011 at 08:34, Fabrizio Giudici
>
> <fabrizio.giud...@tidalwave.it> wrote:
> > 1. Were these loop-breaking optimizations introduced by default only in
> > 7.0GA - so they weren't in betas?
> > 2. If answer#1 is "no", did they try Lucene with betas?
>
> I was able to find some more info and it turns out that:
>
> 1. that Oracle learned about it 5 days before GA release, and promised
> a fix for the first JDK7 security update
>
> 2. that Java 6 users are also affected, if they enable
> -XX:+OptimizeStringConcat or -XX:+AggressiveOptshttp://pages.citebite.com/d9y2u1i5bnjm
>
> 3. That this doom and gloom bug (according to tweets) actually affects
> very specific conditions, and there is a work-around. In the words of
> the poster:
>
> -----> These problems were detected only 5 days before the official Java 7 release, so Oracle had no time to fix those bugs, affecting also many more
> > applications. In response to our questions, they proposed to include the fixes into service release u2 (eventually into service release u1, see
> > [http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2011-July...]).
> > This means you cannot use Lucene/Solr with Java 7 releases before Update 2! If you do, please don't open bug reports, it is not the committers' fault! At least disable loop optimizations using the -XX:-UseLoopPredicate JVM options
>
> -----
>
> 4. As usual h-online has some of the best, in-depth reporting when it
> comes to Java, without apocalypse headlines that I´m sure will appear
> in other sites like TheReg...
>
> Java 7 paralyses Lucene and Solrhttp://www.h-online.com/open/news/item/Java-7-paralyses-Lucene-and-So...

Fabrizio Giudici

unread,
Jul 31, 2011, 5:23:12 PM7/31/11
to java...@googlegroups.com, opinali
Uwe has posted a clear and detailed crono-story of the thing:

http://blog.thetaphi.de/2011/07/real-story-behind-java-7-ga-bugs.html


Do I understand well that they started testing Lucene on Java 7 with
Hudson only one week ago?

opinali

unread,
Jul 31, 2011, 6:53:18 PM7/31/11
to The Java Posse
Yes that looks clear from the article. How stupid is that, start
testing a hugely popular project like Lucene on a hugely important JDK
update a single week before the latter is GA? And then complaining
that *Oracle* did not turn around immediately on the bug report, over
a weekend no less.

In all fairness, the loop optimization bug has a submit date of May
13, it was not discovered by the Lucene team. Maybe before Lucene,
Oracle evaluated that to be an extremely rare thing that wouldn't like
affect real-world code (Pentium FDIV all over again... never make this
kind of bet with bugs that silently produce wrong results, no matter
how huge your internal testing with real app code - as a single
important/vocal affected user/project means loads of shit hitting the
fan). So thumbs down to Oracle, too, for glossing over this particular
bug to keep their planned release date. But Lucene's behavior was just
as irresponsible.

One interesting comment is to complain that the GA build was the same
as the month-old b147. That's stupid, this is how a RC build is
SUPPOSED to be. Old Sun never did that properly, the GA release of a
major JDK update (and even most minor updates when these had beta
builds) was never identical to the last RC; it always had a few last-
minute changes (often revealed by a "micro-build" letter suffix, e.g.
"125e" where only that latter was increased from the last RC). JDK 7
is the first release I remember that's bit-per-bit identical to the
last public prerelease build, and that is good because that's a build
that thousands of people and projects have tested, which reduces the
risk of last-minute surprises in the GA.

A+
Osvaldo

On Jul 31, 5:23 pm, Fabrizio Giudici <fabrizio.giud...@tidalwave.it>
wrote:
> Fabrizio.Giud...@tidalwave.it

Wayne Fay

unread,
Jul 31, 2011, 11:33:26 PM7/31/11
to java...@googlegroups.com
> Yes that looks clear from the article. How stupid is that, start
> testing a hugely popular project like Lucene on a hugely important JDK
> update a single week before the latter is GA? And then complaining

You realize that you're talking about open source communities -- we
scratch our own itches, and I'm literally months if not longer away
from getting jdk7 in production anywhere important, so even if I was a
committer on Lucene/Solr, I might not have done any testing with jdk7
until now myself... Hard to really blame them, IMO.

Wayne

Fabrizio Giudici

unread,
Aug 1, 2011, 3:48:07 AM8/1/11
to java...@googlegroups.com, Wayne Fay

At first sight I'd not "blame" anybody in particular, also because the
Lucene guys - as far as I understand - just blogged "hey, we've got a
problem" without spreading FUD. As usual, the culprit is the blogsphere
where people like to amplify events because they have got some personal
bias, or to increment their click counter.

At second sight, I think that "open source" can't automatically mean
that some basic QA parts are missing. There are some small projects that
are the effort from one or just a few individuals; others, such as those
at the FSF or Apache Foundations, or Eclipse, or Netbeans, etc... where
you expect QA is taken seriously. Consider that there's not only the
risk of bug of the new JDK, but your own bugs (e.g. they discovered the
hidden dependency on a precise sequence of tests). Given that if you
have CI set up creating a new job for running JDK 7 is easy, frankly
they could have been that months ago.

Of course, the same holds for Oracle. I don't know whether they're
already doing that, but if I were them I'd set up myself some tests for
JDK running some popular, large framework / libraries. It would a be to
take advantage that even tests are FLOSS and while this would cost some
money, it must be compared with the costs of bad press.

Frankly, to me it holds the principle "if it's not tested it doesn't
work", so I assume that everything that others or I haven't explicitly
tested on Java 7 doesn't work (including all of my software, that I
haven't tested).


So I'd part the blame between Oracle and Lucene in this case. Just a few
of blame, because the thing doesn't sound very dramatic, until as soon
as there are no reports by other people discovering problems with their
own code.

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
java.net/blog/fabriziogiudici - www.tidalwave.it/people

Fabrizio...@tidalwave.it

Kirk

unread,
Aug 2, 2011, 5:11:00 PM8/2/11
to java...@googlegroups.com
I'd like to suggest that Oracle was asking people to test their projects with 7 and let them know if they ran into problems. Oracle *cannot* possibly test all products/projects and as important as Lucene may seem to you, I have only once run into it during an engagement (and I run through dozens a clients per year).

Bottom line, everyone knew it was coming.... the builds were freely avaliable. I've been using 7 on my Mac for months so.... I don't have much sympathy in this case.

Regards,
Kirk

> --
> You received this message because you are subscribed to the Google Groups "The Java Posse" group.
> To post to this group, send email to java...@googlegroups.com.
> To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
>

Mark Derricutt

unread,
Aug 2, 2011, 6:03:24 PM8/2/11
to java...@googlegroups.com
If it was just "a broken lucene" then maybe, but this revealed bugs in Hotspot itself.

I'd be curious to know how/why these bugs never revealed themselves earlier in whatever tests hotspot currently has, and whether or not any test cases have since been added to cover this now.

Mark

Ryan Schipper

unread,
Aug 3, 2011, 6:30:01 AM8/3/11
to java...@googlegroups.com
Presumably it's part of their change process to have bug-specific unit
tests (I've personally been doing it for years).

-- Ryan

ps. OpenJDK documentation seems to agree:
http://openjdk.java.net/guide/changePlanning.html#bug

Jan Goyvaerts

unread,
Aug 3, 2011, 7:04:51 AM8/3/11
to java...@googlegroups.com
Another one ...http://drdobbs.com/java/231300060. Although I'm exactly agreeing for all of it... Shipping it yes - but then just say you might switch this off to make sure you don't run into Lucene's trouble. That's no big deal. Well, to me that is.

It looks to me netbeans runs okay.

Kirk

unread,
Aug 3, 2011, 11:05:56 AM8/3/11
to java...@googlegroups.com
I don't think this is a denial of the bug, it's just that out of the blocks there is a huge amount of FUD about a problem that the Lucene guys could have looked at quite a while ago.

Regards,
Kirk

Robert Casto

unread,
Aug 3, 2011, 11:17:34 AM8/3/11
to java...@googlegroups.com
And why should Oracle have to worry about what the Lucene guys are doing anyway. Now that they know about the bug they will test for it. But they can't be expected to test every piece of software out there that runs on Java. The Lucene guys should have tested against Java7 long ago and seen this issue and reported it or worked around it. I'm just glad that a new version is out and I can't wait for Java8 and hopefully get some long awaited for features, better date library, and much more. With a great Java8 release, Java as a language will have a long life ahead.
--
Robert Casto
www.robertcasto.com
www.sellerstoolbox.com

Jess Holle

unread,
Aug 3, 2011, 12:19:38 PM8/3/11
to java...@googlegroups.com, Robert Casto
I don't think one should discount the possibility of bugs in the JIT compiler uncovered by Lucene having a much broader impact in other production code that hasn't yet been run for long periods of time on Java 7.  Just because something runs on Java 7 for an hour or two isn't sufficient -- we've seen JIT bugs surface [1] that require days of execution to get enough passes through critical code to JIT it to the point of breakage.

Bugs in the JIT compiler should be taken extremely seriously.  Crashes, poor performance, etc, are not nearly as big of a deal as quietly and mysteriously incorrect results.

Oracle had 5 days to change the default value of the optimization flag in question -- and I believe they should have done just that.  If I wanted a JVM where I had to flip a bunch of knobs just to get it to run correctly I'd use IBM's JVM.

--
Jess Holle

[1] This was in Tomcat and due to a JIT bug involving String.indexOf() optimization on some Intel hardware that occurs from Java 6 Update 18 through 23.

Fabrizio Giudici

unread,
Aug 3, 2011, 2:31:38 PM8/3/11
to java...@googlegroups.com, Mark Derricutt
On 08/03/2011 12:03 AM, Mark Derricutt wrote:
> If it was just "a broken lucene" then maybe, but this revealed bugs in
> Hotspot itself.
>
This doesn't mean anything. There have always been bugs in HotSpot. The
point is how relevant they are and how likely they trigger. Sure, they
are critical for their consequences; but how likely do they trigger? So
far I haven't seen reports by other people, apart from Lucene. In any
case, I'd like people to spend at least as much time to *test* their
stuff with Java 7 as they spend to talk about Java 7 bugs ;-) With
Hudson it's relatively simple to add extra jobs. Personally, I've
started with my own stuff.

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
java.net/blog/fabriziogiudici - www.tidalwave.it/people

Fabrizio...@tidalwave.it

Ricky Clarkson

unread,
Aug 3, 2011, 9:35:45 PM8/3/11
to java...@googlegroups.com, Mark Derricutt
News at 9:30, Java 7 is broken in conjunction with the Cisco VPN
AnyConnect client: http://www.java.net/node/703177

opinali

unread,
Aug 4, 2011, 7:12:46 AM8/4/11
to The Java Posse
That seems to be purely a bug in Cisco's software, not supporting
IPv6. This coming from Cisco, the company that's basically synonym
for network gear... pretty odd.

A+
Osvaldo

On Aug 3, 9:35 pm, Ricky Clarkson <ricky.clark...@gmail.com> wrote:
> News at 9:30, Java 7 is broken in conjunction with the Cisco VPN
> AnyConnect client:http://www.java.net/node/703177
>
> On Wed, Aug 3, 2011 at 2:31 PM, Fabrizio Giudici
>
>
>
>
>
>
>
> <fabrizio.giud...@tidalwave.it> wrote:
> > On 08/03/2011 12:03 AM, Mark Derricutt wrote:
>
> >> If it was just "a broken lucene" then maybe, but this revealed bugs in
> >> Hotspot itself.
>
> > This doesn't mean anything. There have always been bugs in HotSpot. The
> > point is how relevant they are and how likely they trigger. Sure, they are
> > critical for their consequences; but how likely do they trigger? So far I
> > haven't seen reports by other people, apart from Lucene. In any case, I'd
> > like people to spend at least as much time to *test* their stuff with Java 7
> > as they spend to talk about Java 7 bugs ;-) With Hudson it's relatively
> > simple to add extra jobs. Personally, I've started with my own stuff.
>
> > --
> > Fabrizio Giudici - Java Architect, Project Manager
> > Tidalwave s.a.s. - "We make Java work. Everywhere."
> > java.net/blog/fabriziogiudici -www.tidalwave.it/people
> > Fabrizio.Giud...@tidalwave.it

Fabrizio Giudici

unread,
Aug 4, 2011, 8:44:14 AM8/4/11
to java...@googlegroups.com
On 08/04/2011 01:12 PM, opinali wrote:
> That seems to be purely a bug in Cisco's software, not supporting
> IPv6. This coming from Cisco, the company that's basically synonym
> for network gear... pretty odd.
Just to be clear - that's a typical integration problem of a new
software stack. Java 7 is a new software stack and I expect lots of
integration problems. Including in my code: it already happened when I
moved to Java 5 from 1.4 and 6 from 5. It's pretty normal and it will be
a combination of bugs in Java 7 and the hosting enviroment, but in many
cases they won't be bugs, but things tried for the first time in a
different combination. Until I test my stuff with Java 7 I suppose it
won't work; I expect most of the tests to pass, but a non relevant need
of fixing and patching for the rest.

This is very different from bugs in the core, like in HotSpot.


--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
java.net/blog/fabriziogiudici - www.tidalwave.it/people

Fabrizio...@tidalwave.it

opinali

unread,
Aug 6, 2011, 8:46:12 AM8/6/11
to The Java Posse
Agree, but what you call "integration bugs" is 99% of the time, "old
bugs in app code that are just uncovered by the new runtime". One
example I always remember is: "SimpleTimeZone tz =
(SimpleTimeZone)TimeZone.getTimeZone(...)" - this code, found in
several places in projects where I worked by JDK 1.3's time, was
broken by JDK 1.4; the cause is simple, developers who relied on the
fact that getTimeZone() used to return a SimpleTimeZone - but this was
never guaranteed by the API. Lucene's description of some bug related
to ordering of reflection data is similar, the reflection APIs never
made any promises of ordering and I am surprised that any professional
Java developer who uses reflection in any significant extent ignores
this fact. (This is sometimes one odd effect of relying too much in
testing... you can have a test that succeeds through 10 years and 4
major JDK releases, just because some critical but non-documented
runtime behavior was kept unchanged all that time. TDD is all nice and
cool, but it doesn't replace actually knowing your stuff, or sometimes
reading API documentation.)

Cisco's bug is more in a gray area, because JDK's behavior was changed
(on Vista/Win7 only?) to prefer the IPv6 stack (due the the much-
improved unified stack). But IPv6 support was available since 1.4 (1.5
on Windows); and we're not talking about some random program that
happens to use network stack here and there, we're talking about a
program which core work is networking, and everybody knew about the
upcoming changes in JDK 7's networking, that was a release driver
since the earliest plans.

Now in all fairness, of all companies/groups, who most irritates me
about JDK compatibility bugs is... Oracle; specifically, SQLDeveloper.
I love SQLDeveloper, but it always craps out at any major JDK release.
Now with 1.7 it's once again unusable - remarkably, incremental
loading of rows when visualizing table data is all screwed up. So I
have to keep JDK 1.6 only to run SQLDeveloper. It's irritating
because that's a program from the same company that now provides JDK,
so it looks like an ugly case of left hand not knowing what the right
hand does. It's not a recent bug from the very latest JDK 7 builds; I
noticed the problem months ago, so they just didn't test during the
beta period, or didn't care.

A+
Osvaldo

On Aug 4, 8:44 am, Fabrizio Giudici <fabrizio.giud...@tidalwave.it>
wrote:
> Fabrizio.Giud...@tidalwave.it

opinali

unread,
Aug 6, 2011, 10:02:43 AM8/6/11
to The Java Posse
Neil McAllister brings the discussion to a new low:
https://www.infoworld.com/d/application-development/oracle-javas-worst-enemy-168828

He begins with this remarkable comment - "The Java SE 7 bug itself is
the result of a rookie mistake". That's something impressive to state
about the engineers who implement the HotSpot VM. But let's move
forward.

"What Oracle did do in Java SE 7, however, was to enable the faulty
optimization by default." - yes, exactly how it should be. New
advanced optimizations are often introduced in off-by-default mode,
and they are later turned on after some cooking time; and that's
usually done only in a feature update, not in the old-n-trusty version
like JDK 1.6 now.

Then Neil proceeds with the tired, patronizing advise against
optimizing things. He ignores that these "golden rules" about
premature or unnecessary optimization are only really good for the
higher levels of your stack; not for the lower levels like OS kernels,
drivers, or core libraries and compilers / language runtimes. The
reason we can afford to write simple, elegant Java code that's not
twisted by hand-tuning and still run it with decent speed, is that
EVERYTHING below our code is heavily optimized. And if it was not:
pundits would write blogs stoning Oracle for making Java more bloated
and sluggish than those from good ol' Sun. (Sometimes you need new
optimizations just to keep the previous performance level,
compensating for the weight of new features - in 1.7 I'm sure this
applies for example to invokedynamic support.) Major JVM updates MUST
be always pushing the envelope of performance, by making new
optimizations not only available but also active by default. Non-
default opts are only ever exercised by a minuscule number of advanced
users, and some things never really mature if you don't take the
opportunity of major releases to turn them on by default. There's some
risk in doing that; but there's some risk in anything, including every
single of the hundreds of new features you get in a major update of
the platform - most of these features are NOT full-new APIs that are
implemented in isolation and have no risk of causing regression in any
preexisting functionality.

"And yet it shipped anyway because five days wasn't enough time to fix
the problem." - really? Let's say Oracle delayed the release by a few
days, maybe a full month if the fix needs to touch a critical piece of
the optimizer and would require significant field testing. Then a new
release date approaches, and five days before that date, some other
group or company tests their very popular product for the first time
on JDK 7 and finds another important bug. What do we do, wait forever
until no more P1 bugs exist? Even though these bugs will affect a very
small number of apps, AND they are trivially avoided by a command-line
flag? And the bugs only affect HotSpot Server, which is NOT
automatically updated in any platform where Java updates are managed
by Oracle? Seriously...

But the most annoying thing in the article is the take-home message,
that Oracle is "Java's worst enemy". Reality check for Oracle haters:
they're better in the QA dept than Sun ever was. People's memory is
short, but this is not a problem because the Web remembers; check this
for example:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6512534

This is a bug from the JDK 6 FCS release (fixed in 6u1). It's the same
kind of bug - the JIT compiler silently generates bad code that
produces wrong results, the app keeps working happily with risk of
corrupting user data and business behavior. Except that it hits much
more people than JDK 7's bug, because it's a C1 bug (HotSpot Client).
Not to mention API regressions that are often just as bad when they
happen in popular APIs like JDBC, Regression, Collections etc. Every
single JDK major update's FCS build had its fair share of "the sky is
falling" regressions. Nothing to see here, except the fact that Oracle
have been very competent moving forward major Java projects - JDK,
Glassfish, even JavaFX - so people who have a strong bias against
Oracle (or against Java) need to make a storm-in-a-teacup out of the
few major mishaps.

A+
Osvaldo

Casper Bang

unread,
Aug 7, 2011, 10:30:54 AM8/7/11
to The Java Posse
> 7. That this bug is specific to HotSpot Server. It doesn't exist in
> HotSpot Client (which doesn't even have the loop optimization that is
> buggy...).  So the JRE, which only includes the Client VM, is safe.
> All desktop apps (ok... dev apps like Eclipse/NB etc.) are safe.

Well you are forgetting that the Client VM is used much less than the
Server VM. Since Java 1.5, 64bit server-class machines default to
using the Server VM. Indeed, if you're running the JRE on a 64bit
Linux box, you haven't even had the Client VM at your disposal for a
good number of years now!

opinali

unread,
Aug 7, 2011, 12:47:54 PM8/7/11
to The Java Posse
Oh I always forget the five guys who use Ubuntu instead of Windows or
OSX to run desktop software :) Sorry, HotSpot Client is STILL much
more used than Server for desktop apps. Win7 still defaults to 32-bit
MSIE, part due to plugins and corporate ActiveX legacy, part because
64-bit IE itself is not yet complete (no Javascript JIT; 64-bit IE
runs JS in pure interpreter). Other popular Windows browsers, Firefox
and Chrome, still need to deliver a supported Win64 port. The "server-
class" default is only relevant for the JDK which has both VMs, and
it's not used at all in the Windows platform where Client is always
the default no matter how much hardware you have.

But even if you disagree with all of the above - we're talking about a
bug from JDK 6 FCS, released back in December 2006! By that time, 64-
bit desktops were nowhere to be seen... Windows users were still on XP
which 64-bit edition was basically unusable for desktop users; OSX was
still in the original Leopard (just as bad as XP of 64-bit if not
worse), 64-bit browsers nowhere to be seen, etc. So, the bug I
mention below would affect virtually 100% of client-side Java apps.

A+
Osvaldo

Casper Bang

unread,
Aug 8, 2011, 2:48:42 AM8/8/11
to The Java Posse
On Aug 7, 6:47 pm, opinali <opin...@gmail.com> wrote:
> Oh I always forget the five guys who use Ubuntu instead of Windows or
> OSX to run desktop software :)  Sorry, HotSpot Client is STILL much
> more used than Server for desktop apps.  Win7 still defaults to 32-bit
> MSIE, part due to plugins and corporate ActiveX legacy, part because
> 64-bit IE itself is not yet complete (no Javascript JIT; 64-bit IE
> runs JS in pure interpreter). Other popular Windows browsers, Firefox
> and Chrome, still need to deliver a supported Win64 port. The "server-
> class" default is only relevant for the JDK which has both VMs, and
> it's not used at all in the Windows platform where Client is always
> the default no matter how much hardware you have.

Never the less, this is what I see when I inspect the console output
when launching a Web Start application within Windows Vista and
Windows7 (vmware):
Using JRE version 1.6.0_23-b05 Java HotSpot(TM) 64-Bit Server VM

Casper Bang

unread,
Aug 8, 2011, 10:41:25 AM8/8/11
to The Java Posse
Just tested a friends MacBook, also defaults to 64bit Server JVM. So
it really looks to me as if Server is the norm.

ags

unread,
Aug 8, 2011, 1:21:00 PM8/8/11
to java...@googlegroups.com

Isn't that governed by ergonomics?

On Aug 8, 2011 4:41 PM, "Casper Bang" <caspe...@gmail.com> wrote:
> Just tested a friends MacBook, also defaults to 64bit Server JVM. So
> it really looks to me as if Server is the norm.
>

Reinier Zwitserloot

unread,
Aug 9, 2011, 9:43:35 AM8/9/11
to java...@googlegroups.com
ergonomics is the study of how you should sit on a chair in order to reduce things like RSI. Not sure that's what you meant.

David Schlosnagle

unread,
Aug 9, 2011, 9:57:08 AM8/9/11
to java...@googlegroups.com

I believe that is "ergonomics" in reference to "HotSpot is an
"ergonomic" JVM. Based upon the platform configuration, it will select
a compiler, Java heap configuration, and garbage collector that
produce good to excellent performance for most applications." [1].
HotSpot attempts to automatically select the server VM for
"server-class" machines -- "For Java SE 6, the definition of a
server-class machine is one with at least 2 CPUs and at least 2GB of
physical memory." [2].

[1]: http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136373.html
[2]: http://download.oracle.com/javase/7/docs/technotes/guides/vm/server-class.html

- Dave

Russel Winder

unread,
Aug 9, 2011, 12:43:08 PM8/9/11
to java...@googlegroups.com
On Tue, 2011-08-09 at 06:43 -0700, Reinier Zwitserloot wrote:
> ergonomics is the study of how you should sit on a chair in order to
> reduce things like RSI. Not sure that's what you meant.

That is just one small aspect of physical ergonomics. Ergonmics is a
huge field -- hence flagging that the above characterization is somewhat
inappropriate as a general characterization of the term used.

http://www.ergonomics.org.uk/what-ergonomics

--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel...@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder

signature.asc

Casper Bang

unread,
Aug 9, 2011, 4:38:00 PM8/9/11
to The Java Posse
> "For Java SE 6, the definition of a
> server-class machine is one with at least 2 CPUs and at least 2GB of
> physical memory." [2].

Exactly. Sun's old definition of a server class machine is now nothing
out of the ordinary. Hell, we'll see cell phones and tablets shipping
this year with specs like that! I would not be surprised to see the
client profile go away completely on all platforms (just as has
happened with 64bit JRE's). So Osvaldo, I don't know why you say
"HotSpot Client is STILL much more used than Server", empirical
evidence suggests otherwise.

Casper Bang

unread,
Aug 9, 2011, 4:46:53 PM8/9/11
to The Java Posse
> Now with 1.7 it's once again unusable - remarkably, incremental
> loading of rows when visualizing table data is all screwed up. So I
> have to keep JDK 1.6 only to run SQLDeveloper.  It's irritating
> because that's a program from the same company that now provides JDK,
> so it looks like an ugly case of left hand not knowing what the right
> hand does. It's not a recent bug from the very latest JDK 7 builds; I
> noticed the problem months ago, so they just didn't test during the
> beta period, or didn't care.

It's interesting that SQLDeveloper always does version checking and
warns users of potential problems, it kind of says something about the
developers lack of trust in binary backwards compatibility of the Java
platform. However, what REALLY bothers me about SQLDeveloper, is how
it always freezes when you loose a connection over VPN, or just keep
it open for more than an hour or so.

Jess Holle

unread,
Aug 9, 2011, 5:03:39 PM8/9/11
to java...@googlegroups.com, Casper Bang
Or that if you click on the wrong thing (the dreaded "Data" tab), you'll
get an OutOfMemoryError as it tries to bring the entirety of the data
table into memory -- without regard for how big the table is or how
little memory you have...

--
Jess Holle

Graham Allan

unread,
Aug 9, 2011, 6:04:56 PM8/9/11
to java...@googlegroups.com
Or that if you click on the wrong thing (the dreaded "Data" tab), you'll get an OutOfMemoryError as it tries to bring the entirety of the data table into memory -- without regard for how big the table is or how little memory you have...

--
Jess Holle


Really? I don't have an installation locally, but I seem to remember that the Data tab lazily fetched rows when you scrolled down over the results, in batches of 50. Perhaps this is a newer feature, or hidden away in an option? May be worth checking out.

Kind regards,
Graham

opinali

unread,
Aug 9, 2011, 9:31:09 PM8/9/11
to java...@googlegroups.com
On Tuesday, August 9, 2011 4:46:53 PM UTC-4, Casper Bang wrote:
It's interesting that SQLDeveloper always does version checking and
warns users of potential problems, it kind of says something about the
developers lack of trust in binary backwards compatibility of the Java

No, this only says something about the developer's lack of confidence about their own code's portability/compatibility. We're not in the JDK 1.2->1.3 times anymore; backwards compatibility of new Java versions has been exceptionally good as a rule, for a longtime. Of course not perfect, some regressions happen, but I'd say that java's current track record is the best of any major platform - your favorite desktop or mobile operating system, browser, desktop environment, Flash player etc., typically breaks more applications at each major release than any recent major release of Java. At least that's my experience as an early adopter.  There are tons of software much bigger than SQLDeveloper that routinely transition to major JDK updates without a hitch.

The real problem, most likely, is that SQLDeveloper is not a pure-Java app, they have a bunch of DLLs - not just launcher stuff but things like idenative.dll and jdevnative.dll.  In the Oracle forum, they suggested to copy JDK 7's bundled msvcr100.dll to improve compatibility with JDK 7. I've tried that, no improvement at all; but that recommendation is a huge smoking gun.  The problem is that they have some crappy native dependencies that they inherit from JDeveloper frameworks.

A+
Osvaldo

opinali

unread,
Aug 9, 2011, 9:51:58 PM8/9/11
to java...@googlegroups.com
On Tuesday, August 9, 2011 4:38:00 PM UTC-4, Casper Bang wrote:
> "For Java SE 6, the definition of a
> server-class machine is one with at least 2 CPUs and at least 2GB of
> physical memory." [2].
Exactly. Sun's old definition of a server class machine is now nothing
out of the ordinary. Hell, we'll see cell phones and tablets shipping

Once again, the server-class rule doesn't exist at all for the Windows platform. On Windows, -client is ALWAYS the default. Still I don't see how this is relevant in the 32/64-bit discussion (ergonomics won't pick "bitness" anywhere).
 
this year with specs like that! I would not be surprised to see the
client profile go away completely on all platforms (just as has
happened with 64bit JRE's). So Osvaldo, I don't know why you say
"HotSpot Client is STILL much more used than Server", empirical
evidence suggests otherwise.

Which evidence, care to show any? I don't have any stats either, but at least I have logic on my side: 32-bit browsers are much more used than 64-bit ones; and the 64-bit JRE has only very recently evolved to anything that is usable (6u2x releases). As for Java desktop apps that bundle their own JRE, the option for the 64-bit JRE is extremely rare, in fact SQLDeveloper is the single example that I know that has a Win64 bundle.  Oh, you can try to lurk at places like javagaming.org, where people are often whining about optimizations that only Server has and Client doesn't.

I too believe that Client, and also 32-bit, is on the way out, but that's because of bleeding-edge improvements like the tiered compiler (JDK 7's), CompressedOops and CompressedStrings. Even with all this trickery, the 64-bit Server (or tiered Client+Server) VM will still use significantly more memory than ol' good 32-bit Client VM. People still judge things like Java vs. Flash or Chrome vs. Firefox counting the megabytes that each uses more than the other - we are still distant from the day when a platform that burns 100Mb more than another competing platform to run a similar app, is not disadvantaged.
 
A+
Osvaldo

Casper Bang

unread,
Aug 10, 2011, 3:14:26 AM8/10/11
to The Java Posse
>  There are tons of software
> much bigger than SQLDeveloper that routinely transition to major JDK updates
> without a hitch.

As far as exercising client API's (i.e. Swing), I don't think there
are "tons of software" much bigger. IDE's seems to be the single most
successful class of Java client applications out there. But I may be
tainted, having seen my share of Oracle software break on newer Java
releases (Oracle Discoverer bitching for years over Java 6 also comes
to mind!).

> The real problem, most likely, is that SQLDeveloper is not a pure-Java app,
> they have a bunch of DLLs - not just launcher stuff but things like
> idenative.dll and jdevnative.dll.  In the Oracle forum, they suggested to
> copy JDK 7's bundled msvcr100.dll to improve compatibility with JDK 7. I've
> tried that, no improvement at all; but that recommendation is a huge smoking
> gun.  The problem is that they have some crappy native dependencies that
> they inherit from JDeveloper frameworks.

Ah I doubt if MFC and Visual C++ redistributable dll's are relevant to
my Linux installation of SQLDeveloper. That does raise an interesting
point however, that Java's search for the lowest common denominator
for client applications, can be a tough goal to meet. For example,
there's no System.restart() API so even NetBeans (which we must assume
is written by people who truly know how to do things) ships with
native wrappers.

> I too believe that Client, and also 32-bit, is on the way out, but that's
> because of bleeding-edge improvements like the tiered compiler (JDK 7's),
> CompressedOops and CompressedStrings. Even with all this trickery, the
> 64-bit Server (or tiered Client+Server) VM will still use significantly more
> memory than ol' good 32-bit Client VM. People still judge things like Java
> vs. Flash or Chrome vs. Firefox counting the megabytes that each uses more
> than the other - we are still distant from the day when a platform that
> burns 100Mb more than another competing platform to run a similar app, is
> not disadvantaged.

There's no reason (that I can tell) for why there should be two
distinct VM's, just make one that's adaptive and less black-n-white.
That a 32bit VM uses less memory I suppose is primarily a consequence
of pointers being ½ the size of 64bit, yet Moore's law will remedy
this in less than a year. I actually just don't think Java was ever
really optimized for client computing (for one thing, why not just
cache the verified, compiled and optimized native code first time it's
executed?) unlike i.e. Android and .NET.

Ricky Clarkson

unread,
Aug 10, 2011, 7:16:55 PM8/10/11
to java...@googlegroups.com
>>  There are tons of software
>> much bigger than SQLDeveloper that routinely transition to major JDK updates
>> without a hitch.
>
> As far as exercising client API's (i.e. Swing), I don't think there
> are "tons of software" much bigger.

Lotus Notes.

Vince O'Sullivan

unread,
Aug 11, 2011, 7:02:17 AM8/11/11
to The Java Posse
> Lotus Notes.

Possibly one of the ugliest and least Windows compliant Windows
applications on the market.

Ricky Clarkson

unread,
Aug 11, 2011, 7:07:35 AM8/11/11
to java...@googlegroups.com
Is that true since the rewrite into Java? I haven't seen it running
since before that.

And did they still make it Windows-only when they rewrote it?

opinali

unread,
Aug 11, 2011, 7:24:40 AM8/11/11
to java...@googlegroups.com
On Wednesday, August 10, 2011 3:14:26 AM UTC-4, Casper Bang wrote:
>  There are tons of software
> much bigger than SQLDeveloper that routinely transition to major JDK updates
> without a hitch.
As far as exercising client API's (i.e. Swing), I don't think there
are "tons of software" much bigger. IDE's seems to be the single most
successful class of Java client applications out there. But I may be
tainted, having seen my share of Oracle software break on newer Java
releases (Oracle Discoverer bitching for years over Java 6 also comes
to mind!).

Oracle's Java apps have traditionally been "pollutted" with native extensions and Oracle-internal, low-level frameworks. I remember that some years ago many Oracle Java apps used the EWT (a windowing toolkit that much like SWT, planned to replace AWT/Swing, but unlike SWT they never walked the last mile to promote it more broadly and make it mature).
 
Ah I doubt if MFC and Visual C++ redistributable dll's are relevant to
my Linux installation of SQLDeveloper. That does raise an interesting

I guess on Linux it has/uses equivalent native libs... but even without that, you have have lots of (your fault's) unportable hacks.
 
point however, that Java's search for the lowest common denominator
for client applications, can be a tough goal to meet. For example,
there's no System.restart() API so even NetBeans (which we must assume
is written by people who truly know how to do things) ships with
native wrappers.

This functionality can be provided by shell scripts; native launchers still have some advantages (remarkably on Windows), but the native code from SQLDeveloper goes much beyond launcher wrappers (it has those, too).
 
There's no reason (that I can tell) for why there should be two
distinct VM's, just make one that's adaptive and less black-n-white.

I can hear tens of HotSpot developers thinking "yeah, like that would be very easy and not have tons of tradeoffs" ;-) this stuff is hard, for one thing HotSpot Client and Server used to have very different LIR/HIR, calling conventions and many other structural diffs; only now with the Tiered work they became compatible enough to run side by side... but it's still a combo JIT, not a single JIT that can operate in "-O1" or "-O2" mode... let's see
 
That a 32bit VM uses less memory I suppose is primarily a consequence
of pointers being ½ the size of 64bit, yet Moore's law will remedy

CompressedOops now mostly avoids this problem, at least for Java objects in the heap; but (I think) not for code, stack, native heap, VM-internal structures, OS resources. Maybe the major delta is that we'd need a very mature port of the 64-bit HotSpot Client VM, so this can still improve.
 
this in less than a year. I actually just don't think Java was ever
really optimized for client computing (for one thing, why not just
cache the verified, compiled and optimized native code first time it's
executed?) unlike i.e. Android and .NET.

Static and shareable IT-caching requires to drop many agressive dynamic optimizations, so this enters a different discussion. Both .NET and Android are less advanced in the dynamic features than JavaSE, and HotSpot - often even Client - beats .NET's pants down in most benchmarks (well, except ones that depend a lot on extra typesystem things, like lightweight structs for complex numbers and such).  But I always thought that for Client, the tradeoff would make sense... at least if Java's frameworks are not too over-engineered to rely a lot on advanced optimizations (like Swing is).

A+
Osvaldo
Reply all
Reply to author
Forward
0 new messages