Slashdot Mirror

← Back to Stories (view on slashdot.org)

State of the OpenJDK Project and Java 7

Posted by Zonk on from the heading-out-to-meet-new-people dept.

LarsWestergren writes "David Flanagan, the author of Java in a Nutshell, has a nice writeup on the state of the open source development of the next version of Java. The article explains the difference between the JDK7 and the OpenJDK projects and how to join them. Furthermore, it has an overview of the release schedule, proposed language changes and projects of interest. A more technical and in-depth tracking of the language changes and proposed new features can be found at Alex Miller's blog. This is the first in a series, and 'each future installment will provide an update on what's currently happening in the latest builds from the project, along with a deep dive into a new feature or API that's tracking for inclusion in Java 7.'"

11 of 184 comments (clear)

  1. Bad requirements by bchernicoff · · Score: 3, Insightful

    It sounds like they still have no idea which new language features will make it into the release. What is driving them to add new features? Are they just trying to move the language "forward"? If the developer community isn't pushing new requirements then why muck with the language?

  2. Re:Java 7? by mhall119 · · Score: 2, Insightful

    Install Linux on your iBook and you're all set.

    --
    http://www.mhall119.com
  3. Refactoring by ishmalius · · Score: 4, Insightful

    It's good to see that there is at least one project aimed at cleaning up old legacy code. The thing needed most by Java, IMHO, is not more features, but a thorough cleanup of the runtime classlib. The packages and classes need to be rearranged logically, renamed, made to have consistent API's and naming patterns. Redundancies need to be removed (like 3 different RPC schemes and APIs), and deprecations finally need to be pruned. Collections- and non-collections-containers need to be merged, and AWT and Swing need to be reconciled. There needs to be a declarative GUI design grammar. Maybe JavaFX's grammar could be borrowed for that. And the long-promised merging of Swing and Collections needs to happen, too. (Like a popup list could be accessed as a java.util.List)

    I have thought for years that there needs to be a "JDK 2.0" series started which would be a clean break from the 1.x series. Keep maintaining the 1.x series, but make a fresh start.

    1. Re:Refactoring by Anonymous Coward · · Score: 1, Insightful

      ... needed ... need ... need ... need ... need ... need ... needs ... needs ... needs ...

      You keep using this word. I do not think it means what you think it means.
    2. Re:Refactoring by ZeroConcept · · Score: 2, Insightful

      I would argue that a cleaner API is one of the advantages of .NET over Java, cleaning up the Java libraries would certainly bridge this gap.

    3. Re:Refactoring by dintech · · Score: 2, Insightful

      I would agree that there is lots of legacy detritus left in the class libraries. However, I'm not sure it really causes that much of a problem. If you don't use those classes for anything, they're pretty much invisible to you.

    4. Re:Refactoring by Abcd1234 · · Score: 3, Insightful

      ROFL! You can't be serious! Consider:

      Array.Length
      List.Count

      I'm sure there are a million other examples (date handling, for example, is totally fucked up in .NET).

      I've said for some time now, C# is actually a pretty decent language hobbled by a horrible class library.

    5. Re:Refactoring by julesh · · Score: 2, Insightful
      That's strange. All my Java programs, nearly all of them large Swing programs, start up in less than one second. Without any OS caching.

      One second is way too long for process startup, IMO. A process should be able to be running within a tenth of a second, to be useful in many circumstances.

      Timings of a C-based hello-world program:

      Jules@minerva ~/My Documents/projects/eclipse/jzx/bin
      $ time ./test
      Hello, world

      real 0m0.047s


      Python-based equivalent:

      Jules@minerva ~/My Documents/projects/eclipse/jzx/bin
      $ time python test.py
      Hello, world

      real 0m0.109s


      Java-based equivalent:

      Jules@minerva ~/My Documents/projects/eclipse/jzx/bin
      $ time java Test
      Hello, world

      real 0m0.266s ...

      Jules@minerva ~/My Documents/projects/eclipse/jzx/bin
      $ java -version
      java version "1.6.0_01"
      Java(TM) SE Runtime Environment (build 1.6.0_01-b06)
      Java HotSpot(TM) Client VM (build 1.6.0_01-b06, mixed mode, sharing)


      Why is Java the slowest of all three of these? A quarter second startup time for a trivial CLI program on a modern computer with a multi-gigahertz processor, a surplus of RAM and Java already in the cache (because two existing Java programs were already running on the machine) is unacceptable. The job Java has to do is substantially simpler than Python's job, which included compiling the source to bytecode prior to running it. It makes Java implausible for writing high-performance CLI programs, which you often need to run hundreds of times to perform certain jobs.
  4. What Java really needs ..... by ajs318 · · Score: 1, Insightful
    ..... is a new string concatenation operator. One that doesn't look like any of the "numeric" operators.

    Perl got this right. If you want to concatenate strings (using the string concatenation operator .), it coerces the operands to string. If you want to add numbers (using the numeric addition operator +), it coerces the operands to numeric.

    Automatic type coercion is, in general, a good thing -- it removes clutter (in the form of unnecessary function calls). However, it breaks down when using "overloaded" operators (that have different meanings in different contexts), when the context in which the operands are meant to be evaluated is ambiguous. It's not always obvious whether something is supposed to be numeric or a string. Perl's rules are that only strings can be concatenated and only numbers can be added. Obviously this can only make sense if the operators themselves are different. (The reason + worked OK in BASIC was that there's no automatic coercion [except between integer and floating-point, in dialects that support integers -- some BASICs treated everything numeric as floating-point]; you have to call STR$ to convert numbers to strings, or VAL to convert strings to numbers. In some BASIC dialects, auto-coercion was introduced and with it a new string concatenation operator, most commonly &.)

    Also, ditch the requirement to have function arguments in brackets. They are just more clutter. The computer can work out for itself how many arguments belong to a function. I'd rather see

    s = sin theta;
    than

    s = sin(theta);
    anyday.
    --
    Je fume. Tu fumes. Nous fûmes!
  5. Re:Bah. by julesh · · Score: 4, Insightful

    The only open source java project worth noting these days is GCJ.

    Anything deriving from Sun's JVM is over. Done. Good riddance.

    Right. Because all we really need is an implementation of the language that's mostly compatible with a five year old version, and which as of the latest released version doesn't yet support generics, a critical improvement to the language definition that was made nearly 3 years ago now.

  6. Consistent, sane branding and versioning needed by Fastball · · Score: 4, Insightful

    Anybody else confused by Java's branding and versioning? Stop calling version 1.7 of the language Java7. When Java2 was released, I thought it'd be Java 2.0; no, it was Java 1.2.

    Now we have OpenJDK, Blackdown, Sun, and so on... Somebody should take Java, call it "Java," and give it logical versioning like Java 1.6.0 and Java 2.0.0. Worked for Linux and Apache. It could work for Java too.