Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Java Programming Technology IT

State of the OpenJDK Project and Java 7 184

Posted by Zonk 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.'"
This discussion has been archived. No new comments can be posted.

State of the OpenJDK Project and Java 7 More

State of the OpenJDK Project and Java 7

Comments Filter:

  • Waste of time? (Score:2, Interesting)

    by thunderlizard ( 947581 )
    Isn't the OpenJDK just a waste of time (or a reinvention of the wheel?). The Sun JDK is already open, with the source code available...

    • Re:Waste of time? (Score:5, Informative)

      by aled ( 228417 ) on Tuesday August 28, 2007 @09:25AM (#20382997)

      Isn't the OpenJDK just a waste of time (or a reinvention of the wheel?). The Sun JDK is already open, with the source code available...


      OpenJDK IS the SunJDK, is just that Sun open sourced the SunJDK under GPL with the name OpenJDK, minus some proprietary components that are being replaced by the community.

    • Re:Waste of time? (Score:5, Informative)

      by mhall119 ( 1035984 ) on Tuesday August 28, 2007 @09:26AM (#20383011) Homepage Journal
      The OpenJDK is Sun's JDK, only under the GPLv2 license. Sun's JDK may make the source available, but you are limited as to what you can do with it.

      • Re: (Score:3, Informative)

        by wawannem ( 591061 )
        The OpenJDK is Sun's JDK, only under the GPLv2 license. Sun's JDK may make the source available, but you are limited as to how you can re-distribute it or derivatives of it.


        There, I fixed it for you. -W

  • v1.6 at 64bit on FreeBSDv7.0 (Score:3, Informative)

    by billsf ( 34378 ) <billsf@cuba.ca[ ].nl ['lyx' in gap]> on Tuesday August 28, 2007 @09:17AM (#20382907) Homepage Journal
    Simply happy to have a 'modern' jdk on a modern machine running a modern OS. Very slick stuff. :) Something new again? I call that real progress.

  • Bad requirements (Score:3, Insightful)

    by bchernicoff ( 788760 ) on Tuesday August 28, 2007 @09:21AM (#20382959)
    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?
    • Half the developer community is pushing all kinds of new language features, and the rest of the developer community is pushing to keep those same new language features out. There is no consensus about any of them at the moment.
  • No javaws, no Mozilla plugin.
  • Awesome, just what I've always wanted. Parsing XML is an extremely important requirement in determining the expressiveness of a language, mind you. Except, they're gonna be screwed when CSV files come back. And don't even get me started on what a pickle they'll be in when those .DAT files return to claim their rightful place!

    As such, I move to recommend that Java incorporate support for parsing CSV and DAT files into the language.

    • Re: (Score:2, Informative)

      by WWWWolf ( 2428 )

      Awesome, just what I've always wanted. Parsing XML is an extremely important requirement in determining the expressiveness of a language, mind you. Except, they're gonna be screwed when CSV files come back. And don't even get me started on what a pickle they'll be in when those .DAT files return to claim their rightful place!

      As such, I move to recommend that Java incorporate support for parsing CSV and DAT files into the language.

      First of all, Java already has pretty good "language-level" support for XML for short while now - it's called JAXB. Basically, you can say things like "this class, Foo, represents XML tag <foo>" in your code, and use the JAXB Marshaller and Unmarshaller to save and load XML.

      And when the CSV files come back, all you need to do is implement String toCsvRow() or String toCsv() in your class and implement a marshaller/unmarshaller that walks your data structure and crunches it into CSV, or back. It's

    • Re: (Score:2, Funny)

      by kramulous ( 977841 )

      As such, I move to recommend that Java incorporate support for parsing CSV and DAT files into the language.


      I second that that motion. Hopefully motion will be parsed.

  • Refactoring (Score:5, Insightful)

    by ishmalius ( 153450 ) on Tuesday August 28, 2007 @09:36AM (#20383133)
    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.

    • Re: (Score:3, Insightful)

      by ZeroConcept ( 196261 )
      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.

      • Re: (Score:2, Insightful)

        by dintech ( 998802 )
        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.

      • Re:Refactoring (Score:4, Insightful)

        by Abcd1234 ( 188840 ) on Tuesday August 28, 2007 @04:52PM (#20389933) Homepage
        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.

        • Re: (Score:2)

          by obi ( 118631 )
          Maybe look at Vala then, though it's probably still at "toy-language" stage.
        • In .NET, arrays and strings have lengths. Collections have element count. When array poses as a collection (i.e. when you cast it to ICollection - and you can), it also has property Count.

          Meanwhile, in Java, we have public final field length for arrays (nevermind that every style guide explicitly forbids having public non-static fields in a class), length() for class String and size() for collections. Neither of which conform to naming conventions for JavaBean properties, so whenever a bean need to expose

        • You provide one example of API inconsistency and no further evidence to support your judgment. Have you shipped applications built in both platforms? I get the impression you haven't worked too much with .NET to know where the weaknesses of it are (and I know there are many), Array.Lenth and List.Count are not near the top 10 pains. Besides there are comparable inconsistencies in the Java libraries.
          • You provide one example of API inconsistency and no further evidence to support your judgment. Have you shipped applications built in both platforms?

            Yes, I have. Fairly large ones, too (not huge... the 100K+ range).

            Array.Lenth and List.Count are not near the top 10 pains

            Yes, because I selected that because it's at the top of the list, and not simply because it's a) patently stupid, and b) easy to illustrate.

            Besides, are you trying to defend .NET or not? Your suggestion that you can easily think of 10 othe
            • To clarify, I like both platforms (J2EE, .NET) for different things, as far as the API is concerned my logic goes like this:
              - .NET has less historic baggage
              - .NET was designed from learned lessons from Java and other languages
              From my experience, the .NET API feels cleaner than Java.

              I understand your point is that the .NET API is inferior to J2EE, is this the case?

              If so, would you explain which parts of J2EE do you consider superior and why? Pointing flaws in .NET alone doesn't provide a fair comparison.
              • I understand your point is that the .NET API is inferior to J2EE, is this the case?

                Uhh, I don't recall making that point, nor would I, since I don't have a lot of experience with either stack (most of my .NET and Java experience is in building desktop and server applications). I have made disparaging comments about ADO.NET, but that's simply a database access layer, not a complete, soup-to-nuts application stack. And in the Java world, there really isn't an equivalent, as most people work with ORMs built

    • Re: (Score:3, Informative)

      by mhall119 ( 1035984 )

      AWT and Swing need to be reconciled

      Reconciled in what way? Mixing AWT and Swing widgets has been fixed in current Java 7 builds. Other than that, I don't know what kind of reconciliation is possible.

      There needs to be a declarative GUI design grammar. Maybe JavaFX's grammar could be borrowed for that.

      JavaFX's grammar was taked from F3 [sun.com], which is a declarative GUI language for Java.

      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)

      Beanbindings (JSR 295) [java.net] is already in the works, and will allow you to "bind" a java.util.List as the data model for a JList widget. Meaning that you can read JList info from the java.util.List, or write to a java.util.List and have the changes appear in the JL

      • Mixing AWT and Swing widgets has been fixed in current Java 7 builds.

        That sounds wonderful. I didn't know that this had happened. Good news! So there is no longer a split between the NNNN and JNNNN widget classes?

        Meaning that you can read JList info from the java.util.List, or write to a java.util.List and have the changes appear in the JList on the next repaint.

        This is another much-anticipated feature that will be greatly appreciated. Good to see that the new development efforts are paying off.

        • That sounds wonderful. I didn't know that this had happened. Good news! So there is no longer a split between the NNNN and JNNNN widget classes?
          Oh they are still separate, as they are still very different things. Swing != AWT. But you can now put Swing widgets on top of all or part of an AWT widget, which you couldn't do before.
      • JavaFX's grammar was taked from F3, which is a declarative GUI language for Java.

        I thought that too, but it turns out JavaFX IS actually F3, just rebranded with an official name. I thought Form Follows Function was a pretty nice name, but then I don't work in marketing, do I...

        Minor nitpick. :)

        • I thought that too, but it turns out JavaFX IS actually F3
          It's quite a bit more than _just_ F3 though.

    • Re: (Score:2)

      by julesh ( 229690 )
      The thing needed most by Java, IMHO, is not more features, but a thorough cleanup of the runtime classlib.

      Agreed. There are huge problems with the Java classlib as it stands, and these problems account for most of the issues that Java has. The biggest one is the huge list of dependencies typical classes, including some of the most basic classes in the library, have.

      For instance, all classes depend on java.lang.Class. java.lang.Class depends on (among others) java.io.InputStream, java.net.URL, sun.reflect

      • Re: (Score:2)

        by VGR ( 467274 )

        The biggest problem that Java has, and it's a problem it has always had, is that Java programs take too long to start. This is directly because of this dependency problem. I say: strip it down to layers. Define a core set of classes, no more than 20 or so of them, that must always be there. Add new functions on top of those in small increments. Basic classes must not depend on more advanced ones.

        That's strange. All my Java programs, nearly all of them large Swing programs, start up in less than one seco

        • Re: (Score:3, Insightful)

          by julesh ( 229690 )
          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 p

    • Couldn't agree more. I've been developing in Java from the early days and it's certainly starting to become time to make a clean break. As long as sun announce that they will continue to support the 1.x language for say 10 years but stop adding new features 2 years from now I think the majority of people will switch. At the end of the day look at the move from the old days of dos to the newer windows stuff. DOS applications were often impossible to run in 2000 which was only about 10 years after dos applic

    • Re: (Score:2)

      by nuzak ( 959558 )
      All this stuff has already been done. All you're suggesting is moving shit around. I'd much rather see some radical language changes come with the next language, and it should certainly run on the JVM, but there's simply no reason it has to be Java.

      I would argue that Scala is already the worthy successor language. Others would point at Fortress. Either way, all I care about as far as Java goes is that it evolve to help make those languages better and interoperate more.

    • Re: (Score:2)

      by the_olo ( 160789 )
      While pruning deprecateds (sorry for funny grammar...) is a good idea and has to be executed some day, I'd disagree that this needs to be done with the first release that will be fully open source.

      For those, who look forward to OpenJDK release, it would be a great disappointment that could set back the whole Java camp a couple of years because of mindshare/psychological reasons.
      If the first release that's finally included with all the Linux distributions would make lots of older software stop working, lots

  • Jesus, JDK7?! (Score:3, Interesting)

    by Lysol ( 11150 ) on Tuesday August 28, 2007 @11:41AM (#20384743)
    Man, I've been programming Java since 1.x (yah, yah, I know). Is it me or does it just seem like the versions are getting a little whacky. I don't do much Java programming anymore, but it always seems like a jump in major number was a big issue if you have to maintain apps. Shit, how many people out there in the 'real' working world use 1.6? Prob no one. Last project I did (for a major bank) required 1.4.2 and it was deployed at the beginning of this year.

    I feel like it's great (again, even tho I'm not using it this year) that Sun is on top of stuff and 'looking ahead'. But I really wish they would do meaningful SMALL dot increments and quit shoving out a now major release every year or so. I know 1.5 was out a while ago. But why not keep making 1.5 REALLY super stable and optimized and make 1.6 ONLY the one with the new uber-Swing and whatever else.

    It's sorta like Microsoft coming out with Vista even tho no one want's to use it cuz all the 'new stuff' (which seems to have been cut at the last minute) isn't stable. Continuously having big releases makes people feel like they have to abandon the older releases so they can focus on re-learning all the new features that haven't made it out yet. I've seen this on teams I've worked with.

    I just think more stable, optimized, smaller point releases are the way to go. And Sun being an 'enterprise' company should know this.

    • Re: (Score:2)

      by ADRA ( 37398 )
      Well, since Java is more or less 100% backwards compatible they could release a new major version every two weeks and nobody should care. That said, there are some gotcha's to watch out for when upgrading to new versions of the JDK. For the company I work for, the move from 1.4's Metal to 1.5's Metal meant going through every screen to make sure the layout was still consistent. That wasn't fun, but the added features of the release more than compensated for it.
    • Shit, how many people out there in the 'real' working world use 1.6?

      *raises hand* Fifteen machines servicing about 700,000 users.
    • Actually, we found 1.6 fixed a number of issues we were having with anything later than 1.5.03. So we're using it in a production environment. But, we are small and "agile", I think is the word ;)
  • I remember when Java was still in its first beta that Mitsubishi (among others, mostly Japanese) announced a Java CPU that executed bytecode in HW, not a SW JVM. It integrated a DSP, evidently targeted at consumer multimedia apps. Maybe a "set-top box" which was the main vision for "converged" PC/TV/network devices back then, around 1995.

    What ever happened to Java CPU/DSPs? By now, if they'd worked out, I'd expect most consumer devices to include them, but I don't know about any. Maybe they required develop
  • ..... 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

    • Re: (Score:2)

      by fuzz6y ( 240555 )

      Also, ditch the requirement to have function arguments in brackets.

      If you want to program in perl, nobody's stopping you.

    • Re: (Score:2)

      by glwtta ( 532858 )
      Automatic type coercion is, in general, a good thing -- it removes clutter (in the form of unnecessary function calls).

      Eh? Java is statically typed (well, for primitives, anyway), I'm not sure how you envisage automatic coercion here. And not requiring parentheses for method calls would make most Java code unreadable (and probably unparseable).

      Java is just not a concise language, you must be thinking of something else.

    • 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.

      Sure, its easy when you talk about changing sin(theta) to sin theta, but when you have ln(sqrt(x))+y and ln(sqrt(x+y)) and ln(sqrt(x)+y) and they all map to ln sqrt x+y, you start needing parens anyway to enforce sequence, whether explicitly to specify function arguments or to denote expression precedence.

      When you've got nested function

      • Re: (Score:2)

        by ajs318 ( 655362 )
        It's never ambiguous as far as the computer is concerned, because there will always be operator precedence. sqrt binds more tightly than + and so does ln, but the sqrt, being nearer the argument, gets evaluated first; so ln sqrt x + y is ln(sqrt(x)) + y.

        I'll admit, that's one case where brackets are actually more of a help than a distraction. But if you were taking baby-steps, it wouldn't be so bad. Also, for the benefit of baby-steppers, how about a forget statement which would free up memory that had

        • It's never ambiguous as far as the computer is concerned, because there will always be operator precedence.

          Well, sure, if one views "function call" as an implicit, invisible operator. Still, with multiple argument functions (particularly with variable length argument lists) parsing becomes tricky, at least for humans. I mean, if you ditch parens in those cases, you can end up with things like

          printf format_str, val1, val2, my_func val3, val4, val5, other_func val6, val7

          If my_func and other_func take variabl

        • I know, real programmers just reuse variable names ..... it has the same effect ..... but the whole idea of modern programming languages is to let the computer do the work for you. An optimising compiler would see the baby-steps followed by a bunch of forgets and decide that since the intermediates were obviously never going to be required again, they could all be stuck into one big long operation.

          Even better, you could have the compiler figure out the last position a particular variable is used in a fu

          • Re: (Score:2)

            by ajs318 ( 655362 )
            True; but an interpreter (or even a compiler which supports an eval function, or some other weirdy "calculated" construct such as treating variables as a property of the containing namespace) wouldn't be able to do that, because it wouldn't have any way to know for certain that the variable really was never going to be used again. It could conceivably crop up in an eval, or be accessed by some other indirect means.

            Of course, gratuitous misuse of forget (especially inside an eval) could be even more e

            • True; but an interpreter (or even a compiler which supports an eval function, or some other weirdy "calculated" construct such as treating variables as a property of the containing namespace) wouldn't be able to do that, because it wouldn't have any way to know for certain that the variable really was never going to be used again.

              Even most interprete languages (such as Python) are in fact compiled or at the very least parsed and tokenized when loaded, giving the interpreter a chance to evaluate variable

    • I keep hearing rumors that Ruby is going to start requiring parentheses for function arguments because, I assume, it's too confusing otherwise.

      Clutter is just what you are used to--it's objective. Where Java can it uses a single, consistent methodology at the cost of a few extra characters.

      It's clearer for many people to read and not harder for anyone I've ever met except perhaps for people trying to prove that their language of the day is "Better" somehow than some other language.

    • Re: (Score:2)

      by nuzak ( 959558 )
      > Also, ditch the requirement to have function arguments in brackets.

      Will not ever happen. Fortress on the other hand might be up your alley. I believe you can even overload the concatenation operator in Fortress. It may be aimed at fortran, but I imagine you could write whatever you like in in.

      And BTW, perl got nothing whatsoever right about concatenation. It has a different operator for strings because it is incapable (without diving deep into internals) of telling the difference between strings an
    • All your comments are great if you assume code writing speed is more important than readability, for quick & dirty disposable code that would be the case. For enterprise applications that require high-availability bugs introduced due to automatic stringnumber comparisons, non-explicit function parametrization etc. Can be very hard/expensive to identify and correct.

      I was on a project in which we converted a VB.NET application to C# using automated tools, we found and fixed several bugs due to the (limite

  • Consistent, sane branding and versioning needed (Score:5, Insightful)

    by Fastball ( 91927 ) on Tuesday August 28, 2007 @12:47PM (#20386039) Journal
    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.

    • Re: (Score:2)

      by WWWWolf ( 2428 )

      Well, Sun Java is one of the Giant Bytecode Virtual Machines, and everyone knows that the official versioning scheme of Giant Bytecode Virtual Machines is that of GNU Emacs. So they just decided to drop the first number, like the Emacs folks. Expect the language flame war between Java and C# really flare up into a giant massive global CARNAGE by the time of Java 19 or 20. =) (Though, just for the argument, I can't say C# has any of the redeeming qualities of vi, compared to Java. Both are equally massive. =

    • 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.

      The version of the JVM was 1.2, while the version of the Java language it ran was 2.0. It's a bit like GCC 3.0 (the program) supports C89 (the language).

Slashdot Top Deals

Two can Live as Cheaply as One for Half as Long. -- Howard Kandel

Close