Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Java Oracle Programming

To Avoid Confusion: Oracle's Confusing New Java Numbering Scheme 183

twofishy writes "'To avoid the confusion caused by renumbering releases,' Oracle has announced that it is adopting a new numbering scheme for JDK 5.0, JDK 6 and JDK 7. 'The next Limited Update for JDK 7 will be numbered 7u40, and the next 3 CPUs after that will be numbered 7u45, 7u51, and 7u55." The vendor notes that a more elegant solution would require the changing of the version numbering scheme to accommodate different kinds of changes (for example by using 7u44-2 ). However this cannot be implemented outside of a major release, since doing so might break existing code that parses version strings (possibly including the Java auto-update system)" Here's Oracle's announcement.
This discussion has been archived. No new comments can be posted.

To Avoid Confusion: Oracle's Confusing New Java Numbering Scheme

Comments Filter:
  • by fnj ( 64210 ) on Tuesday May 14, 2013 @09:13AM (#43719507)

    An absurd TLA overloading.

  • by Karganeth ( 1017580 ) on Tuesday May 14, 2013 @09:13AM (#43719509)
    Surely they could just number them from 1 to infinity. Why does name matter? Who knows.
    • by alexo ( 9335 )

      Why does name matter?

      http://www.youtube.com/watch?v=Jg9w0YSMLHY [youtube.com]

    • by bunratty ( 545641 ) on Tuesday May 14, 2013 @09:36AM (#43719785)
      Because programs are used to decode/encode the name. It's the same problem with Y2K, user agent strings, and so on. When programs expect data in a certain format, such as two digits for years or a single number after a u in a version string, they don't react well when the format is changed. RTFA.
      • by unrtst ( 777550 )

        Because programs are used to decode/encode the name.

        ...except that isn't the problem.

        They are using an incremental number on the RHS (right hand side) of the "u" seperator, and that number may represent either a critial patch update or it might be a new minor version. The problem arrises when they attempt to associate FUTURE releases with stuff in bugtrackers and their ilk. They could have more CPU releases than normal releases, making the CPU minor release number much higher than the planned normal release, causing a bunch of confusion.

        Their solution, IMO,

        • by gl4ss ( 559668 )

          why not just incrementally switch to 1.2.3.4 version? and guarantee that api's wont probably break at minor bumps.

          • Because "Java 7.53" makes them look bad - 53 critical updates!

            Instead they chose to obfuscate things and redefine "CPU", which doesn't make them look bad at all.

      • by Zadaz ( 950521 )

        There's a solution to this, it's called deprecation. A proper way to do this would be to still support Wacky Version Numbers with System.getProperty("java.version") but note that it is deprecated and list a date after it will no longer be supported.

        Then you add something new like System.getProperty("java.realVersion") which is just a number from 1 to infinity. (Or something more common like Major and Minor version.) Doesn't break anything, provides a way forward. Languages that aren't thinking 10 years/rev

    • by LordLimecat ( 1103839 ) on Tuesday May 14, 2013 @10:08AM (#43720197)

      Because the old numbering system of incrementing by 1 was far too complicated. The new system is much easier to understand:

      * Limited Update releases will be numbered in multiples of 20.
        * We intend for Critical Patch Updates to continue to use odd numbers. The numbers will be calculated by adding multiples of five to the prior Limited Update and when needed adding one to keep the resulting number odd.
        * Updates containing Norton instead of McAfee will be prime numbers
        * If an update actually contains intentional regressions, it will end in a 9. We recommend you do not install these updates.
        * If the update number is a prime but also a member of the fibonacci sequence, it is considered a "surprise" update: It will be automatically installed, and will contain 1 or more undesirable features. It may also install the ask toolbar.

      Obviously this system is far superior.

      • Because the old numbering system of incrementing by 1 was far too complicated. The new system is much easier to understand:

        * Limited Update releases will be numbered in multiples of 20.

        * We intend for Critical Patch Updates to continue to use odd numbers. The numbers will be calculated by adding multiples of five to the prior Limited Update and when needed adding one to keep the resulting number odd.

        Obviously this system is far superior.

        But then there is the even more superior solution which would be to get their shit together. Seriously, the situation with Java is beyond absurd. The number of updates to fix security holes is a few orders of magnitude beyond absurd. How is it even possible to create software so shitty and full of holes?

      • by t4ng* ( 1092951 )
        Ah... I think I see were Sun can do some layoffs. First, promote the management of the team that came up with the new numbering. Then layoff all the programmers, except for one intern.
      • I belive the "surprise update" feature is patented by Mozilla.

    • Well the issue with version numbers are Important.
      I actually like the new scheme it makes it much easier to see how up to date you are.

      The problem was back with MS changing their version numbers after Windows NT 4/Windows 3.1 with 95, 98, ME, 2000, XP, 2003, 2008, Vista, 2012....
      While the Date of the release is better, a general version number Major.Minor.Patch is superior, as it can really help you decide to Upgrade or Not or how much effort will it be to upgrade.

      Major: Big New features, Full Compatibility

  • by Errol backfiring ( 1280012 ) on Tuesday May 14, 2013 @09:14AM (#43719519) Journal
    You know, to be able to insert something between two existing lines.
  • by Joe_Dragon ( 2206452 ) on Tuesday May 14, 2013 @09:14AM (#43719521)

    Why not copy MS and have 2 ver numbers like how windows 7 is also 6.1

    • Windows 7 is 6.1 for compatibility reasons. When Vista went to 6.0 it broke a lot of applications that were incorrectly checking the Windows version, like so:

      if (MajorVersion >= 5 && MinorVersion >= 1) {

      Back when the latest version of Windows was XP, this code worked fine 100% of the time. Of course it fails to pass this check on Vista, where MinorVersion is 0. Windows 7 and Windows 8 are 6.1 and 6.2 respectively since they will pass this check. At least, that's what I've heard.

      • by ArcadeMan ( 2766669 ) on Tuesday May 14, 2013 @09:28AM (#43719687)

        Who would be stupid enough to check for the OS version that way? It should have been something like:

        if ( ( MajorVersion * 10 ) + MinorVersion >= 51 )
        {
        }

        • by flink ( 18449 )

          Who would be stupid enough to check for the OS version that way? It should have been something like:

          if ( ( MajorVersion * 10 ) + MinorVersion >= 51 )
          {
          }

          You know it's possible to have a v4.12, right?

    • because one is the operating system and the other is the kernel. Every linux distro does the same thing. Ubuntu 13.whatever uses linux 3.8.
      • Re: (Score:3, Informative)

        by X0563511 ( 793323 )

        Wrong. Ubuntu uses YY.MM date-based numbering.

        • Correct ... for the distro version.

          The kernel version is 3.whatever.

          Two completely separate numbers, incremented separately. Just like Windows OS versions and kernel versions.

    • by David_W ( 35680 )

      They do...

      C:\>java -version
      java version "1.6.0_43"
      Java(TM) SE Runtime Environment (build 1.6.0_43-b01)
      Java HotSpot(TM) 64-Bit Server VM (build 20.14-b01, mixed mode)

  • IQ (Score:5, Funny)

    by rossdee ( 243626 ) on Tuesday May 14, 2013 @09:19AM (#43719591)

    Mensa can use this as a 'What is the next number in the sequence' for their IQ test.

  • by jfdavis668 ( 1414919 ) on Tuesday May 14, 2013 @09:24AM (#43719639)
    Every time they try to standardize version numbers, they make it more confusing. 11G database release 1 was 11.0, but release 2 is 11.2. Where was 11.1? App server 9i was actually an 8.0 base. Most of the time I can't even figure out which product I am actually buying.
    • Comment removed based on user account deletion
  • Why not just switch the numbering to the sha of the package. Equally informative...

  • Simpler solution.. (Score:5, Insightful)

    by xtal ( 49134 ) on Tuesday May 14, 2013 @09:25AM (#43719653)

    I resolved the issue by removing it.. perhaps, that is the intended effect. Apologies to those with no choice.

    • I've had a new PC for almost a year with no JAVA.

      No apps/sites have complained and I run LibreOffice, too.

      • by gl4ss ( 559668 )

        a bunch of programs that have java come with a java vm. it makes things easy to install.

        but install packages take 90 megs for something that should be 2 megs..

  • You are a terrible terrible programmer and you deserve to be caned by a band of angry Thai policemen.
    • I'm assuming the updater does this to make sure it's getting a newer version than what's already installed. How would you handle it? A single 64-bit number? A history graph à la Git?
      • The way developers have been doing it for decades, using the de facto standard of major.minor.build version numbers.

        IOW, JDK 5 uses 5.x.y numbers, JDK 6 uses 6.x.y numbers, JDK 7 uses 7.x.y numbers. X is incremented for feature releases and resets Y to 0. Y is incremented for security releases.

        Simple. Easily parseable. And it the ways things used to be done before the whole stupid "my number needs to be bigger than your number, logic be damned" movement started.

        • They pretty much do that, just with a useless prefix and an _ instead of . as the last delimiter.

          So instead of major.minor.build it is 1.major.minor_build, which means I could take your statement and easily alter it to read:

          JDK 5 uses 1.5.y_z numbers, JDK 6 uses 1.6.y_z numbers, JDK 7 uses 1.7.y_z numbers. Y is incremented for feature releases and resets Z to 0. Z is incremented for security releases.

          As you say, that's "Simple. Easily parseable."

          The funny thing is, they never put out "feature releases" so t

  • Something simple like: API-level (revision release date)

    Isn't something like "Java 7 (20130514)" relatively obvious what it means?

    • Sun made people feel safe putting their eggs all in 1 basket. Witness the result that many of us said was a foolish move.

      C# may be a knock off and not have Oracle but then you have MS holding your eggs; and while MS might not act as badly as Oracle, they have a borg mentality that Oracle does not yet have with Java.

      Do not build your business around closed languages. When C# becomes fortran the MS holdings company will still be extracting blood.

      Oracle is secure (and just evil,) MS on the other hand has 1 r

  • Ask Toolbar (Score:4, Insightful)

    by Anonymous Coward on Tuesday May 14, 2013 @09:40AM (#43719815)

    I don't care what they call it so long as I don't have to install any toolbars.

    Like seriously what is this 2003? It's crowding out my "Bonzi Buddy"

  • Oracle... we don't care. Please just donate Java to Apache.
    • Oracle... we don't care. Please just donate Java to the trash.

      TFYFY.

      Oh wait, you mean they already did that?!

  • by sl4shd0rk ( 755837 ) on Tuesday May 14, 2013 @09:55AM (#43720005)

    It was easier to change the version numbering scheme to break all the current malware rather than fix the myriad of holes in the code.

  • Why not just do a normal numbering scheme? If you dig into their packages, they sometimes claim stupidly to be version 1 of Java 7 update 17. WTF? Instead of that, how about Oracle just acts with some sanity and call it v. 7.17?

    If you need sub versions of 7.17, then call it 7.17.1 and 7.17.2. You know, a sane person might do.

    Or how about we all just drop Java since it's terrible and the cause of too many security problems?

    • You know, that does sound normal.
      But you're forgetting that Java 7 is actually Java 1.7, much like Java 6 was actually Java 1.6, and Java 5 was actually Java 1.5, etc.
      So there's that implicit "1." that you need to prefix to these version numbers.
      So that sentence in the summary should read more like:

      "The next Limited Update for JDK 1.7 will be numbered 1.7u40, and the next 3 CPUs after that will be numbered 1.7u45, 1.7u51, and 1.7u55."

      I can't wait to see what happens when they finally make it to Java 2.0... Will it be "Java 0"?

      • It doesn't really change the basic idea. In fact, I think it makes my point even stronger.

        If it's Java 1.7, why refer to a version as 7u40-3 version 1.0? Are you ever going to have a version of Java 1.7 that you're calling 7u40-3 version 2.0? That's insane.

        Just call it 1.7.40.3. Or really, make it simpler than that.

  • I would submit that this is somewhat sensible and that the switch from 1.5 to 5.0 back in the Sun days was far more confusing.
  • Or do we not have numbers that go that high?

  • Are their releases really called CPUs?
    If so, that is so amazingly stupid it appears actually designed to confuse.

  • Microsoft - One big version number. One little one. .Net Framework 2.0, 3.5, etc... easy to know where you are. Security patches don't alter the name unless they're a service pack. Then it would be .Net 3.5 sp 1 whatever. You at least know that as long as you have the update service running you are fully patched up and manually running it will make sure. 7u45 is freaking Chinese - it sounds like something that should be on the side of a submarine. Imagine trying to say one of these numbers on a phone to so
    • except the little problem of major component updates coming in v3.51 and the server OS being released with v3.5 on it,so many of your bleeding-edge programs wouldn't run.

      I think they fixed this by simply reducing the amount of development going into .NET, thereby reducing the frequency of .net releases.

      • Actually the .Net philosophy to me seems the polar opposite of Java. .Net releases seem further apart but seem to work better and have more integrated functionality. Personally... after using both for a long time C# + .net wins.... The portability comment isn't even an issue anymore really... Mono is working well in most cases (the gap is mostly in the latest incarnations of asp.net and MVC) and is fast enough to run games so it is fast enough for any business use at least in my mind. Personally, I dislike
        • True, .net is much better than Java, but I think much of that is down to the tooling - try writing C# code in notepad!

          They're both still pretty inefficient though, I've played a couple of games written in C#/XNA, they're ok, but there's a lot of grinding at startup and a lot of sluggishness after you've played for a while. Could be just general poor programming practice from games devs, but there's a fair amount of language "assistance" there.

  • Wow. Just wow. (Score:5, Insightful)

    by QilessQi ( 2044624 ) on Tuesday May 14, 2013 @11:43AM (#43721461)

    After reading the Oracle announcement through three times, I actually checked my calendar to see if April 1st had somehow come around again.

    Which is a distinct possibility if Oracle takes over the Gregorian Calendar next.

  • Why not call it "Java Blew"?

  • Note that addition to using a new numbering scheme, each critical Java security update attempts to install the Ask.com toolbar, even if upon the initial install you unchecked the Ask.com checkbox. The latest browser versions include measures to foil the attempted install of the Ask.com, so tech-savvy people tend to be unaware of how bad and intrusive the toolbar is. It mucks up all search results with complete garbage. (details here [zdnet.com])

    So basically the tech naive types get this thing installed and it thoroug

  • From TFA:

    Is this the long-term solution?

    This solution is a compromise to create predictable release numbers for future Java releases, leave version numbers available for unplanned releases needed to address security alerts, and maintain backward compatibility with systems that expect the version number to have only a family number plus a single “update” number. It will be the new standard for the affected version.

    A more elegant solution requires changing the version format of the JDK to accommodate multiple types of releases. To avoid incompatibilities with existing code however, a change in the version string format needs to be implemented on a future major Java release and will have to be documented and communicated with adequate time to allow software developers to prepare for the change.
    Is this the long-term solution?

    This is a workaround. Oracle is being plain about this and at least making an effort not to break applications.

  • It's not confusing, it's just Klingon numbering [slashdot.org].

You are always doing something marginal when the boss drops by your desk.

Working...