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
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
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
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
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
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
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?
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
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
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.
>
-- Ryan
ps. OpenJDK documentation seems to agree:
http://openjdk.java.net/guide/changePlanning.html#bug
--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
java.net/blog/fabriziogiudici - www.tidalwave.it/people
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
Isn't that governed by ergonomics?
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
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
--
Jess Holle
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
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
> "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.
Lotus Notes.
And did they still make it Windows-only when they rewrote it?
> 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!).
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.
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.