Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Java Bug Apache

Java 7 Ships With Severe Bug 180

Lisandro writes "Lucid Imagination just posted an announcement about a severe bug in the recently released Java 7. Apparently some loops are mis-compiled due to errors in the HotSpot compiler optimizations, which causes programs to fail. This bug affects several Apache projects directly — Apache Lucene Core and Apache Solr have already raised a warning, noting that the bug might be present in Java 6 as well."
This discussion has been archived. No new comments can be posted.

Java 7 Ships With Severe Bug

Comments Filter:
  • by Nadaka ( 224565 ) on Friday July 29, 2011 @01:19PM (#36923698)

    So well known for product "quality"

    • Yeah because the numerous bugs and security vulnerabilities in the Sun version of the JVM was such great "quality" in itself, right?

      • by Tridus ( 79566 ) on Friday July 29, 2011 @01:31PM (#36923942) Homepage

        Can you name an instance where Sun knew the thing miscompiled loops before release and put it out anyway with no warning to users about the error?

        I can't. Sun got stuff wrong sometimes, but this is an incredible level of actively poor judgement from Oracle. Anybody sane would have delayed this release.

        • I know it's unfashionable to RTFA, but this quote might help:

          Also Java 6 users are affected, if they use one of those JVM options, which are not enabled by default: -XX:+OptimizeStringConcat or -XX:+AggressiveOpts.

          Emphasis in the original. So it looks more like Oracle turned on more aggressive optimizations by default. And if it's such an obvious bug, one would think it would have turned up in the last 29 version 6 releases?

          • by dgatwood ( 11270 ) on Friday July 29, 2011 @02:09PM (#36924576) Homepage Journal

            And if it's such an obvious bug, one would think it would have turned up in the last 29 version 6 releases?

            No, honestly. This wasn't caught before because nobody used those flags. Oracle decided that these flags should be turned on by default. Therefore, the onus was on Oracle to thoroughly and broadly test these flags before promoting them to be used by default.

            I guarantee you'll find some hairy bugs if you enable lots of random, rarely enabled flags in just about any compiler. The difference between a good compiler and a bad compiler is that a good compiler tests flags thoroughly before either enabling any the flags by default or rolling them into a commonly used option. In effect, what Oracle did was to take an obscure, poorly tested code path and promote it into the hot path through their code. This is something that any first-year CS student should know is risky.

            The best part of this is that (assuming other Slashdot comments are correct) this occurs in commonly used third-party libraries, and was disclosed to Oracle several days before the release shipped. Where I work, that's what is known as a P1 block-ship bug, and people will be called in to work on it day and night until the problem is resolved, and if necessary, features will get temporarily pulled (e.g. turning that optimization back off by default).

            For shame, Oracle.

            • by jensend ( 71114 )

              Nobody used aggressive optimizations? You're off your rocker. I think that's one of the first tweaks people go to when they're trying to tune Java performance. Yes, it wasn't used by the majority of people, but it would have been excusable to think that these options had seen enough testing from those enabling the option to catch any obvious bugs.

              • Nobody used aggressive optimizations? You're off your rocker. I think that's one of the first tweaks people go to when they're trying to tune Java performance. Yes, it wasn't used by the majority of people, but it would have been excusable to think that these options had seen enough testing from those enabling the option to catch any obvious bugs.

                Obviously "nobody" is a sweeping generalization, but if someone is tuning Java performance, and it breaks when a particular switch is turned on, the switch is just going to be left off from then on. Maybe they'll turn revert a few other previously changed options, but unless it stops being broken as a result...

              • by aled ( 228417 )
                IMHO people that try to buy performance by turning on aggressive or little documented options like to play with fire. Profile your own code first and you'll get there faster and safer. No compiler trick will correct bad code.
            • by Amouth ( 879122 )

              exactly - and to top it off according to Apache.. Oracle has put the fix in a timeline to be released on Java 7 update 2.. so something that should never have gone out the door isn't going to be fixed for this or the next update.. that's just stupid.

            • by blair1q ( 305137 )

              You'll find bugs in software every time you change software. Hopefully in alpha and regression testing. Or in Beta testing, if you do it old-school and dogfood it instead of pretending that the first release to the public is Beta testing, or just skip it altogether.

            • by Svartalf ( 2997 )

              Heh... Yeah, we have one of those severity levels in the tracking system too. Simply put, this shows you just what Oracle thinks about "quality", more than anything else.

            • In effect, what Oracle did was to take an obscure, poorly tested code path and promote it into the hot path through their code. This is something that any first-year CS student should know is risky.

              Excessive hyperbole is a good way of making an otherwise sound argument sound silly.

              I remember when I was a Computing Science first-year student (18+ in my country, but 17+ in the educational system I went to university in). Compiler options beyond input and output files names were not on the agenda. "This is se

              • by dgatwood ( 11270 )

                Do computing science students these days get so close to particular languages that they actually even know what compiler flags are about?

                I hope not. But they should have it drilled into their heads from day one that code has bugs, and you have to test code before you submit it to the teacher. If you decide to include that chunk of code that hasn't been tested when you turn it in to your teacher, you're risking getting a bad grade.

                This is essentially what Oracle did when they enabled by default an option

                • OK, from that aspect, yes, I see where you're coming from.

                  TBH though, as I get longer and longer in the tooth, I'm finding that I get more and more cautious about validating input. I see that the actual programmers in the sand pit do too, as the version number of our package edges upwards.

          • Obviousness is irrelevant if the part of the article that says:

            """These problems were detected only 5 days before the official Java 7 release, so Oracle had no time to fix those bugs,"""

            is accurate then Oracle are way past poor judgement.

            You have a bug in your compiler/jvm/whatever which will cause some programs to crash and others to give the wrong output.Do you:

            1. Release it anyway and hope no one notices.
            2. Release it anyway and warn people about it.
            3. Delay the release until it is fixed.
            4. Disable that,

            • by Svartalf ( 2997 )

              You should do 3 or 4, documenting things in the case of '4'. 1's not acceptable as is 2, really, when you get to brass tacks.

          • by Svartalf ( 2997 )

            Ah, but the problem is...Oracle knew about a week before release that this was going on- and did and said nothing about it and shipped it with that problem. Sorry, they're not getting an out just because it was the previous version where it wasn't the default behavior.

            • by DamonHD ( 794830 )

              Remarkable amount of spittle flying in this thread...

              I expect most major technical artefacts from javac to SUVs to space ships go out the door with known defects; heck I worked on a major defence project where the ship had to ship without most of its code, with the significant risk of killing innocent passers-by. And 5 days may simply not be enough time to repackage everything for a bug that's going to affect very few people. (Except possibly some loud ones with an axe to grind?)

              In fact, back in C/C++ lan

          • by sjames ( 1099 ) on Friday July 29, 2011 @04:31PM (#36926648) Homepage Journal

            It's quite common for more aggressive optimization flags on any compiler to come with warnings that things may break in odd ways. It's even considered acceptable as long as those flags default to off.

            It is NOT acceptable to set them on by default in that condition. At no point did Sun violate that, but Oracle just did.

        • Did you miss the part from the article that this was a bug in the JVM since well before Oracle even took over? Oh right, you probably didn't. Who cares about pesky facts when we can bash Oracle instead.

          • It was an Oracle product when they turned on the optimize flags that revealed the bug, were notified of the bug, and decided to ship with the flags on anyway.

            If it had been Sun they would have delayed the release, because Java was Sun's poster product. Oracle has either canned or driven away so much talent that they probably have no clue what Java is at this point.

          • by Svartalf ( 2997 )

            Did you miss that it doesn't matter that they had it in the JVM before they took over. They turned it on as a default behavior for the release, didn't check that it broke anything, and then shipped it anyway when they found it out 5 days before the ship date .

            No company that cares about quality would've EVER done things like this. Seriously. It's called delay ship or back out the default behavior and document the problem with the optimization flag. They knew within enough time to fix it enough to ship w

        • "Anybody sane would have delayed this release."

          The last major version of Java came out in December 2006. If that's not enough of a delay, I don't know what is.

          • by Svartalf ( 2997 )

            Uh, that's not the point and if you're being honest, you know that to be the case. This is a "showstopper" bug where most other places would've delayed the release a bit further (yes...in addition to the "delay" you refer to...) or back that change out. Seriously.

          • by Pieroxy ( 222434 )

            Either you're joking, or you just have no idea what you're talking about.

    • Sounds all too familiar.

      Just finished a project where several workarounds were needed because a well-known bug in Oracle's own damn JDBC driver hasn't been fixed in over three years.

      • by Nadaka ( 224565 )

        Yea... Their most recent JDBC driver is also significantly slower than the previous version and contains a boolean conversion error.

    • So well known for product "quality"

      I once had a heck of a time installing an Oracle product for a client. I finally figure out that the install script had a developer's home directory hard-coded into it. When I googled this path, I found an Oracle messageboard thread that had started almost three years earlier on the problem.

      I had downloaded the package from Oracle that day.

    • by NateTech ( 50881 )

      Name a single large software package that hasn't had at least one major serious screw-up like this in the last few years. The industry's retarded to keep allowing code to be handled as if it weren't real engineering with building codes, inspectors, etc.

  • by kotku ( 249450 ) on Friday July 29, 2011 @01:21PM (#36923734) Journal

    Or is it only a desktop problem?

    • Troll fail.

      Try again next time.

      • He was a fail troll yet got multiple people to fall for it? It's amazing how easy it is for people like the GP to continue to bait people with such obvious trolling.

  • by Tridus ( 79566 ) on Friday July 29, 2011 @01:28PM (#36923886) Homepage

    Relevant part:

    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 [6]).
    This means you cannot use Apache 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 option to not risk index corruptions.

    If this was known before the release and it's as severe as it's being made out to be, why the hell didn't they postpone the release? It's not like the world is dependent on Java 7 being released on time.

    This isn't a little issue, either. It's extremely irresponsible for Oracle to put this kind of release out knowing of a bug this severe without any kind of warning on it.

    • There's a manager at Oracle who would have lost his quarterly bonus if 7 didn't ship on time, you wouldn't have wanted him to do that, would you?

      • by Tridus ( 79566 )

        Yeah that's probably the answer. Some suit somewhere decided on a release date and minor details like the product not working won't deter it.

        • Well, you wouldn't want them to have to deal with all the "Oracle misses ship date" headlines, would you? Some corner-case bug is only going to be reported in the tech media, not in the Wall Street Journal.
          • This ain't no "corner case" . These guys enabled broken optimizations that break loops, knowingly... in a production release. I completely agree with the parent poster, this is way irresponsible of Oracle. It's akin to releasing a new car model where the steering wheel doesn't work properly.

            • Yeah, well, ok, but how many programs use these "loop" thingies? Right? You can code around them. Just do something else. I hear "recursion" is a good workaround. Amiright?

              Good car analogy, btw, but I think it's more like the steering working just fine unless you want to turn. Then it snap-oversteers across the sidewalk and into the side of a building. Just keep steering straight and there'll be no problem. A steering system which permits turning, curving, or lane-changing is schedule for Q4 2011 or Q1 2012

          • They could just turn off those two switches. But hey, this is Oracle. Everything they touch turns into crap.
    • by ardle ( 523599 )
      Would you go as far as to say "culpably" irresponsible? Would some kind of lawsuit help, or are Oracle too big for the law?
      • Would you go as far as to say "culpably" irresponsible? Would some kind of lawsuit help, or are Oracle too big for the law?

        I believe they are willing to refund the entire purchase price for the compiler.

      • by Pieroxy ( 222434 )

        Shitty products are not a crime.

        • by dkf ( 304284 )

          Shitty products are not a crime.

          They can be, but I wouldn't think that Java would be one of the cases where that is so. When dealing with programming tools, you're supposed to be careful. The licenses all say it, and for good reason. It's the user of those tools, the programmer (or deployer in some cases), who warrants that the produced piece of software is actually useful.

    • by jensend ( 71114 )

      I don't see any sign that this is affecting many users other than the two Apache projects noted. The linked article says that the best case with the loop optimizations is a crash and worst case is incorrect behavior- but they're conveniently not mentioning how likely it is that your code would trigger this bug. I see no signs that the "Donâ(TM)t use Java 7 for anything" conclusion is anything other than totally overblown.

      The fact that the bug is also present in Java 6 if you enable the (fairly common)

      • Yeah because applications out there are magic, they read the release notes for each java release and they automatically use the correct command line switches for each of the different versions of java.

        • No, but if you're a sysadmin you should read release notes before making major upgrades. Not too many end-users out there using Lucene or Solr. It's also not like Sun has pushed Java 7 to end users through Java Update either (I imagine it will be quite some time before they do that).

          So only the dedicated early adopters who replace what all their enterprise search software is running on with a brand-new release branch immediately after its release without reading the release notes would be affected.

      • by tixxit ( 1107127 )
        While Solr (& Lucene) are only a couple pieces of software, they also happen to be damn useful and widely deployed pieces of software. Pretty much every web site we make uses Solr to handle searching, so this problem is ours now too. Not that we'd put Java 7 in production on the first release anyways, but it certainly doesn't make me think highly of Oracle, since, as you noted, they didn't even bother to mention this bug in the release notes.
    • why the hell didn't they postpone the release?

      You know the open source motto: Never show weakness to your enemies. Oh, no, wait, that's not how it works.

    • by sjames ( 1099 )

      Not to mention, they were unable to change the defaults on a couple of options back to off in a few days time?

  • by Anonymous Coward on Friday July 29, 2011 @01:28PM (#36923888)

    Damn those bugs where known but Oracle choose to ship Java 7, knowing that it would crash on some very known and used Apache libraries. (And most likely other code too).

    To quote:
    "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. "

    Here is a hint to Oracle: If you find a fatal bug 5 days before launch and don't have time to fix it, you either disable the specific optimization with the know bug, or you postpone the launch and start working on a fix. Just shipping like this is stupid.

    • by rossjudson ( 97786 ) on Friday July 29, 2011 @02:32PM (#36925000) Homepage

      Another way of looking at this is to realize that the pre-release versions of Java 7 have been out there for a long, long time, and nobody from these Apache projects felt like testing their (rather important) open source projects against it, so they could have found and reported the bug earlier.

      It seems to me that fault lies in both directions here.

      A more correct rewrite of the bug teaser would be, "Don't use Java 7 for anything if you are incapable of passing an extra command line argument to it".

      • by gr8_phk ( 621180 )

        Another way of looking at this is to realize that the pre-release versions of Java 7 have been out there for a long, long time, and nobody from these Apache projects felt like testing their (rather important) open source projects against it, so they could have found and reported the bug earlier.

        Umm no. It's not the customers fault for not testing the product. It's Oracles fault. In fact, Oracle could have been using Apache in their test suite - it's not like it's a closed source product. This really raises

    • Agreed. If the release was too close to cancel, then it should have already been released.

      Otherwise, they should have disabled the optimization and put it into the release notes, thus avoiding the issue (as, apparently, using the optimizations in Java 6's HotSpot also caused the same problem) until they had time to resolve it.

    • by blair1q ( 305137 )

      How is 5 days "no time"?

      Just how dumb are the people who write Java?

    • by sjames ( 1099 )

      They apparently also had no time to add a big fat warning to the release. I'm thinking the old skull and crossbones + Mr. Yuk would have done it.

  • by JoeMerchant ( 803320 ) on Friday July 29, 2011 @01:30PM (#36923916)

    And I was only avoiding updating it because the last time our PCs were clamoring for Java updates it was actually a (well disguised) trojan.

    The next thing Windows needs to add is a "don't bother me with this update" API where software vendors need to ask the OS permission before prompting the user for updates - and also allow preference settings like "don't install a damn desktop launch icon when you update" (looking at you Adobe.) Personally, I'd set my preferences to "don't tell me about updates until they are at least a month old." There is a balance to strike between getting the latest patches for security and waiting until a patch has proven itself in the wild.

    Of course, we could all just stop using software from vendors who don't do these things voluntarily (like check for bugs before pushing an update, or making an easy to access preference for launch icon settings (hint: if I've deleted the last 12 of them, I likely don't want the 13th!) but the software that I'm talking about here is Java and Acrobat - kind of hard to get around the web without those.

    • by mark-t ( 151149 )

      When you see a popup alerting you to an update for software you actually have installed being available, the best thing to do is go directly to the company's website and update from there...

      I learned a long time ago to never trust *ANY* popups.. regardless of what they appear to be from.

      • by sjames ( 1099 )

        Actually, the best thing is to wait a few days and watch relevant forums for people ripping their hair out about how the update killed their productivity (or PC) dead with nasty bugs.

    • Perhaps a bit off-topic, but relevant to the OP...

      In Linux everything I need comes from one or more trusted software repositories, and all of the updates are performed through the same tool in the same way, so I do not need to familiarize myself with the different update systems for different pieces of software.

      In iOS everything is downloaded and installed through the app store, updates are similarly pushed through a single (presumably trusted) source. Same with Android and the various marketplaces and pre

  • by ThatsNotPudding ( 1045640 ) on Friday July 29, 2011 @01:35PM (#36923994)
    over the seabreeze whipping past his yacht (not that he'd give a fsck about you, anyway).
  • by roc97007 ( 608802 ) on Friday July 29, 2011 @02:16PM (#36924706) Journal

    > This bug affects several Apache projects directly — Apache Lucene Core

    So... from Oracle's standpoint, it's a feature?

    • Eerie. I thought I heard someone chanting something over by Redwood City. It sounded like "Java's ain't done til Apache won't run!"
  • And unfortunately it infects many, many computers.

    Can anybody honestly tell me why people still develop in Java? It's nothing but a gigantic pain in the ass. And why does each new version of the JVM break programs written for previous versions? Is there no backwards compatibility at all??

    • Please, can you name a programming language/compiler that's more backwards compatible?

      • by Ant P. ( 974313 )

        sh, Perl 5, Lisp, Javascript, everything IBM produces, ...

      • gcc

      • Are you serious? I think Java is the only modern language i can think of that forces you to be careful when updating versions. Or porting to different platforms - hell, Perl and Python are, in many ways, much more stable and portable than Java.

        • IIRC java 6 is bytecode compatible with java 1.1, but correct me if I'm wrong. Citing Python seems weird, as the Python 3.x breaks nearly all 2.x libraries.

          • Python recompiles files to .pyc bytecode dynamically, so you don't even have to care about it. I haven't had any issues migrating code from 2.x to 3.x.

    • by DamonHD ( 794830 )

      Nonsense. I have Java code that I knocked out for Netscape 2 that basically still runs happily in current browsers, and is non-trivial.

      And I fold that same code into a current Java application, and optimise across the old and new with Progard.

      Couldn't really do that with (say) C or C++, and I've been paid shedloads to port them over the years.

      The only other language that I know and use with the practical backward compatibility of Java (ie stuff more than an decade old runs perfectly surviving many OS chang

      • by djp928 ( 516044 )

        Well, then explain to me why every place I've ever worked I've had to maintain several different versions of Java on most servers/desktops because certain apps refuse to work correctly with the most recent version and require an older version? Hell, many apps now go as far as to just install their own version of Java somewhere to get around the fact that their shit probably won't work with whatever version you have have installed.

        Currently where I work our time and attendance software (from a major vendor)

        • by bongey ( 974911 )
          Most likely it one of the following:
          1) They wrote some low level C hooks that makes the application not "pure" java.
          2) They want to milk you for a new version of the software that "supports java X now" .
          3) They have bad programmers that don't really understand there code, there is some voodoo magic in that specific version of java is needed.
          4) The company wants to assume no deviation in run time environment such to lower any support cost for there number 3 mistakes. Most likely is number 3, they just
        • by DamonHD ( 794830 )

          I am a sysadmin and have been for over 25 years, as well as a developer and consultant and architect, and I eat my own dogfood.

          A Java runtime is no worse than (say) a C++ one from an admin point of view, IMHO.

          Rgds

          Damon

  • Nothing has changed in 15 years

Get hold of portable property. -- Charles Dickens, "Great Expectations"

Working...