Slashdot Mirror


IcedTea's OpenJDK Passes Java Test Compatibility Kit

emyar writes "At JavaOne in May, 2006, Sun Microsystems announced they were going to release Java as free software under the terms of the GPL. The size of the task (6.5 million lines of code) was only eclipsed by the size of the opportunity for Java as a free and open technology. [...] This week the IcedTea Project reached an important milestone — The latest OpenJDK binary included in Fedora 9 (x86 and x86_64) passes the rigorous Java Test Compatibility Kit (TCK). This means that it provides all the required Java APIs and behaves like any other Java SE 6 implementation — in keeping with the portability goal of the Java platform."

271 comments

  1. Just use a glove by malfist · · Score: 0, Troll

    So why don't they just use Java's JKD?

    1. Re:Just use a glove by sidnelson13 · · Score: 5, Informative

      OpenJDK came to surface due to pressure of the OS community, to be to fulfill OS purists' ideals. For example, being able to embed the JDK into OS Linux systems.

      OpenJDK is an effort backed up by Sun also, so that is no impasse here.

      This is great news! I can see faster and greater improvements coming to the JDK having it open.

    2. Re:Just use a glove by VGPowerlord · · Score: 2, Informative

      I was under the impression that OpenJDK was the Sun JDK7 project.

      --
      GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
    3. Re:Just use a glove by HJED · · Score: 2, Informative

      the JDK7 project builds it source from it and adds in all the propitiatory software it is still in beta

      --
      null
    4. Re:Just use a glove by Anonymous Coward · · Score: 1, Insightful

      Had sun GPL'd java YEARS ago, .NET would be nowhere today. Too bad for them, at this point it is far far too late and .NET has essentially taken over the rein of next-generation development.

    5. Re:Just use a glove by Anonymous Coward · · Score: 1, Funny

      More importantly, all my games on Pogo.com will work properly now! Yay!!

      Thank you for working so hard to make this happen!

      Now if only PulseAudio would work properly on F9 with my NVIDIA MCP51 chipset and ALSA...

    6. Re:Just use a glove by setagllib · · Score: 4, Insightful

      Put down the crack pipe. Java still has at least 3-4x as much penetration as .NET in the enterprise alone, and in community open source .NET barely makes an appearance at all. Microsoft's marketing should not be confused for fact.

      --
      Sam ty sig.
    7. Re:Just use a glove by dave87656 · · Score: 3, Insightful

      Had sun GPL'd java YEARS ago, .NET would be nowhere today. Too bad for them, at this point it is far far too late and .NET has essentially taken over the rein of next-generation development. What are you smoking? Java has a much higher penetration than .NET.
    8. Re:Just use a glove by rootpassbird · · Score: 1, Interesting

      I'm collecting a lot of bad karma these days, but +5, Insightful anyway.
      To say it bluntly, Harmony brought about the GPL-ing of Java

      --
      Hackers have long memories. It works both ways.
  2. Perfomance by electricbern · · Score: 2, Insightful

    How about performance. It is a great milestone, it is, but if it is too slow it isn't ready for prime time.

    --
    alias possession='chmod 666 satan && ls /dev > il && tail daemon.log'
    1. Re:Perfomance by JimDaGeek · · Score: 5, Informative

      They are using the "real" Java source. Only 4% of the Sun Java code wasn't released. So IcedTea only had to implement the 4% of Java that wasn't GPLed.

      --
      General, you are listening to a machine! Do the world a favor and don't act like one.
    2. Re:Perfomance by sm62704 · · Score: 1, Interesting

      How about performance. It is a great milestone, it is, but if it is too slow it isn't ready for prime time.

      With 6.3 megs of source my guess is the guy from Space Oddessy would say "My God! It's full of bloat!"

      I would be incredibly surprised if it was speedy. I wonder how many of those lines are "NOP"? How many of them are comments? How many are actual, once working code that has been commented out?

      --
      mcgrew's razor: Never attribute to stupidity that which can be explained by greedy self-interest
    3. Re:Perfomance by Reverend528 · · Score: 5, Funny

      IcedTea only had to implement the 4% of Java that wasn't GPLed.

      Although 4% doesn't sound like much, it's actually just short of 8 billion lines. It sounds unbelievable that they could accomplish that so quickly, but Java's strength is in making it easy to write large amounts of code.

    4. Re:Perfomance by glebfrank · · Score: 2, Insightful

      You do realize that NOPs and comments do not affect the speed of the software, once it's compiled?

    5. Re:Perfomance by JebusIsLord · · Score: 1

      Since most of the java source is in java, I doubt there are many (if any) "NOP"s in there... also, you're aware comments don't get compiled, right? So like, they won't slow it down? Yeesh. Anyhow, as mentioned above, this is based on the official Sun code so the performance should be pretty damn close.

      --
      Jeremy
    6. Re:Perfomance by Z34107 · · Score: 1

      Others would have modded you funny (instead of flamebait), too, but they were destroyed by Java's implementation of "sockets."

      Think "light bulbs" instead of "network connectivity" and you'll see what I mean.

      --
      DATABASE WOW WOW
    7. Re:Perfomance by sm62704 · · Score: 2, Informative

      Yes, which would affect the size of the source without bloating the code. That's why I asked. If 5 megs of the 6.3 megs of source is comments, that's a GOOD thing. Little or no bloat and the code is decipherable.

      --
      mcgrew's razor: Never attribute to stupidity that which can be explained by greedy self-interest
    8. Re:Perfomance by Anonymous Coward · · Score: 5, Informative

      This is not completely correct. In the OpenJDK project we have been removing the encumbered code and have whittled down the nonfree part of OpenJDK's source tree to 0%. OpenJDK6's source tree is 100% open source. IcedTea has been matching this by removing some of the patches they applied. Most of what's left in IcedTea is a build system. Oh, and a plugin.

    9. Re:Perfomance by penguin_dance · · Score: 2, Funny

      How about performance.

      I don't know, that Ice T guy seems to be pretty talented. First he's a rapper, then he's an actor, now he's writing Java....what?

      Oh, nevermind....

      --
      If you've never been modded as "flamebait" or "troll," you've never tried to argue a minority viewpoint here!
    10. Re:Perfomance by dave87656 · · Score: 2, Informative

      I just tested it on Ubuntu. The fonts are not as attractive as with the Sun JDK. And the resident memory usage was about twice that of the Sun JDK.

      Not sure about the speed. But first indications are that I will be staying with Sun's JDK.

    11. Re:Perfomance by dave87656 · · Score: 2, Informative

      IcedTea only had to implement the 4% of Java that wasn't GPLed.

      Although 4% doesn't sound like much, it's actually just short of 8 billion lines. It sounds unbelievable that they could accomplish that so quickly, but Java's strength is in making it easy to write large amounts of code.

      Huh? The whole project is 6.5 million lines. 4% comes out to 260,000 lines according to my calculator.
    12. Re:Perfomance by harry666t · · Score: 1

      > Java's strength is in making it easy to write large amounts of code.

      Oh dude, soooo true (: You should've been modded insightful, I think.

    13. Re:Perfomance by Anonymous Coward · · Score: 0

      Java's strength is in making it easy to write large amounts of code that do absolutely nothing. There, I fixed that for you...

    14. Re:Perfomance by ultranova · · Score: 1

      With 6.3 megs of source my guess is the guy from Space Oddessy would say "My God! It's full of bloat!"

      Maybe. But then again, the JRE alone has a compiler (the JIT one), an interpreter, class correctness checker, and the whole Java class library which contains quite a bit of native code, so at least part of it should be included in that figure. The JDK adds another compiler (source ->> bytecode) and some tools.

      6.3 megs isn't actually much when you start implementing a runtime environment. The compiled form of the C library in my machine is 6.3 megs.

      I would be incredibly surprised if it was speedy. I wonder how many of those lines are "NOP"? How many of them are comments? How many are actual, once working code that has been commented out?

      Size of code being large doesn't neccessarily mean that any particular code path is long, just that there are many of them. For example, adding a JIT compiler will make a virtual machine faster, but also increase code size.

      --

      Forget magic. Any technology distinguishable from divine power is insufficiently advanced.

    15. Re:Perfomance by ncc74656 · · Score: 1

      Huh? The whole project is 6.5 million lines. 4% comes out to 260,000 lines according to my calculator.

      The way I read the summary, it sounds like the "6.5 Mloc" referred to the 4% that had to be rewritten, not the entire system. That would put the entire system somewhere around 163 Mloc (which is still a long way from the GP's 8 Gloc).

      --
      20 January 2017: the End of an Error.
    16. Re:Perfomance by Reverend528 · · Score: 2, Funny

      which is still a long way from the GP's 8 Gloc

      AFAIK, GP was making a joke.

      Sincerely,
      GP

    17. Re:Perfomance by master5o1 · · Score: 1

      I have it also and on *something* I tried I couldn't read any text :(

      --
      signature is pants
    18. Re:Perfomance by dave87656 · · Score: 1

      Lately I've been having problems with Fonts between platforms, even with Sun's JRE. I think some fonts are not available on all platforms. Unfortunately, I can't seem to find a common fixed-sized font between the three (Open Solaris, Linux and Windows). "Monospaced" was yielding different results between the three.

      As for not being able to read any text at all. Wow, that is a definite show-stopper.

    19. Re:Perfomance by cheesybagel · · Score: 2, Funny

      Actually I believe they got sockets right... it only took them 2 or 3 iterations of the API. :-)

  3. Mono needs a similar testsuite. by Anonymous Coward · · Score: 5, Insightful

    If Mono wants to ever become suitable for enterprise use, it will need a testsuite and compatibility kit like this. One of the main benefits of Java is the stringent standards that implementations must adhere to. This brings a level of predictability that we just can't get from .NET or Mono. And for huge enterprise apps, that predictability is totally necessary.

    1. Re:Mono needs a similar testsuite. by Funks · · Score: 2, Insightful

      If Mono wants to ever become suitable for enterprise use, it will need a testsuite and compatibility kit like this. One of the main benefits of Java is the stringent standards that implementations must adhere to. This brings a level of predictability that we just can't get from .NET or Mono. And for huge enterprise apps, that predictability is totally necessary. And you believe that it would be in Microsoft's best interest to create a .NET platform TCK?
    2. Re:Mono needs a similar testsuite. by Saint+Stephen · · Score: 1

      On Windows machines, .NET is hugely predictable :-) Microsoft is "not bad" for actually getting stuff done. In the last few years, I've done SQL server, Oracle, and lastly DB/2 running on an AS/400, all from C# using pretty much the same techniques. It gets the job done, enterprise-wise.

    3. Re:Mono needs a similar testsuite. by Anonymous Coward · · Score: 0

      Yeah, Mono is an necessary evil for Microsoft.

      When the time comes, Mono won't be a .NET clone anymore. It will be a clone of the old .NET, totally incompatible with the new .NET.

      Although, considering Mono is a good two major revisions behind the reference implementation at this point, it may happen sooner than Microsoft anticipates. That may slightly limit Microsoft's tactical advantage when it comes to crushing open source.

    4. Re:Mono needs a similar testsuite. by DickBreath · · Score: 3, Funny
      Mono already has a much simpler compatibility test.
      • Does it run on Windows? (Check)
      • Does it have poisonous patents? (Check)
      Okay, it passes.
      --

      I'll see your senator, and I'll raise you two judges.
    5. Re:Mono needs a similar testsuite. by oldhack · · Score: 1

      I think .NET's main adv. over Java is its interop with Windows native services (Win32, COM, etc.) that derives from tight coupling with Windows, and MS isn't trying much to hide this. The Mono project must amuse the MS .NET team a good deal.

      --
      Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
    6. Re:Mono needs a similar testsuite. by neuromancer23 · · Score: 1

      Hmmm... I don't think Mono or anything else will ever be a competitor of Java. Even if you discount Java's superior performance, security, stability, superior APIs that are decades ahead of anything at microsoft, and vast amounts of open-source libraries, the Mono project if it wants to maintain compatibility with .NET will always be held mercy to the whims of Microsoft.

      The real benefit of Mono: .NET is going to Microsoft. Once all Windows applications are written in .NET, why would anyone want to use Windows?

      Factoid:

      Did you know? The term "Microsoft" was originally Bill Gates' pet name for his penis.

    7. Re:Mono needs a similar testsuite. by Anonymous Coward · · Score: 0

      Is it total fucking shite? (Checkeroonie)

    8. Re:Mono needs a similar testsuite. by Anonymous Coward · · Score: 0

      On Windows machines, .NET is hugely predictable :-) ... until the new, improved version comes out with completely incompatible core features a la RDO, ADO, DAO, DOA or their SOAP interfaces, etc. etc. etc.

      Been there, done that, bled heavily. Swore it off.

    9. Re:Mono needs a similar testsuite. by Anonymous Coward · · Score: 4, Informative

      Even if you discount Java's superior performance,
      I'm pretty sure .NET has Java beat in several areas. For example, generics. In Java generics are just syntactic sugar for casting everything from java.lang.Object to something else. Each cast is a runtime type check, which comes at a performance penalty that I don't believe is trivial. .NET actually generates unique code without that casting.

      superior APIs that are decades ahead of anything at microsoft,
      APIs, maybe, I don't know, but language features, definitely not. I don't use C# really, but even as someone with only a passing familiarity with it I can name a few things about it that make it seem much more productive to work with than Java:
      • Support for generics is "real" rather than an afterthought, mentioned above.
      • Using C# delegates for closures is syntactically much nicer than anonymous classes in Java.
      • Accessors in C# actually make syntactic sense, where in Java everybody writes ugly statements like foo.setBar(true) (and it gets more complex, verbose, and uglier than this example, too).
      • C# has yield iterators, i.e. real iterators like in Python. Try writing an iterator in Java for a tree structure. You pretty much have to think about breaking it into a state machine. In a language that has real support for iterators it's as simple as writing your standard-issue traversal function.
      • C# has type inference in declarations with an initializer, eg. var foo = new SomeVeryLongClassName() and foo ends up with the right type
      These are just a few. I'm sure people who are more familiar with C# than I am can name more.

      For the record, the kind of coding I do is much more geared towards lower level stuff, so I don't use C# or Java much at all. But I'm aware of the features of both, and I definitely would say hands down that between the two major high-level, VM languages, C# is the better one. It is definitely in the best interest of free software and open source to replicate some of its strong points over Java. Unfortunately Microsoft has a credibility gap, so a lot of people dismiss it without being aware of its features. Mono is an okay start, but still lacking...
    10. Re:Mono needs a similar testsuite. by IdeaMan · · Score: 1

      Man I'd love to have some real clean examples of each of those, just so I can improve my coding.

      --
      They ARE out to get you simply because They are in it for themselves and they don't care about you.
    11. Re:Mono needs a similar testsuite. by ADRA · · Score: 2, Insightful

      1. "Support for generics is "real" rather than an afterthought, mentioned above."

      Java support for generics was made with a backwards compatability wrapper so that all the API's are still compatible with java 1.5. This is a really big deal in my day job, since our company still codes for 1.4. I think you can look it up and find that Sun will move generics into runtime when there aren't the worries about backwards compatability. Since .NET has no backwards compatability, there's no issue there.

      4. How is IEnumerator different from Java's java.lang.Iterable?

      Or do you mean the benefit of hacks like quoted from OnDotNet?

      public IEnumerator GetEnumerator()
      {
          yield return "Who";
          yield return " is";
          yield return "John Galt?";
      }

      foreach ( string s in new foo )
      {
            Console.Write(s);
      }

      You still need to order which items are iterated over even if C# avoids needing to force you to actually store the iteration number somewhere.

      5. I think this is absolutely the worst thing you could possibly do being allowed or not, having invariant variable are just evil. Am I missing the difference between this and java's "Object a = new SomeReallyBadDefinition();"
      Does the same apply to var foo = callThisAmbiguousReturnTypeMethod() too? Regardless, this whole idea is ugly to me.

      --
      Bye!
    12. Re:Mono needs a similar testsuite. by Anonymous Coward · · Score: 1, Informative
      For the iterators, think something more like this:

      public class TreeNode : IEnumerable
      {
            TreeNode left, right;
            int data;

            public IEnumerator GetEnumerator()
            {
                  if (left != null)
                        foreach (int i in left)
                              yield return i;

                  yield return data;

                  if (right != null)
                        foreach (int i in right)
                              yield return i;
            }
      }
      Code is simple and readible. Last time I tried to rewrite something like this in Java it was kind of a headache and the resulting code was slower.

      Am I missing the difference between this and java's "Object a = new SomeReallyBadDefinition();"
      You can't call any interesting methods on Object. That feature is just to save some typing, though. IIRC, C++0x will introduce something similar like this to C++.
    13. Re:Mono needs a similar testsuite. by setagllib · · Score: 1

      At this point it wouldn't even surprise me if Mono was rebased on OpenJDK. OpenJDK has a vastly superior garbage collector and JIT engine, and just generally a lot more maturity and skill in its implementation. Mono can reuse a lot of that technology without breaking compatibility with .NET, and then Mono might even become worth using. Until then, we have OpenJDK itself.

      --
      Sam ty sig.
    14. Re:Mono needs a similar testsuite. by jkroll · · Score: 1

      C# has yield iterators, i.e. real iterators like in Python. Try writing an iterator in Java for a tree structure. You pretty much have to think about breaking it into a state machine. In a language that has real support for iterators it's as simple as writing your standard-issue traversal function. Unless you are picking a bad example, I still don't see any purpose to this.

      Of course in Java you can do that contrived example as TreeSet.iterator( ), so it really doesn't take any significant code using the basic libraries in the language.

      Your type inference is really just shorthand, I don't really see that as an advantage in any significant way either.

      C# and Java are now both heavily plagiarized from each other. If you are explicitly coding for Windows, C# has the advantage that it mimics the underlying Windows API. If your code ever has to run anywhere else, Java is probably the better choice. Unfortunately I think Java picked up a few of the bad ideas from C# in the last couple of revisions, but that's just my opinion.

    15. Re:Mono needs a similar testsuite. by aeoo · · Score: 1

      Unfortunately Microsoft has a credibility gap, so a lot of people dismiss it without being aware of its features. No. A lot of people dismiss it while being fully aware of some technically neat features that .NET has. I can't recall it now, but .NET is not all peaches and roses -- I've heard language complaints against it that worked well in Java.

      The conditions under which you are allowed to use some software are just as important as the software itself. What is the point of .NET's neat features if it's married to Microsoft? Mono is nowhere close in terms of performance and support to a first-class open source solution such as OpenJDK, so Mono is not an answer to this.

      If Microsoft came to its senses and GPL'ed .NET, all the resistance to it would vanish within a day. I guarantee it. And I do mean GPL and not some anal-retentive "shared source" crap that Microsoft likes to use.

      Microsoft has shown that it's a terrible and unreliable company time and time again. It simply doesn't matter how good .NET is technically because Microsoft is just a very shitty coding project partner.

      If I had to chain myself to a vendor, I'd rather pick Sun or Oracle than Microsoft. I wouldn't even pick Apple.

    16. Re:Mono needs a similar testsuite. by Planetx_123 · · Score: 1
      Whoever said:

      superior APIs that are decades ahead of anything at microsoft
      Clearly has NO idea what he is talking about.
      1. Has he used NIO?? Memory mapped files are useless because of the ridiculous API decisions they made (see #2 RFE on Sun's forums)
      2. What about the lack of a good async file I/O (or Async anything!)?? Delegates are elegant, and very useful.
      3. What about the lack of a rational file system abstraction!! So what "File" are you, canonical or abstract ? Are you a directory or a file...?
      4. What about the ridiculous decision to make all of the original collections thread-safe a.k.a. Vector!?
      5. Date, Calendar, and the case of the frustrating timezones!! Their date API has been terribly designed and released TWICE now! .NETs is excellent (TimeSpan)

      Thankfully, in Java5 they fixed alot of the most embarassing problems: concurrency API, missing assert, missing enum, missing string format, etc, but their decision of Generics is just so frustrating. I understand their decision, but I just disagree. They believe that everything is based on "backwards compatibility". Since they believe that everyone runs on linux and enjoy dealing with PATH variables and other archaic crap, you have to tip toe when you have multiple versions of JREs installed. So in this sense, they are right to care! Who wants to deal with the frustrations of multiple JRE compatibilty issues!! What I LOVE is that many companies "solution" to this is to package the exact JRE with their solution. So eventually our computers will have 42 separate (almost) duplicate installations of JREs--yep they solved that one alright! .NET decides correctly what version to run, and multiple versions are only installed once without hassle. Do not underestimate this problem, my company has spent tons of hours diagnosing rediculously stupid problems with PATH variables and multiple versions of JREs installed- it costs money, which is kind of part of this "software" thing.

      .NET has its own set of problems, but when it comes to APIs, Microsoft has done a fantastic job of creating an elegant set of APIs. Also, since they have solved the version compatibility problem- they aren't so afraid to introduce keywords into the language. I fully understand why Josh Bloche doesn't want to introduce new keywords (my java == your java, everyone reads with ease), but come ON a couple of well chosen keywords would probably make things MORE readable!

      Where Java succeeds is its rich codebase and 3rd party components and tools- the community involvement make it the only viable environment for cutting edge, mission critical, enterprise development in my opinion (hello Terracotta and GigaSpaces + billions of other amazing components). This also, ironically, is one of its biggest problem-- with 40 solutions to the same problem, different groups inevitably choose different frameworks, which makes the code less readable (maintainable). Microsoft is a bottleneck, and thus it always ends up late to the party, but with a better API that learned from the mistakes of its predecessors. However, I'm still waiting for Visual Studio to catch up with Eclipse...

      So don't dare argue Java's API especially using terms like "decades ahead", because you just look stupid and cleraly inexperienced. Java has had decades (unlike .NET) and it still has fundamental problems (see #5) that are so frustrating!! Some of the mistakes are just helarious, and while .NET contains its own silly mistakes- MS has been innovating at 2x the pace of Java, resulting in a much more rich/elegant language.

      Steve

    17. Re:Mono needs a similar testsuite. by Anonymous Coward · · Score: 1, Insightful

      Even if some features are better done in C# than in Java, most language features and API have been clearly copied. The facts that C# implemented them better is only because it's a newer language than Java.

      But:

      - The Stream classes of C# are badly designed (simply because a good design could not be easily wrapped around the underlying OS) and are no comparison to the IO classes in Java.
      - In .NET 1.0 using the SMTP API was not problem as long as you had IIS installed with CDO.
      - In .NET 1.0 kernel caching mode (IIS feature) was switched on by default, this caused that some customers of my client saw personal information of other customers. And Microsoft would not help because we where only a standard member not a Gold Partner. Only a year after this problem they came with a solution.

      C# programming = Microsoft programming = extending Microsoft software and products.

      Java programming is implementing software using standardised API and letting the customer decide on what kind of product they deploy it on.

    18. Re:Mono needs a similar testsuite. by Planetx_123 · · Score: 3, Informative

      For #1, it doesn't matter-- without runtime help you loose half of the power of generics. In either case you aren't gaining anything. Your company is still writing without generics. If a .NET shop wanted to work with 1.1 then they wouldn't write generics either... no difference. The problem is forward compatibility. You "could" write with generics and they could work with non-generified JREs. In the trade-off I would prefer the runtime benefits (et al) any day of the week.

      For #4- you don't understand what you are talking about. For good uses of yield (or closures) go ask one of the millions of Ruby fans that are convinced its the best thing ever. Note that your example of "Who is John Galt" is stupid. You can write bad code in any language-- programming languages aren't meant to "fix" stupid.

      For #5- you clearly don't understand how type inference works. This is still static typing- its just that the type is inferred by the compiler (obviously at compile time) instead of having the coder type extra, unnecessary characters. It is NOT a "variant" type or widened type. It is only syntactic sugar to save you some keystrokes when declaring and initializing in the same statement (which should almost be required). No one is arguing against types or interfaces, etc. This is only to help reduce some superfluous typing. And YES this is in C++0x as well.

    19. Re:Mono needs a similar testsuite. by rreyelts · · Score: 2, Informative

      I'm pretty sure .NET has Java beat in several areas. For example, generics. In Java generics are just syntactic sugar for casting everything from java.lang.Object to something else. Each cast is a runtime type check, which comes at a performance penalty that I don't believe is trivial. .NET actually generates unique code without that casting.
      You should read John Rose's blog for nice comparisons between .NET and the JVM. You give a perfect example of something that would cost .NET in performance, but that the JVM optimizes out at runtime (casts). Don't take my word for it. Put together a micro-benchmark and see for yourself. If you download a fast-debug build of the JVM, you can even see the machine code it generates for a particular method (-XX:+PrintOptoAssembly).

      APIs, maybe, I don't know, but language features, definitely not.
      If you want a nicer language on the JVM, use Scala.
    20. Re:Mono needs a similar testsuite. by Anonymous Coward · · Score: 0

      If it takes a team of you significant time to work out some path variables, I think you'd be better suited to a management role...

    21. Re:Mono needs a similar testsuite. by Anonymous Coward · · Score: 0

      What patent is mono covered by?


      It's actually starting to become quite a compelling platform for building Linux applications. Performance is still an issue but it's improving and already good enough for a lot of desktop apps.

    22. Re:Mono needs a similar testsuite. by davebert · · Score: 2, Informative

      (1) Type erasure in java generics makes writing reflective code a nightmare.

      (4) Support for iterators in the language makes them a lot easier to write

      (5) - in your example, a is still strongly typed, it's just that you don't have to tell the compiler what it is. The dotnet rules wouldn't let you have an overloaded function such as callThisAmbiguousReturnTypeMethod that differ only in their return type, so this wouldn't be an issue.

      It's also the only way to declare a variable with an anonymous type, e.g.

      var x = new {Foo = "X", Bar = 0};

      (and yes, Foo and Bar are also strongly typed)

      Anonymous types can only be used within the method in which they defined, and are very useful at cutting down on the profusion of crappy little data type class that you'd otherwise end up having to write every time you need a simple tuple. Personally, I use them a lot for projections over LINQ expressions.

      Oh, and don't forget c# lambda expressions which can be easily be decomposed into the equivalent expression tree.

    23. Re:Mono needs a similar testsuite. by optevo · · Score: 2, Informative

      I agree that Java is showing its age. C# has the advantage that is was designed several years after Java and learnt from its mistakes. Also, Java had a philosophy (for quite a while although it seems to be changing) that language changes should be made quite conservatively. However, there are some languages that run on a JVM that integrate perfectly with the Java API but have all the C# features you mention (and many more). I highly recommend looking both at JRuby and Scala.

    24. Re:Mono needs a similar testsuite. by RAMMS+EIN · · Score: 1

      ``This brings a level of predictability that we just can't get from .NET or Mono. And for huge enterprise apps, that predictability is totally necessary.''

      Perhaps, but Java's standard isn't even that high. Many things are unspecified or implementation-dependent, and there can be and have been significant and incompatible changes between releases. I don't think it's actually significantly better than many open source efforts (that is, efforts that originated in the open source community).

      Still, a complete, open-source implementation of Java is a great boon. Kudos to everyone who made this happen.

      --
      Please correct me if I got my facts wrong.
    25. Re:Mono needs a similar testsuite. by R3d+Jack · · Score: 1

      As someone who HAS programmed in .NET and who is a Java developer, my first comment is that people who haven't and aren't shouldn't be touting the merits of languages they know little about. Second, C# does have areas where it is superior to Java, but I certainly won't say C# is superior. Here's my bottom line: For Windows only software, use .NET, and C# has definite advantages as a .NET language. For multi-platforms, including Windows, use Java. Bottom line, both environments and languages are strong and equivalent in many ways.

    26. Re:Mono needs a similar testsuite. by Xabraxas · · Score: 1

      Although, considering Mono is a good two major revisions behind the reference implementation at this point, it may happen sooner than Microsoft anticipates. That may slightly limit Microsoft's tactical advantage when it comes to crushing open source.

      You seem to be a little confused by the version numbers. Check out the Mono project's website to see where Mono development is at. Some parts of .Net 3.5 have already been implemented.

      --
      Time makes more converts than reason
  4. bfd by speedtux · · Score: 1, Insightful

    So, Sun's own codebase passes their own compatibility suite. BFD.

    If after more than a decade, there is not a single, independent, compliant Java implementation, then there is evidently something wrong with the Java platform.

    1. Re:bfd by PinkPanther · · Score: 4, Interesting
      How does having an "independent" (whatever that means) implementation make a platform "right" (or rather, lack of one make it "wrong").

      What is it that is "wrong" in the platform? The fact that the base implementation is solid enough that few others found need to rewrite that wheel?

      --
      It's a simple matter of complex programming.
    2. Re:bfd by pmontra · · Score: 5, Informative

      Actually, Sun's own codebase and a 4-5% of rewritten code passes Sun's compatibility suite.

      TFA is about that 4-5% which was encumbered by patents (? the article doesn't go into details) and has been rewritten to make all the JDK free. That should be enough to finally get Debian include Java in their distributions.

    3. Re:bfd by Anonymous Coward · · Score: 5, Informative

      So, Sun's own codebase passes their own compatibility suite. BFD.

      If after more than a decade, there is not a single, independent, compliant Java implementation, then there is evidently something wrong with the Java platform. What in the world are you talking about?

      There has been multiple compliant java-implementations for years now.

      IBM's JDK (which is their own codebase).
      and ORACLE's JDK (BEA JRockit)

      both of which passed the Java TCK and can claim Java compatibility and compliance.

      As for performance, the OPENJDK is based primarily on SUN's JVM code, hence it has the exact same optimizations (same HOTSPOT, and etc). Only a small majority of the code was replaced with open source alternatives which doesn't affect performance.

    4. Re:bfd by oldhack · · Score: 1

      Good info. But Debian's included (don't know which branch) SUN's JDK for quite sometime now, since the change in the license of JDK, I think.

      --
      Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
    5. Re:bfd by Jah-Wren+Ryel · · Score: 4, Insightful

      What is it that is "wrong" in the platform? The fact that the base implementation is solid enough that few others found need to rewrite that wheel? Because you get people coding to the bugs of the implementation without even realizing it, since it works after all. And then eventually you reach a point where new versions don't fix the bugs because too many systems depend on them. Sound like a monopolist you know?
      --
      When information is power, privacy is freedom.
    6. Re:bfd by speedtux · · Score: 0

      Sun claims that Java is an open "standard".

      If, after a decade, nobody has managed to produce an independent, compliant, commercial implementation, then that suggests that doing so is too hard. Maybe Sun's specifications are incomplete, maybe the specs are so complex that they are too hard to implement, maybe Sun keeps changing the platform too quickly.

      Why does it matter? If Sun were to go belly-up tomorrow, there would be no compliant commercial Java implementation left.

    7. Re:bfd by DickBreath · · Score: 4, Insightful

      Question: How long did it take Wine to come up with something mostly compatible with Windows? Fifteen years?

      Have you considered that Java is almost like writing an OS? A runtime byte code, compiled form multiple source languages. Almost every service of an OS provided in a portable way. (eg, sound, video, graphics, multiple portable widget toolkits, network access, file access, system tray access, and the list goes on...)

      GNU Classpath is mostly compatible now. Much like Wine.

      --

      I'll see your senator, and I'll raise you two judges.
    8. Re:bfd by loftwyr · · Score: 1

      If Wine had had the Windows Codebase (-4%) to start with, I doubt it would have taken 15 years. They had to do it starting from scratch and with no help from the codebase it was starting with.

      OpenJDK started with 96% of Sun's Java codebase.

    9. Re:bfd by Anonymous Coward · · Score: 0

      Whoohoo! My sunoco stock is kicking ass!

    10. Re:bfd by bunratty · · Score: 1

      In addition to a JVM, you need compilers. If there's any part of Java that is complex or that there are incomplete specifications for, it may be those huge standard libraries. But doesn't Sun ship the source code to those with every JDK?

      --
      What a fool believes, he sees, no wise man has the power to reason away.
    11. Re:bfd by Anonymous Coward · · Score: 0

      That should be enough to finally get Debian include Java in their distributions.

      bob@debian > apt-cache search sun-java
      ia32-sun-java6-bin - Sun Java(TM) Runtime Environment (JRE) 6 (32-bit)
      sun-java6-bin - Sun Java(TM) Runtime Environment (JRE) 6 (architecture dependent files)
      sun-java6-demo - Sun Java(TM) Development Kit (JDK) 6 demos and examples
      sun-java6-doc - Sun JDK(TM) Documention -- integration installer
      sun-java6-fonts - Lucida TrueType fonts (from the Sun JRE)
      sun-java6-javadb - Java(TM) DB, Sun Microsystems' distribution of Apache Derby
      sun-java6-jdk - Sun Java(TM) Development Kit (JDK) 6
      sun-java6-jre - Sun Java(TM) Runtime Environment (JRE) 6 (architecture independent files)
      sun-java6-source - Sun Java(TM) Development Kit (JDK) 6 source files
      openoffice.org - OpenOffice.org Office suite
      ia32-sun-java5-bin - Sun Java(TM) Runtime Environment (JRE) 5.0 (32-bit)
      sun-java5-bin - Sun Java(TM) Runtime Environment (JRE) 5.0 (architecture dependent files)
      sun-java5-demo - Sun Java(TM) Development Kit (JDK) 5.0 demos and examples
      sun-java5-doc - Sun JDK(TM) Documention -- integration installer
      sun-java5-fonts - Lucida TrueType fonts (from the Sun JRE)
      sun-java5-jdk - Sun Java(TM) Development Kit (JDK) 5.0
      sun-java5-jre - Sun Java(TM) Runtime Environment (JRE) 5.0 (architecture independent files)
      sun-java5-source - Sun Java(TM) Development Kit (JDK) 5.0 source files

    12. Re:bfd by jfbilodeau · · Score: 1

      If I'm not mistaken, BEA JRockit is a licensed derivative of Sun's source optimized for WebLogic.

      --
      Goodbye Slashdot. You've changed.
    13. Re:bfd by PinkPanther · · Score: 1
      But this itch obviously is not powerful enough to cause the community to scratch.

      So is it really a matter of immaturity or wrongness? Or is someone going to claim that the issue is that Java just isn't in use enough?

      --
      It's a simple matter of complex programming.
    14. Re:bfd by PinkPanther · · Score: 4, Insightful
      Or maybe its that the default implementation is really quite good.

      Which it is.

      Could it be improved? Sure it could...name a single software product that couldn't be. But there are many billions of dollars of IT projects that depend on Java, so trying to pass it off as immature, incomplete, incorrect or insufficient is nonsense.

      --
      It's a simple matter of complex programming.
    15. Re:bfd by Anonymous Coward · · Score: 0

      There are many billions of IT projects out there written using Visual Basic 6. I guess no one should try and pass Visual Basic off as immature, incomplete, incorrect, or insufficient either, right?

    16. Re:bfd by cos(0) · · Score: 1

      Sounds dangerously like Perl.

    17. Re:bfd by monkeythug · · Score: 1

      I believe you will find these packages are in Debian's 'non-free' repository :-(

      --
      Don't you wish you hadn't wasted 3 seconds of your life reading this sig?
    18. Re:bfd by speedtux · · Score: 1

      Well, if those are your criteria for an "open standard", then Microsoft Windows and .NET are "open standards" as well: their default implementations are quite good as well, everything's documented, and there are billions of dollars of IT projects that depend on them.

      To me, an "open standard" is one that other people can and do implement, so that I have a choice of vendors and security against any one vendor doing something stupid. That is what Sun promised, but they haven't delivered.

    19. Re:bfd by speedtux · · Score: 1

      But this itch obviously is not powerful enough to cause the community to scratch.

      The community has scratched: a lot of people have abandoned Java, and a lot of people have worked on creating third party Java implementations, albeit ones that haven't been certified.

      There's no question that Java is useful to many people, just like there is no question that Windows is useful to many people. But neither Java nor Windows are open standards. And for Sun to proclaim compatibility of their own implementation with their own test suite is ridiculous and masturbatory.

    20. Re:bfd by aled · · Score: 1

      Sun claims that Java is an open "standard".

      If, after a decade, nobody has managed to produce an independent, compliant, commercial implementation, then that suggests that doing so is too hard. Maybe Sun's specifications are incomplete, maybe the specs are so complex that they are too hard to implement, maybe Sun keeps changing the platform too quickly.

      Why does it matter? If Sun were to go belly-up tomorrow, there would be no compliant commercial Java implementation left.


      BTW, how many independent Perl implementations are there?
      --

      "I think this line is mostly filler"
    21. Re:bfd by speedtux · · Score: 1

      There has been multiple compliant java-implementations for years now.

      RTFP. Those are not independent Java implementations, they are licensed derivatives.

      Your argument is like saying that Microsoft Windows is an open standard because both HP and Dell ship it.

    22. Re:bfd by speedtux · · Score: 1

      Exactly. So, if Wine and Microsoft's copious documentation don't make Windows an "open standard", why should Sun be able to claim that Java is an open standard?

    23. Re:bfd by Anonymous Coward · · Score: 0

      > TFA is about that 4-5% which was encumbered by patents

      Copyrights. It's just proprietary third party code that Sun doesn't own. If it were patented, then any rewrites would very likely be just as encumbered, depending on how broad the patent was.

    24. Re:bfd by kjots · · Score: 1

      If Wine had had the Windows Codebase (-4%) to start with, I doubt it would have taken 15 years.

      You're right; if they had the Windows codebase, it probably would have take twice as long!

    25. Re:bfd by speedtux · · Score: 2, Insightful

      BTW, how many independent Perl implementations are there?

      None. There are also no "Perl compatibility kits". Perl is licensed under the AL, so if Larry Wall falls off a cliff, commercial users can continue to use it. Perl doesn't pretend to be something it is not.

      So, what does your question have to do with Java?

    26. Re:bfd by setagllib · · Score: 2, Informative

      I also disagree with the great cost of the Java compatibility kit, but having it there at all is a great idea. It's basically one big unit test harness, and we all know unit testing is a good thing when done right. So now Sun have a unit testing framework they can use to ensure new releases really do maintain backwards compatibility, and one that alternate implementations can use to have a reasonable confidence their version of Java actually works.

      --
      Sam ty sig.
    27. Re:bfd by ciggieposeur · · Score: 1

      IBM's JDK (which is their own codebase).

      It is indeed IBM's codebase, but it started out as Sun's JDK and periodically is refreshed with new code from Sun, so it is in fact a derivative implementation. (Disclaimer: I used to work for IBM and Hursley's JDK was always about a year behind Sun's, but it was often more stable on Linux and Windows and of course it was the only decent one for AIX.)

      The closest independent Java implementation out there is GNU Classpath combined with one of the various JVM's, but AFAIK it still hasn't passed the Java certification.

    28. Re:bfd by setagllib · · Score: 1

      I was really hoping GNU Classpath was mostly compatible, and I still test every single Java project against it, but I still find even basic things that work in Java 1.6 don't work in even the latest GNU Classpath.

      Example: new String(byte[], Charset)
      No sir, no such constructor.

      It supports the String version (providing the charset name) because more code uses that, but the "correct" way to use it, with a real Charset object, is not supported. It would probably be a few minutes of work to change it, but obviously they're too busy with other things.

      Java2D programs barely run at all. Swing is laughable. On the other hand, SWT generally runs perfectly well because it can be incorporated directly, not cloned like Swing.

      --
      Sam ty sig.
    29. Re:bfd by Anonymous Coward · · Score: 0

      Debian has rejected it several times, the current just isn't up to our copyright/licence and technical standards.

    30. Re:bfd by speedtux · · Score: 1

      Sure, it's a good unit test kit.

      and one that alternate implementations can use to have a reasonable confidence their version of Java actually works.

      But there are no "alternate implementations" that have passed the test kit, and Sun has been putting up one roadblock after another for alternate implementations to even get tested or use this software to demonstrate compatibility.

      Sun doesn't want alternate implementations, and the sun test kit is a sham.

    31. Re:bfd by HJED · · Score: 0

      Sun claims that Java is an open "standard". If, after a decade, nobody has managed to produce an independent, compliant, commercial implementation, then that suggests that doing so is too hard. Maybe Sun's specifications are incomplete, maybe the specs are so complex that they are too hard to implement, maybe Sun keeps changing the platform too quickly. Why does it matter? If Sun were to go belly-up tomorrow, there would be no compliant commercial Java implementation left. if sun was to go belly up tomorrow then the OPEN jdk project code under GPL will be put up somewhere else probably
      --
      null
    32. Re:bfd by speedtux · · Score: 1

      How does having an "independent" (whatever that means)

      It would mean that someone else has managed to implement the specifications without using code from Sun. If there are no independent implementations a decade after a specification has been written and made public, it doesn't makes sense to call the platform an "open standard".

      implementation make a platform "right" (or rather, lack of one make it "wrong").

      It means that the way things are, Sun Java is really not much different from Microsoft Windows: a platform with a single implementation that's driven by one group of developers controlled by a single big company.

    33. Re:bfd by sentientbrendan · · Score: 1

      >Question: How long did it take Wine to come up with
      >something mostly compatible with Windows? Fifteen years?
      There's no way to answer that question, because wine is *still* not mostly compatible with windows. It implements a small subset of win32 that lets them run a few versions of office and some other random applications... Just because they released 1.0 doesn't mean it is "mostly compatible."

      >GNU Classpath is mostly compatible now. Much like Wine.
      Not Even Close. Just, no. Have you ever actually *used* GNU classpath? Specifically, swing and awt are quite lacking, and probably a number of other miscellaneous things.

      That's not to say you can't use it if you only happen to need the subset of functionality that classpath supports. I've written small software for embedded devices where I only used pretty basic functionality that happened to be available. Good luck if you need something more than that.

      There's been little incentive to build a replacement for sun's implementations of the java libraries since they can just be had from sun or a licensee for most platforms. I don't think anyone seriously used the old open source java stack, including gnu classpath, for anything except maybe embedded devices. it shipped with some linux distros like redhat, but anyone who's not just joking around immediately replaces that with sun java.

      Generally, systems with multiple mutually compatible implementations from different vendors are rare. An effort towards standardization by all the major developers is required.

      Open standards are a good idea, but difficult to make work for complicated systems.

      Sun has made a good effort towards standardization, but has almost unintentionally quashed alternative implementations by simply being too successful as the primary vendor of java.

    34. Re:bfd by aled · · Score: 1

      OpenJdk is GPL'ed. So what happens if Sun falls off a cliff?

      --

      "I think this line is mostly filler"
    35. Re:bfd by Tim+C · · Score: 1

      Your argument is like saying that Microsoft Windows is an open standard because both HP and Dell ship it.

      If HP and Dell rewrote parts of Windows to better suit their own needs then you'd have a point. As it is, neither IBM nor BEA (now Oracle unfortunately) simply slapped a logo on Sun's JDK and shipped it with their own products.

    36. Re:bfd by DuckDodgers · · Score: 1

      1. Sun has a free (open source?) set of complete tests you can run to check compatibility between your implementation of the 1.6 JDK and the standard. Microsoft certainly does not.

      2. BEA and IBM have successfully written their own implementations of the JDK 1.6 that do pass said tests. Wine is at version 1.0 and is an unbelievable accomplishment considering how small the development team is versus the monstrous resources Microsoft used to create Windows. But Wine 1.0 still has major and minor compatibility problems with hundreds of programs. You can't just slap the Office 2007 or Crysis installer DVD into your drive and have everything run on Wine.

      On the other hand, as complicated as Java is, I would definitely consider a working implementation of the Windows API a much harder task to tackle, even if Microsoft did make it easy.

    37. Re:bfd by petermgreen · · Score: 1

      writing a java virtual machine is not a very big big deal (writing a fast one is but that isn't really a java specific issue more that fast VMs in general are hard to write) and several groups have indeed done it.

      writing a java compiler isn't a big deal either.

      what is a huge deal is writing a complete set of java class libraries. Java's standard library is HUGE and very complex and it's documentation ranges from mediocre to terrible.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    38. Re:bfd by Anonymous Coward · · Score: 0

      Bad curves, but the correct ones aren't much better.

    39. Re:bfd by PinkPanther · · Score: 1
      Nothing in the definition of "open standard" says that "someone else" has to implement it.

      Other people can create an alternative Java. The language, byte code and API specs are all published; there is an initial implementation that others can build and/or test and/or reverse engineer. That someone else hasn't gone and implemented the ENTIRE JAVA SYSTEM on their own does not detract from the availability and openness of the spec.

      --
      It's a simple matter of complex programming.
    40. Re:bfd by speedtux · · Score: 1

      OpenJdk is GPL'ed. So what happens if Sun falls off a cliff?

      Then there will be no commercially licensable version of Java at all anymore. And that's a problem.

    41. Re:bfd by speedtux · · Score: 1

      1. Sun has a free (open source?) set of complete tests you can run to check compatibility between your implementation of the 1.6 JDK.

      They most certainly do not. There was a big stink about that fact with the Apache developers.

      2. BEA and IBM have successfully written their own implementations of the JDK 1.6 that do pass said tests.

      No, they have not. Both of them are licensed derivatives of Sun's code.

    42. Re:bfd by speedtux · · Score: 1

      Nothing in the definition of "open standard" says that "someone else" has to implement it.

      Sun's own definition says so:

      http://www.sun.com/software/standards/definition.xml

    43. Re:bfd by speedtux · · Score: 1

      As it is, neither IBM nor BEA (now Oracle unfortunately) simply slapped a logo on Sun's JDK and shipped it with their own products.

      Quite right: after IBM was forced to license Java from Sun, they had to spend several years cleaning up the code. That only means that Sun Java, in addition to being proprietary, also requires a good deal of cleanup.

    44. Re:bfd by DuckDodgers · · Score: 1

      Thanks for the correction.

    45. Re:bfd by aled · · Score: 1

      OpenJdk is GPL'ed. So what happens if Sun falls off a cliff?

      Then there will be no commercially licensable version of Java at all anymore. And that's a problem.

      why? Apache Harmony with enough support from IBM and ORACLE could be one. Someone could buy SUN assets. And they have invested enough in Java to be interested.
      And lack of commercial licenses hasn't stopped Redhat or Ubuntu of offering GPL'd Linux, isn't it?
      --

      "I think this line is mostly filler"
    46. Re:bfd by speedtux · · Score: 1

      why? Apache Harmony with enough support from IBM and ORACLE could be one.

      Apache Harmony is not a commercially licensable version of Java, it isn't a version of Java at all because Sun doesn't let it be tested.

      Someone could buy SUN assets. And they have invested enough in Java to be interested.

      Or maybe they are interested in killing it, if it's Microsoft.

      And lack of commercial licenses hasn't stopped Redhat or Ubuntu of offering GPL'd Linux, isn't it?

      If it didn't matter for Java, Sun wouldn't be offering commercial Java licensing, and there wouldn't be any licensees.

      You can make excuse after excuse, but the fact remain: no matter how swell you think the current situation with Java is, Java is not an open standard, not even by Sun's own definition. In fact, the openness of the Java platform is little different from Microsoft Windows or .NET

    47. Re:bfd by aled · · Score: 1

      why? Apache Harmony with enough support from IBM and ORACLE could be one.

      Apache Harmony is not a commercially licensable version of Java, it isn't a version of Java at all because Sun doesn't let it be tested.

      Oracle used to take Apache Httpd and rename it as Oracle Httpd. Apache license allows you that. Then you can sell under your commercial license. If SUN doesn't test it there will be some fragmentation, but you think all the companies in the world that have Java systems will just switch to PHP overnight in that case? not likely. A clean room Java version from IBM will be readily accepted as long as it shows compatibility with major applications.
      AFAIK you can sell licenses as you please for your own Java version, as long as you don't call it Java. That is why IcedTea.
      --

      "I think this line is mostly filler"
    48. Re:bfd by ChunderDownunder · · Score: 1
      Classpath's methodology has been to progressively increase coverage of the Java class libraries based on running real-world applications, such as tomcat, eclipse and jboss which redhat wanted to bundle but couldn't rely on Sun's JRE because it did ship on all their supported architectures.

      For a number of years software was stuck using Java SE 1.4.2 - Large scale software projects tended to be fairly conservative when jumping to new 1.5 features such as generics and hence held back on using newer 1.5 and beyond APIs.

      You can check the completeness here

      So don't be surprised if coverage is best for 1.4.2. Classpath has been somewhat dormant for a year or so - many of the chief developers have been working on IcedTea.

      I wouldn't be expecting Classpath to be passing the TCK any time soon, if ever. BrandWeg may help in substituting missing classes but for implementing specific methods like your missing constructor, probably not.

      But then classpath's goal of "escaping the Java trap" by having a complete Java platform under the GPL has now been realised, so the need for anyone to 'finish' it is reduced.

    49. Re:bfd by petermgreen · · Score: 1

      debian has had sun supplied java binaries in thier non-free repositry for a while, that is certainly an improvent over not having it packaged at all but it is still far inferior to having a proper package built from source in main for a couple of reasons.

      1: non-free is not in the repositries list by default so unless someone manually edits the list they won't see it.
      2: stuff in non-free cannot be included in any of the standard installation tasks
      3: when some change in another library breaks sun java the debian guys can't really do anything to fix it.

      unfortunately there are still a few small license inconsistancies in openjdk which have been causing the debian ftpmasters to reject it.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    50. Re:bfd by setagllib · · Score: 1

      What I want to see is GCJ integrated with OpenJDK, so we can combine GCJ's native code generation with the complete official classpath. It's not too useful now that the official JVM is stupidly fast, but it can save some memory and startup time which still matter.

      --
      Sam ty sig.
    51. Re:bfd by speedtux · · Score: 1

      If SUN doesn't test it there will be some fragmentation,

      No, if Sun doesn't test it, then it's not Java.

      A clean room Java version from IBM will be readily accepted as long as it shows compatibility with major applications.

      Yes, people are finding workarounds for the fact that Java isn't an open standard, and that's good. But Java still isn't an open standard.

      AFAIK you can sell licenses as you please for your own Java version, as long as you don't call it Java. That is why IcedTea.

      The legal situation is unclear because Sun holds many patents on Java.

      In any case, such heroic efforts don't make Java an "open platform" any more than the existence of Wine makes Windows an "open platform".

    52. Re:bfd by Anonymous Coward · · Score: 0

      Debian already includes Java in their non-free repository.

  5. Re:Really ? by tritter · · Score: 1, Funny

    You mean Vista is written in Java?

  6. Re:Really ? by PinkPanther · · Score: 4, Funny

    Does this mean it consumes 2 GB of RAM to display "Hello World"???

    Man! Was that joke ever funning circa 1997...

    --
    It's a simple matter of complex programming.
  7. Language Compatibility vs. Class Libraries by KidSock · · Score: 3, Interesting

    Languange compatibility was never the main problem - it was class libraries. Java has a mountain of class libraries.

    Unfortunately most of them are complete bloat (e.g. Swing, NIO, logging ...). Each package is like a treatise on OOP and design patterns. When are people going to learn that OOP is just one tool of many?

    But Java the *language* is great. I wish that someone would create a non-bloat version of the Java class libraries. Do an analysis of important use cases, redesigned the class libraries to be much less "fluffy" and then post some metrics to show how much better it performs.

    1. Re:Language Compatibility vs. Class Libraries by jalet · · Score: 5, Funny

      > I wish that someone would create a non-bloat version of the Java class libraries. Do an analysis
      > of important use cases, redesigned the class libraries to be much less "fluffy"

      Somebody did just this already.

      --
      Votez ecolo : Chiez dans l'urne !
    2. Re:Language Compatibility vs. Class Libraries by Octorian · · Score: 3, Informative

      But at least its only a mountain :-)

      I don't know if Mono can ever catch up to the whole mountain range that .NET has bundled in. Especially since its taken far less seriously than Java by this community.

    3. Re:Language Compatibility vs. Class Libraries by snoyberg · · Score: 2, Interesting

      Why would remove features from the library make a program perform (significantly) better? Why not just avoid using those classes you consider bloated?

      --
      Thank God for evolution.
    4. Re:Language Compatibility vs. Class Libraries by CastrTroy · · Score: 4, Insightful

      I'm not sure how much more performance you could achieve simply by culling the unused stuff. Java already dynamically loads only the classes you use into memory. We have gotten to a point where people don't want to rewrite their own XML parsers, sorting algorithms, cryptography libraries, UI components, network connection handling functions, and all the other wonderful stuff provided by the .net and Java APIs. We're probably a lot better off because of it. Less time wasted writing code that someone has already written a million times. If you still want a smaller version of the JDK, there's always the Java Micro Edition Platform.

      --

      Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
    5. Re:Language Compatibility vs. Class Libraries by Anonymous Coward · · Score: 0

      Who is stopping you? It is now open source so grab the source and do whatever you want with it. No one will use it because the class libraries make Java powerful, but you will have a nice lean system that only you will use.

    6. Re:Language Compatibility vs. Class Libraries by DuckDodgers · · Score: 2, Insightful

      Aren't you talking about a social problem, not a language problem?

      Use the class libraries you like, build your own replacements for the ones you don't in Java itself or in C, and then (and here's the tricky part) convince the people you work with to only use your stuff.

      Rewriting all of the class libraries to be more syntax consistent and intuitive would be fantastic - but you break so much backwards compatibility you might as well give up and adopt Groovy or Scala.

    7. Re:Language Compatibility vs. Class Libraries by mightybaldking · · Score: 0, Troll

      This is my favourite snippet that demonstrates the java bloat:
      String xmlSystemId = new File(xmlFileName).toURL().toExternalForm( );
      String xsltSystemId = new File(xsltFileName).toURL().toExternalForm( );
      org.apache.xalan.xslt.XSLTProcessor processor = org.apache.xalan.xslt.XSLTProcessorFactory.getProcessor( );
      org.apache.xalan.xslt.XSLTInputSource xmlInputSource = new org.apache.xalan.xslt.XSLTInputSource(xmlSystemId);
      org.apache.xalan.xslt.XSLTInputSource xsltInputSource = new org.apache.xalan.xslt.XSLTInputSource(xsltSystemId);
      org.apache.xalan.xslt.XSLTResultTarget resultTree = new org.apache.xalan.xslt.XSLTResultTarget(System.out);
      processor.process(xmlInputSource, xsltInputSource, resultTree);
      When what I need is:
      XMLTransformer.transform(xmlfile, xsltFile, outputStream)
      which should be a static method.

    8. Re:Language Compatibility vs. Class Libraries by ndansmith · · Score: 1

      I wish that someone would create a non-bloat version of the Java class libraries. Do an analysis of important use cases, redesigned the class libraries to be much less "fluffy" and then post some metrics to show how much better it performs. Have it on my desk Monday morning.

    9. Re:Language Compatibility vs. Class Libraries by cecom · · Score: 0

      In fact Java the language is absurdly primitive. The culmination of cut & paste. It is the libraries that make it bearable.

    10. Re:Language Compatibility vs. Class Libraries by AKAImBatman · · Score: 5, Informative

      Source source = new StreamSource(new File(xmlFileName));
      Result result = new StreamResult(new File(xsltFileName));
       
      TransformerFactory.newTransformer().transform(source, result);
      Was that really so hard?

      If the code you posted is the best obfuscated Java code you can come up with, then I'm impressed. I've seen MUCH worse Perl, C, and even Python. Your code was at least understandable (albeit unnecessarily obtuse), thus demonstrating the unexpected readability advantages of the Java language.

      P.S. Import statements are your friend.
    11. Re:Language Compatibility vs. Class Libraries by VGPowerlord · · Score: 1

      Last time I checked, Xalan wasn't part of the Java standard library. You'll have to take this one up with Apache.

      And if you think that's bad, take a POJO and run it through Apache Axis2's Java2WDSL then that WDSL through WDSL2Java to generate the client. The generated client code is huge, somewhere in the 2-3k line range.

      --
      GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
    12. Re:Language Compatibility vs. Class Libraries by Anonymous Coward · · Score: 5, Insightful

      And as examples of bloat, you had to pick Swing, NIO and logging?!?

      Logging is a quasi-identical to Apache's log4j, indeed this caused bad feelings among log4j's authors who felt Sun should just have officialized their API. Of course the reason Sun used it as an (ahem) inspiration is that it's very good, as demonstrated by the absolutely huge number of projects using it. And you know as well as I do that rolling out your own is a common developer trait, *especially* for trivial things like that.

      NIO is brilliant. If it's too complex or low-level for you, just use the "old IO", which is *also* good - just not as low-level.

      Swing, I can understand your feeling. Although the real problem with Swing is not "bloat" as in unnecessary complex and featurefull, it's that even though it only shipped in a JDK with 1.2 (which had the Collection framework), Sun bowed to short-sighted morons who kicked a fuss when it was suggested that it be put in java.swing (instead of javax.swing), and as a result still uses the old Vector and so on.

      Generally speaking, what you call "bloat" is due to:
      - the presence of libraries *you* don't use. Guess what, other people do.
      - the provision for extensions. For instance, the java.net package is chock full of factories, abstract classes and interfaces that you seem to disdain. And indeed to 98% of developers who just use it for the net, that's all pretty pointless. The upshot is that should you require Unix or X25 sockets, you can still use the same API - I've seen it done. Sure you have to write the C code, but the Java code is all the same except the bit that gets the address. How many open-source language don't even have a common low-level DB API, forcing you to write you own single use abstraction layer when you need to target several DBs? At least with Java you know it's JDBC. Always.

      Sun's attitude towards libraries has always been, as far as Java is concerned at least, make the simple easy, make the difficult possible. To me that's good design. Of course it means that easy can be more complex than with more specific APIs. But those tend to not allow the difficult at all :-(

    13. Re:Language Compatibility vs. Class Libraries by deraj123 · · Score: 1

      Transformer transformer = TransformerFactory.newTransformer(new StreamSource(new File(xsltFileName)));
      transformer.transform(new StreamSource(new File(xmlFileName)), new StreamResult(outputStream));

      It's 2 lines, not your 1. However, what you call bloat, I call flexibility (well, and a little bit of either ignorance or deliberate misinformation - there is seldom any good reason to include the entire package name - use import statements).

      When what I need is:
      XMLTransformer.transform(xmlfile, xsltFile, outputStream)
      which should be a static method.

      This is what we call a special case. I seldom have the need to do this particular operation. If you have to do it a lot, you can write a static method in 4 lines.

      Also, I should point out that "org.apache.xalan.xslt" is hardly the Java API.

    14. Re:Language Compatibility vs. Class Libraries by Moebius+Loop · · Score: 2, Insightful

      Oh come on. Java is definitely quite verbose, but no one would ever write that code like that.

      This code example wouldn't even compile, these classes don't exist in any version of xalan.xslt that I can find, and it's not even using import statements.

      import org.apache.xalan.xslt.*;

      String xmlSystemId = new File(xmlFileName).toURL().toExternalForm( );
      String xsltSystemId = new File(xsltFileName).toURL().toExternalForm( );

      XSLTProcessor processor = new XSLTProcessorFactory().getProcessor( );
      XSLTInputSource xmlInputSource = new XSLTInputSource(xmlSystemId);
      XSLTInputSource xsltInputSource = new XSLTInputSource(xsltSystemId);
      XSLTResultTarget resultTree = new XSLTResultTarget(System.out);
      processor.process(xmlInputSource, xsltInputSource, resultTree);

      And claiming that you ought to be able to do the following:

      XMLTransformer.transform(xmlfile, xsltFile, outputStream)

      Okay, so with your version:

      1. You can't transform XML that isn't stored in the local filesystem
      2. You can't apply any kind of preferences to the processor
      3. If you wanted to process multiple documents, you'd have no factory to instantiate/set common objects and attributes

      And surely a million other things. You must realize that in this day and age people are using XML and XSLT for myriad different uses, and a proper toolkit should be able to handle as many of them as possible.

      That's the best and the worst part about almost every Java library that people love to complain about. Swing gets much of this, but when you want a platform-agnostic way to put that essential UI component in the lower right-hand rectangle made by the scrollbars on your JScrollPane, Swing is the only way you're going to get there (or maybe SWT, I've never used it, but I hear similar complaints and praise).

      Java is the only platform-independent language that has this kind of power in the core library. Furthermore, this announcement means we've now got an true open-source environment that is already making inroads in the business programming world, in areas that have been previously dominated by C/C++ and (shudder) VB. This is a good thing.

      -phil
      --
      have you been seen on slash?
    15. Re:Language Compatibility vs. Class Libraries by Abcd1234 · · Score: 1

      Wow... a single example from a third party library. And then you used explicit namespaces instead of importing them, to make it look more complex than it really is. Sheer brilliance. You've sure convinced me!

      That you don't know anything about software development, that is.

    16. Re:Language Compatibility vs. Class Libraries by hattig · · Score: 1

      Say "Yay" for SOAP sadly. I haven't used Axis 2, only Axis 1.0 and 1.4 though, but the generated files do have quite a bit of syntactic bloat to them. Shame that the Axis code generator hasn't learned of auto-generating imports either.

      People, just use REST, okay? In Java you just include HTTP Client, and it's a few lines of code, assuming you have Java->XML and XML->Java code written already (efficient StringBuilders and SAXParsers respectfully, rather than lots of Introspection within the SOAP/Axis libraries). Yeah, it takes longer, but you run a timer against the same thing implemented as REST versus SOAP.

      Sadly, when you're told to write an interface to a third-party web service, you have no choice, and you have one day to do it in, so the wsdl2java + utility class to map values to/from your data structure is a really quick and reliable way to do things.

    17. Re:Language Compatibility vs. Class Libraries by Anonymous Coward · · Score: 0

      They have. IBM's J9.

    18. Re:Language Compatibility vs. Class Libraries by vdboor · · Score: 1

      But Java the *language* is great. I wish that someone would create a non-bloat version of the Java class libraries.

      Someone else already did this as well. :-)

      --
      The best way to accelerate a windows server is by 9.81 m/s2 ;-)
    19. Re:Language Compatibility vs. Class Libraries by Anonymous Coward · · Score: 0

      Right, because an actual working threading model is just class bloat...

    20. Re:Language Compatibility vs. Class Libraries by tkinnun0 · · Score: 1
      Why, I believe I have just the thing for you:

      import java.io.*;
      import org.apache.xalan.xslt.*;

      public class XMLTransformer {
      public static void transform(String xmlFile, String xsltFile, OutputStream out) {
      try {
      String xmlSystemId = new File(xmlFileName).toURL().toExternalForm();
      String xsltSystemId = new File(xsltFileName).toURL().toExternalForm();
      XSLTProcessor processor = XSLTProcessorFactory.getProcessor( );
      XSLTInputSource xmlInputSource = new XSLTInputSource(xmlSystemId);
      XSLTInputSource xsltInputSource = new XSLTInputSource(xsltSystemId);
      XSLTResultTarget resultTree = new XSLTResultTarget(out);
      processor.process(xmlInputSource, xsltInputSource, resultTree);
      } catch(Exception iCantBotherLookingTheseUp) {
      throw new RuntimeException(iCantBotherLookingTheseUp);
      }
      }
      }
    21. Re:Language Compatibility vs. Class Libraries by tagattack · · Score: 1

      OOP is not one tool too many, it's just a tool that's used inappropriately all too often.

      Object Oriented Programming *can* lead to incredibly elegant application designs, high separation of concerns, easy feature-scalability and very flexible and agile code.

      The problem typically is, that programmers focus on the wrong things when building an object oriented application. They worry about things like how to use inheritance, which is probably the most over-valued feature of OOP. They create objects which are large, upside-down in structure (utility base classes!?) and couple data and functionality arbitrarily (making data objects have functionality that is not intrinsically exclusive to that data, is a common error in OOP).

      Java programs can be elegant. But usually, they aren't. The fault is not the language, or OOP. The error is the operator.

    22. Re:Language Compatibility vs. Class Libraries by curunir · · Score: 1

      The problem with the Java API at this point is that there's been such an effort made to ensure that each new release is backwards compatible with all other releases that it's become a jumbled mess. This is why Java is continually getting trashed as being bloated.

      What needs to happen is some serious work into deprecating and then actually removing the stuff that's old or a result of some failed experiment. That Vector, Hashtable, StringBuffer and so many other old classes are still part of Java 1.7 is a crime. There's stuff all over the Java API that was deprecated in Java 1.1 and still has not been removed. And the minimum number of classes that Java has to load in order to run anything is still way too high. The beauty of Java's dynamic class loading is somewhat ruined when you have too many dependencies in the core classes that need to be loaded every time the JVM runs. Reducing those dependencies would result in faster start ups which would make Java feel less bloated.

      And beyond the core API, many of the J2EE APIs have serious issues. For instance, the Servlet API is mostly good an easy to use. But it still uses things like Enumerators and StringBuffers that are considered obsolete. And there are still things that are wildly inconsistent...like HttpServletRequest#getRequestURI and #getRequestURL. One returns a String and the other returns a StringBuffer...how does that make any sense? Even if you were to update the API to use the newer StringBuilder, that API decision would still make no sense. And that's not an isolated case...that kind of stuff is strewn all over the J2EE APIs.

      All this combines to give Java a very overwhelming and bloated feeling...especially to new users. That could all go away with some effort towards clean up and consistency throughout the API. There's an adage that a good finished design comes not when there is nothing left to add but when there is nothing left to remove. And that really embodies the philosophy that Java should adopt. If it means breaking backwards compatibility, then I think it's a necessary step. It wouldn't be that much more effort to maintain updates to the 1.6 branch to allow code written for ancient VMs to continue to run on an up-to-date JVM. But the gain from having an API that is consistent, intuitive and unburdened by the mountain of deprecated or otherwise ignored stuff that's currently in the API would be significant.

      And Sun should embrace the vibrant Java community and realize when others have solved a problem better than they have instead of the continual NIH syndrome they tend to have. If, instead of continuing to recommend their own substandard solutions, they were to advise that users use other solutions and then invest effort into improving those other projects and possibly incorporating them into core APIs (i.e. giving them either java.* or javax.*), they could provide users with a better experience and expend less developer effort in the process. The fact that I still have to fend off PHBs who think we should re-architect projects to use EJB is incredibly annoying (though not nearly as annoying as the ones that suggest rails, but I digress). EJB has been a total train wreck since its inception. And the re-designed EJB 3.0 is, while better, still a worse solution than any of a handful of open source projects geared towards solving the same problem. They should let it die already.

      On somewhat of a tangent, AWT and Swing also need to crawl into a hole somewhere and die. They were interesting forays into a GUI framework, but SWT and JFace are better. If Sun has the balls to move to a Java 2 that breaks backwards compatibility, they should also have the insight to axe AWT and Swing and work with IBM to include SWT and JFace in core Java distribution. For one, it would allow Sun to offload a lot of the responsibility for maintaining a huge part of the distribution to someone else, which would no doubt save them a nice chunk of change. And it would also allow them to focus on the core Java language, performance and API.

      But I make a very nice living off of being able to navigate through the whole mess, so who am I to complain?

      --
      "Don't blame me, I voted for Kodos!"
    23. Re:Language Compatibility vs. Class Libraries by Anonymous Coward · · Score: 0

      NIO is brilliant? Give me a break. It is a set of buggy wrapper classes.

      How brilliant do you have to be to expose existing functionality in another language? Berkeley sockets are now almost 50 years old? In order to be brilliant; don't you have to accomplish something unprecedented?

      James
      Beverly, MA

    24. Re:Language Compatibility vs. Class Libraries by Anonymous Coward · · Score: 0

      In case you didn't notice, the reason you've been modded "Funny" is because a language whose standard library includes an e-mail server, web server, sqlite implementation, and a DOM implementation cannot call itself "non-bloated".

    25. Re:Language Compatibility vs. Class Libraries by setagllib · · Score: 1

      I happen to think NIO is a very spartan low level library. I had to write a high level library on top of it, integrating it with threading and Swing/SWT event loops, just to use it for a few projects. I'll release it as open source if it's cleared by a company I worked for before.

      --
      Sam ty sig.
    26. Re:Language Compatibility vs. Class Libraries by Anonymous Coward · · Score: 0

      I think most developers would agree, but Sun lacks a leader guiding the language. Its a fairly balsy call to make, and not one that a design-by-committee process will easily adopt. There needs to be a two release cycle between a replacement API and the older API moved out into a seperate library (and ideally a different namespace). As in, dropping Date and Calendar could be done in Java 1.9, given the new Java 7 apis, and this would give most shops enough time (and incentive) to migrate.

    27. Re:Language Compatibility vs. Class Libraries by jalet · · Score: 2, Insightful

      In case you didn't notice because you can't read, we (both the OP and me) were talking about the libraries, not the language itself. If I trust what you say, Java's libraries (the default ones) can't do anything "remotely" (this is the word) useful unless you install tons of add-ons, so basically they could as well have been thrown away a long time ago. So Java is bloated but does nothing by default excepted print "Hello World" (yes this is trollish). Java has always been overhyped by companies like Sun (but not only them).

      --
      Votez ecolo : Chiez dans l'urne !
    28. Re:Language Compatibility vs. Class Libraries by Anonymous Coward · · Score: 0

      Sorry, but you're talking out of your ass.

      The GP didn't say anything about obfuscation - he talked about bloat, which is an entirely different thing. Did you really not get that? Given your highhorse-ish advice to use import statements, it would appear that you're trying to make him look like a fool by suggesting that he's not aware of the *very problems* he's actually *complaining about*.

      That being said, yes, he could make the code somewhat less verbose than it currently is; at the same time, though, it still is pretty verbose. I'm not sure it's necessarily a reason to complain, myself, but at least do try to understand what he means.

    29. Re:Language Compatibility vs. Class Libraries by DuckDodgers · · Score: 1

      Microsoft has the resources to re-architect their next operating system from the ground up and make something truly revolutionary. They won't do it for fear of breaking even more backwards-compatibility with existing apps and tens of thousands of developers who are comfortable with the existing APIs.

      Java has the same problem. Changing the standard class libraries to be more consistent and clean would be wonderful. But tens of thousands of existing programs would need to be rewritten if they were to be ported forward, and tens of thousands of developers would need to re-learn the class libraries.

      My bet is that the next big thing, whatever that is, will supplant Java before they ever fix the standard libraries.

    30. Re:Language Compatibility vs. Class Libraries by Anonymous Coward · · Score: 0

      Java has the same problem. Changing the standard class libraries to be more consistent and clean would be wonderful. But tens of thousands of existing programs would need to be rewritten if they were to be ported forward, and tens of thousands of developers would need to re-learn the class libraries.
      I find the issue of tens of thousands of existing programs needing to be re-written to be somewhat of a red herring. The key difference between Microsoft's dilemma when breaking backwards compatibility and Java doing the same thing is who controls the execution environment. Whereas developers who rely on Microsoft APIs do not control the environment where the code is executing, that's not really the case with Java. If you develop a windows program, it needs to run on XP, Vista and possibly even 2k or the server variants. But the majority of Java programs are run as server applications, so the developer controls what JVM is used to run their code.

      And if the developer controls the runtime environment, they can continue to use existing Java releases to run their application until such time as they decide it's worth it to update their code.

      But I agree with your second point...the pain of learning new APIs would probably be the bigger problem for Sun. As much as developers like to convince themselves they can quickly learn new langauges and APIs, with an API as large as Java, it would take significant effort for most Java devs.

    31. Re:Language Compatibility vs. Class Libraries by VGPowerlord · · Score: 1

      Sadly, when you're told to write an interface to a third-party web service, you have no choice, and you have one day to do it in, so the wsdl2java + utility class to map values to/from your data structure is a really quick and reliable way to do things.

      Sadly, it's the WDSL2Java part of Axis2 that is the problem. Something to do with Axis2's Automatic Data Binding (ADB). I haven't played around with Axis2's other data binding types: JAXB or XMLBeans... or with manually writing AXIOM (Axis Object Model?) code.

      Of the 4 options, Eclipse's Web Services generator with Axis2 only supports ADB.

      --
      GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
    32. Re:Language Compatibility vs. Class Libraries by optevo · · Score: 1

      I kind of have the opposite view. The language is ok - but kind of verbose and a bit quirky as one of its design goals was to keep it similar to C++. However, for all the criticism that you may level at its API (and not all of it is awful - most is reasonably usable) what I like is that it does *so much* and it's available everywhere and works in the same way. That's a huge time saver. When I moved from Windows to Linux as my main OS, I didn't have to relearn *anything* to continue doing Java development; the main Java IDEs were identical as they're written in Java too. And when I go back to Windows at a client's site and they're using Java, it doesn't phase me more the same reason.

    33. Re:Language Compatibility vs. Class Libraries by RAMMS+EIN · · Score: 1

      ``Unfortunately most of them are complete bloat (e.g. Swing, NIO, logging ...). Each package is like a treatise on OOP and design patterns. When are people going to learn that OOP is just one tool of many?

      But Java the *language* is great.''

      Err, no. Java, the language, is built around the idea that the only paradigm you'll ever need is classes-and-instances object-orientation. A lot of the ugliness and bloat in the libraries stems from that. The rest is culture - from the start, everything about Java has been heralded as the One True Way and the new way to do things, and it's been the same ever since: whenever a new workaround for some ugliness is invented or ported over from another language, it is heralded as the Great New Thing, and everybody starts using it everywhere, even where it isn't the best way to go. But really, in the end, you can't get around the limitation that Java just doesn't allow for anything that isn't an object with fields and methods (except for the built-in primitives, of course).

      --
      Please correct me if I got my facts wrong.
    34. Re:Language Compatibility vs. Class Libraries by petermgreen · · Score: 1

      The problem with the Java API at this point is that there's been such an effort made to ensure that each new release is backwards compatible with all other releases that it's become a jumbled mess. This is why Java is continually getting trashed as being bloated.
      True, on the other hand that backwards compatibility is one of java's greatest strength. Why should application developers be forced to change thier code just to satisfy a few basement dwellers. I feel much more confident of my app continuing to work if I write it in java than if I write it in some language that is always dicking arround with the specs (e.g. php)

      What I would suggest though would be to hide deprecated classes in the help by default and require a specific compiler switch to compile code that uses them.

      And Sun should embrace the vibrant Java community and realize when others have solved a problem better than they have instead of the continual NIH syndrome they tend to have. If, instead of continuing to recommend their own substandard solutions, they were to advise that users use other solutions and then invest effort into improving those other projects and possibly incorporating them into core APIs (i.e. giving them either java.* or javax.*),
      One issue is that sun wants to keep the ability to sell java under any license they like. This makes it basically impossible for them to incorporate existing free software projects into the main java tree.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    35. Re:Language Compatibility vs. Class Libraries by Bri3D · · Score: 1

      Take some Java 1.1 source.
      Compile and run it with JDK/JRE 1.1.
      Benchmark memory consumption.
      Now do the same with Java 6 SE.
      The memory consumption for a real-world app I worked on is over 4(!) times higher with Java 6 SE.
      Clearly something's grown.

  8. Re:Really ? by Anonymous Coward · · Score: 0

    Feels like it.

  9. Apple by thomas.galvin · · Score: 4, Insightful

    Sweet. Maybe was can start getting Java VMs on the Mac less than a decade after they're released now.

    1. Re:Apple by Anonymous Coward · · Score: 0

      Sweet. Maybe was can start getting Java VMs on the Mac less than a decade after they're released now. Ti's the nice thing about OpenJDK, there's actually an OSX port. People are trying to get it included as a support "platform" port so that developers don't have to wait for apple.
    2. Re:Apple by sm62704 · · Score: 1

      Now that it's open-source and Apple is UNIX-like you can do Java on Mac yourself.

      --
      mcgrew's razor: Never attribute to stupidity that which can be explained by greedy self-interest
    3. Re:Apple by Anonymous Coward · · Score: 0

      What's with all the drink codenames?

      What do we get if we mix IceTea with Java and Cocoa with a drop of WINE on the rock made of Aqua?

    4. Re:Apple by Ilgaz · · Score: 3, Insightful

      Where were you past 3-4 months? :)

      Landon Fuller and a team made Java 6 running under OS X X11 (and command line of course)

      http://landonf.bikemonkey.org/static/soylatte/

      It is said to have great performance too.

      The real issue is, how to make that gigantic thing available to PPC G5 and G4/G3 (if they accept perf. penalty) processors under OS X. X11 could be OK too. The Java 6 release(!) from Apple is Intel 64bit _only_. We can't ask Apple as they even abandoned Intel 32bit users (on that release) so there should be some team, likely from IBM needs to step in. They shipped Java 6 for Linux PPC/PPC64 ages ago. They should step in and save/support their CPU customers, especially G5. While people buy G5 workstations/servers, they also bought IBM CPUs.

    5. Re:Apple by Ilgaz · · Score: 1

      Cocoa/Core Audio/Integration with OS X Desktop and the rumours of Carbon future make it hard for everyone. Only company besides Apple to ship such a huge thing is Sun and it could get real pricey for them. They absolutely need to start hiring Cocoa/OS X programmers and start talks with Apple on future of Java on OS X.

      I won't be surprised if Apple says "Java 6 will be Intel only" for example. Won't be surprised at all.

      You know any handset which has higher price than $70 and doesn't have J2ME? Take a guess :)

    6. Re:Apple by thomas.galvin · · Score: 1

      I was in the corner, bitching about the fact that it took almost a decade to get Java 6 on the Mac. From a third party. Then, I was bitching about the fact that Apple decided to release the "official" Java 6, but limited it to 64 bit processors.

    7. Re:Apple by Anonymous Coward · · Score: 0

      QT Jambi may offer a solution to people who are doing Free things on OS X?

    8. Re:Apple by shawnce · · Score: 1

      I won't be surprised if Apple says "Java 6 will be Intel only" for example. Won't be surprised at all. Java SE 6 on Mac OS X is already Intel 64-bit only.

      http://support.apple.com/kb/HT1856
    9. Re:Apple by ChunderDownunder · · Score: 1
      Where were you past 3-4 months? :)

      Gary Benson has been steadily implementing a processor-independent version of HotSpot.

      The shipping HotSpot is available only for a limited number of platforms such as Sparc, x86 and x86_64 because it uses intricate assembly language specific to those CPUs. Benson's work uses a purely C++ version of the bytecode interpreter for which he is JIT-ifying using LLVM.

      Though sponsored by RedHat for their Linux platforms, the resultant PPC JVM will hopefully one day integrate nicely with Soylatte.

    10. Re:Apple by Ilgaz · · Score: 1

      Honestly I gave up on Apple regarding Java especially after they plain ignored J2ME on iPhone even claiming nobody asked for it. Someone at Apple, the Boss perhaps hates Java so they treat it like junk. Yes, amateurish and child like like that. People still wonder why enterprise stays away from Apple. The enterprise runs Java 6 on Windows 98!

      After I saw JRE6 being 64bit Intel only without explanation and while poor G5 users just sitting there with enterprise class 64bit CPUs, I begun to question platform of my choice back in 2003.

      Today the best platform to run Java especially for end user is Windows. Let Apple live with that shame if they ever look to something other than that locked and closed junk.

      Check the release date of that rock solid and excellently performing IBM Java for PPC Linux 32/64. You will understand my frustration too. If you are in desperate need for Java 6 and you need to be final and supported, check Linux or even Windows,

    11. Re:Apple by petermgreen · · Score: 1

      You know any handset which has higher price than $70 and doesn't have J2ME? Take a guess :)
      The port-o-rotary ;)

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    12. Re:Apple by petermgreen · · Score: 1

      Today the best platform to run Java especially for end user is Windows.
      Java on i386/amd64 linux isn't bad either (though the lack of an official amd64 java plugin is a pita) and will hopefully getting a lot better in the not too distant future as distros begin to accept openjdk as thier default java.

      I wonder if/when sun will release any more of thier JITs.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    13. Re:Apple by Constantine+XVI · · Score: 1

      Windows Mobile handsets*?
      "Modern" Palm OS phones?
      Most dumbphones on CDMA carriers that aren't Sprint?

      *Without a good bit of hacking

      --
      "I think an etch-a-sketch with an ethernet port would beat IE7 in web standards compliance."
  10. Re:Really ? by ais523 · · Score: 4, Funny

    Does this mean it consumes 2 GB of RAM to display "Hello World"???

    Man! Was that joke ever funning circa 1997...

    Yes, nowadays everyone has the 2GB of RAM, due to Windows Vista, so it isn't a problem.
    --
    (1)DOCOMEFROM!2~.2'~#1WHILE:1<-"'?.1$.2'~'"':1/.1$.2'~#0"$#65535'"$"'"'&.1$.2'~'#0$#65535'"$#0'~#32767$#1"
  11. mod parent up by mpapet · · Score: 1

    Well said sir.

    GPL or not, based on Sun's behavior around their Indiana/OpenSolaris (That can't be called OpenSolaris because Sun said no)will pretty much kill whatever advantages going GPL/community driven may bring.

    --
    http://www.maxineudall.com/2010/02/should-economists-be-sued-for-malpractice.html
  12. Re:Really ? by jalet · · Score: 1

    Circa 1997 nobody could afford having 2 GB of RAM.

    --
    Votez ecolo : Chiez dans l'urne !
  13. Ask Slashdot by sm62704 · · Score: 1

    Six point three million lines of code??? How is it possible for a language to need six point three milliion lines of code? Is this bloat, or are all six point thee million lines actually used?

    The first iteration of Artificial Insanity (a smartassed Turing test program I wrote way back when I still gave a shit) was less than 16k of BASIC, but when I rewrote it with pretty much the same source code in Clipper for DOS, the executable was over 400k despite the fact that the source was still less than 16k.

    The SOURCE for java is 6.3 megabytes? What is it written in, COBOL?

    --
    mcgrew's razor: Never attribute to stupidity that which can be explained by greedy self-interest
    1. Re:Ask Slashdot by The+End+Of+Days · · Score: 5, Informative

      Java the language and Java the platform are not at all the same thing. OpenJDK refers to an implementation of the platform, which includes the tools, the API, and the VM.

      It's mostly written in Java (the language), by the way.

      By the by, reading that first link made my brain hurt. When is GNU going to learn that the language of doom ("shackled," "trap," etc.) is a good way to ensure that you preach only to the choir?

    2. Re:Ask Slashdot by Thiez · · Score: 2, Informative

      Java comes with a huge library of classes. It seems that is was the article about. I'm sure you can write a working java interpreter in less than 6.3 million lines.

    3. Re:Ask Slashdot by Anonymous Coward · · Score: 3, Insightful

      That count includes the standard libraries. And it includes the *comments* in the standard libraries, from with the javadocs are generated. All in all, it sounds like a pretty reasonable number.

    4. Re:Ask Slashdot by SanityInAnarchy · · Score: 2, Funny

      When is GNU going to learn that the language of doom ("shackled," "trap," etc.) is a good way to ensure that you preach only to the choir? I suspect it'll be around the same time that Republicans learn that people care about more issues than the terrorists.
      --
      Don't thank God, thank a doctor!
    5. Re:Ask Slashdot by Ilgaz · · Score: 1

      Java is not only a language, it is a virtual machine which should run anywhere with amazing levels of backwards compatibility.

    6. Re:Ask Slashdot by Jason+Earl · · Score: 3, Insightful

      By the by, reading that first link made my brain hurt. When is GNU going to learn that the language of doom ("shackled," "trap," etc.) is a good way to ensure that you preach only to the choir?

      RMS has been talking that way for years. There's essentially no chance of him changing his ways at this point. This is especially true considering the fact that RMS' zealotry has netted him an impressive string of wins including a GPLed version of Java.

      The fact of the matter is that the Free Software community has become a rather influential player in the software world. Sun GPLed Java because the executives at Sun finally realized that despite the huge push for Java from the "Enterprise" crowd, the real reason that Java was a competitive platform was because of the large quantity of Free Software that had grown up around Java. Sun needed Free Software hackers, but for the most part Free Software hackers weren't interested in working with Java.

      In this particular case, preaching to the choir was precisely what was needed.

    7. Re:Ask Slashdot by Anonymous Coward · · Score: 0

      the real reason that Java was a competitive platform was because of the large quantity of Free Software that had grown up around Java. Sun needed Free Software hackers, but for the most part Free Software hackers weren't interested in working with Java.


      Wanna try restating that in a way that doesn't contradict itself, there, zealot?
    8. Re:Ask Slashdot by Jason+Earl · · Score: 2, Insightful

      There's no contradiction, although I admit that I could have been more clear. Java was Free enough that a substantial amount of Free Software was created for it. However, the majority of Free Software hackers steered clear, and that has hurt Java quite a bit (for essentially no benefit to Sun).

      For example, even Sun-supported Gnome contains more Mono-based C# in it than Java. Free Software hackers generally used (and built) competing web technologies instead of using Java-based tools. You can get web hosting that includes toolkits based on PHP, Perl, or Python from any number of sources, and for ridiculously reasonable prices. You can then use these accounts to host sophisticated Free Software applications. Java should have done much better in this space, but Sun's licensing precluded that.

      Free Software hackers used (and built) competing tools for creating desktop applications as well. Heck, one of the most popular Java-based desktop applications is Eclipse, and because it is based on SWT it isn't even pure Java.

      When you think of the time and effort that went into the various Java replacement toolsets like gcj, Harmony, GNU classpath, etc. it is pretty clear that Sun wasted a great deal of Free Software effort that could have gone towards making Java that much cooler. It will be interesting to see what happens to Java now that a 100% Free Software version is finally available.

      Java would almost certainly be a cooler platform today if Debian (to give an example) would have included it in main years ago, or if the source would have been available for a decent, up-to-date port to the BSDs and other niche platforms. Java was an inferior choice for even the less zealous of the Free Software community simply because you couldn't count on it being available. gcc, as an alternative, is available everywhere. Heck, Python is available everywhere. Java's write once run everywhere promise has been broken for years for people that are interested in platforms outside of Sun's narrow scope.

      If it weren't for the Free Software that grew up around Java it would not be a viable platform today, plain and simple, but that doesn't mean that Sun has done a particularly good job encouraging Free Software hackers to use Java. A lot of opportunities have almost certainly been missed.

      Thanks for encouraging me to spend some time making my point more clear. I appreciate it.

    9. Re:Ask Slashdot by Anonymous Coward · · Score: 0

      Yeah, yeah, yeah. Basically you didn't actually clarify anything, you just took it upon yourself to go off on an unsupported opinion-based rant.

      Thank you for encouraging me to poke holes in your bullshit.

    10. Re:Ask Slashdot by Jason+Earl · · Score: 1

      Fine then, I'll bite Mr. Anonymous Coward. If Sun wasn't concerned about getting the Free Software community more excited about Java why then did Sun GPL Java?

      After all, there are some downsides, for Sun anyway, to a GPLed Java. For example, now that Java is GPLed Sun has lost a considerable amount of control. Sun also had to pay to have Java vetted for release, and it has to pay for the infrastructure and community relations.

      So what's in it for Sun?

      Or are the executives at Sun full of bullshit as well?

    11. Re:Ask Slashdot by argent · · Score: 1

      RMS has been talking that way for years. There's essentially no chance of him changing his ways at this point. This is especially true considering the fact that RMS' zealotry has netted him an impressive string of wins including a GPLed version of Java.

      You sure that didn't happen *despite* his zealotry?

    12. Re:Ask Slashdot by jonasj · · Score: 1

      Wait, wait, wait...

      Six point three million lines of code???

      The SOURCE for java is 6.3 megabytes? 6.3 megabytes is 6.3 million bytes. For 6.3 million lines of code. That's a single byte per line of code? That doesn't sound right!
      --
      You know, Microsoft's street address also says a lot about their mentality.
    13. Re:Ask Slashdot by Jason+Earl · · Score: 1

      Actually, in this particular case I think that RMS' zealotry actually slowed the process down a bit. Gosling and RMS have a long and storied history dating back to the early days of Emacs and there's little doubt in my mind that this history caused the folks at Sun to miss the many opportunities inherent in a Free version of Java.

      Still, it's hard to argue that RMS doesn't get what he wants in the end. Lots of software projects have given in to RMS when it became apparent that cooperation was in order and RMS was not going to bend. Whether you are talking about the BSD-license changes or the license changes for QT and MySQL, or any number of other minor wins, RMS' willingness to rally the GNU folks and write replacement software from scratch if need be over minor licensing points has historically been pretty darn persuasive. In this particular case I don't think it is a coincidence that Sun released Java just as projects like Harmony, gcj, and GNU classpath were starting to show some promise.

    14. Re:Ask Slashdot by sm62704 · · Score: 1

      Hmmm.... the source must be compressed pretty tightly, eh?

      --
      mcgrew's razor: Never attribute to stupidity that which can be explained by greedy self-interest
  14. What's the point? by jps25 · · Score: 4, Interesting

    Okay, so I understand that this is a huge success, yay GPL and all that, but what is wrong with Sun's JDK?
    What makes the OpenJDK more desirable than Sun's?
    Is it merely the GPL?
    Are there any performance gains?
    I don't use java, so I really have no idea and it would be nice if someone could enlighten me.

    1. Re:What's the point? by Funks · · Score: 3, Interesting

      Okay, so I understand that this is a huge success, yay GPL and all that, but what is wrong with Sun's JDK? What makes the OpenJDK more desirable than Sun's? Is it merely the GPL? Are there any performance gains? I don't use java, so I really have no idea and it would be nice if someone could enlighten me. Trying using the Sun distributed JDK on FreeBSD, NetBSD and other micro architectures like MIPS. Moreover, being completely GPL - Linux distributions will be able to bundle it in. The BSD's will also benefit from this and won't be treated like a redheaded step-child anymore when selecting a JEE hosting platform. Note, RedHat is a big player in the Java (JEE) middleware industry. So basically, it was in their best interest to see this through.
    2. Re:What's the point? by Vectronic · · Score: 3, Informative

      From what i understand, the advantage is that distributions that are (or try to be) 100% "Open Source" can now add this to their list.

      Ontop of that, it means that anyone and their dog can dig through it, and maybe even improve on it, plus being able to make better java applications knowing exactly whats going on...

    3. Re:What's the point? by mhamel · · Score: 1

      Well, that won't solve any performance issues. I'm an Ubuntu user. For me, it could change lot's of things. There are lot's of great java applications lying around. But in linux, they are often second class citizen. The reason is that the java envirenment can't but included simply with a distribution. You always have to go throught some hooplas. The reason it's not included is mostly because the jvm (java virtual machine) is not free in it's intelectual property. Now it just changed. So we can hope that some good java applications will have much better support soon in linux.

      So for me it's a great thing.

    4. Re:What's the point? by youngdev · · Score: 3, Interesting

      It is my understanding that all of core java would be based on the OpenJDK going forward. Basically OpenJDK is SunJDK6.999 beta. SunJDK 7 will be the openJDK and SunJDK >= version 7 will all be open(gpl?).

      Someone please correct me if that is wrong.

    5. Re:What's the point? by sidnelson13 · · Score: 2, Informative

      Of course, we can search for enlightenment ourselves!

      OpenJDK FAQ

      Cheers!

    6. Re:What's the point? by Anonymous Coward · · Score: 0

      Also, as mentioned elsewhere, they rewrote all the patent-encumbered stuff. The whole codebase is "free" now: this will allow third parties to create competing JDKs, and possibly usher in an era of very rapid improvement.

    7. Re:What's the point? by j79zlr · · Score: 2, Informative

      64-bit plugin for 64-bit browsers. For some strange reason Sun refuses to release one. The current icedtea plugin for my Gentoo amd64 install works about 50% of the time. Hopefully they can get that up to where it is more compatible

      --
      I'm not not licking toads.
    8. Re:What's the point? by lytles · · Score: 1

      from my experience this is going to be very useful. i've come across several classes that do almost what i want, but not quite. the best example is sorting primitives, eg doubles, and wanting the sort order back. Arrays.sort() is a good algorithm, but the only way to get the order is convert all those primitives to Objects and sort the Objects - not fun. Having the source means that you're not starting from scratch - you've got a known working version, with known performance, and you can modify it. I had to hunt around and choose and algorithm and implement it.

      And sorting is "easy", with hundreds of free references. For more complicated things that java does, this will be great.

    9. Re:What's the point? by drinkypoo · · Score: 1

      My understanding is that if you use the OpenJDK, you gain access to variable-width text.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    10. Re:What's the point? by Tacvek · · Score: 1

      Think more like StarOffice. StarOffice is OO.org + additional proprietary code. SunJDK form Version 7 on will be OpenJDK + additional proprietary code.

      --
      Stylish sheet to fix many problems in Slashdot's D3: https://gist.github.com/801524
    11. Re:What's the point? by ChunderDownunder · · Score: 1

      This announcement means OpenJDK passes all the tests. That doesn't mean the GPL replacements for the Sun proprietary code are yet mature enough to be considered 'production ready'; Sun may continue to link the encumbered bits in their release versions.

      e.g. As someone else mentioned, things like font rendering still aren't quite there yet in terms of quality. They 'do the job' enough to pass the test suite but adequacy doesn't imply polish.

      Another factor is not everything included in a JRE has been released into OpenJDK. Examples are a browser plugin for applets and Java Web Start for JNLP. These are undergoing a rewrite as Sun tries rediscovers the client through their JavaFX initiative. Perhaps these will be freed into the OpenJDK7 source tree over time. Meanwhile, IcedTea have provided substitutes for these two technologies.

  15. about time Sun by sjwest · · Score: 0, Troll

    Dear Sun employees as a /. reader and Debian box user i am occasionally interested in the Freshmeat apps on the right hand side. When it says downloading jar i know it usually won't work. Yes I am lazy and wont download stuff from your website, untar it, click agree and hope that all the other working Java bits still work and i have got a handle on what ever your Sun marketing experts have named the jdk this week. It is a shame that the run everywhere on everything has been such a long time coming.

    1. Re:about time Sun by SanityInAnarchy · · Score: 1
      When I last installed it, it was actually pretty simple:

      apt-get install sun-java6-jdk
      Of course, it'd still ultimately do the same thing -- download a tarball, unpack it, and prompt me for a license agreement. But it wasn't really that much more difficult than it is now with openjdk-6-jdk.
      --
      Don't thank God, thank a doctor!
    2. Re:about time Sun by sjwest · · Score: 1

      That is a channel/repo we don't have setup, i assume you have the Non-free channel your pulling down the .deb from.

    3. Re:about time Sun by SanityInAnarchy · · Score: 1

      Likely. Well, actually, Ubuntu with "restricted", but I suspect the package also exists in Debian non-free.

      But then, if you're complaining about how hard it is to install non-free software when you deliberately don't have the non-free repository setup... (Which is point-and-click in Ubuntu, by the way.)

      --
      Don't thank God, thank a doctor!
    4. Re:about time Sun by setagllib · · Score: 1

      In Hardy openjdk-6-jdk comes in without any license agreement nonsense. I just checked, too. It's just like installing Python or any other open package, except that, yes, it's still in universe instead of main.

      --
      Sam ty sig.
    5. Re:about time Sun by SanityInAnarchy · · Score: 1

      Check from a fresh Hardy install. I'm not sure, but from what I remember, it ran a script to download it separately, and did request that you agree to that license. It also keeps track of that agreement, so you can reinstall without re-agreeing.

      I could be wrong, though.

      --
      Don't thank God, thank a doctor!
    6. Re:about time Sun by setagllib · · Score: 1

      It is most definitely a complete self-contained package, and yes I've tested it on a fresh Hardy install. I don't want to create a virtual machine just to repeat it. OpenJDK is the real deal, and it may even make it into main someday.

      --
      Sam ty sig.
  16. Re:Really ? by snoyberg · · Score: 3, Funny

    I had 2 GB of RAM you insensitive clod.

    --
    Thank God for evolution.
  17. Re:Really ? by sm62704 · · Score: 3, Insightful

    Does this mean it consumes 2 GB of RAM to display "Hello World"???
    Man! Was that joke ever funn[y] circa 1997...
    And in 1987 it was "Does this mean it consumes 2 MB of RAM to display 'Hello World'???" and in in 2017 the joke will be upgraded to "Does this mean it consumes 2 TB of RAM to display 'Hello World'???"

    Why does it seem that every time the hardware guys give us more machine, the software guys use every last bit of it to do exactly what the previous generation of machines did, only the previous generation did faster?
    --
    mcgrew's razor: Never attribute to stupidity that which can be explained by greedy self-interest
  18. Re:Really ? by bsDaemon · · Score: 5, Insightful

    Because each generation of "software guy" becomes n+1 generations removed from being a hardware guy himself. That is to say, the tools become "better" to make programming "easier" for people who aren't also electrical engineers.

    At least, if I had to guess, that's what I'd say.

  19. Re:Really ? by peragrin · · Score: 1

    Well that explains a lot. It explains why with every iteration OS X streamlines a bit making it slightly faster on the same hardware, It explains why OS X can do everything Vista does on a quarter of the hardware.
    it is because Apple controls the hardware thus promoting a tighter bonds between the two groups of people.

    --
    i thought once I was found, but it was only a dream.
  20. Oh boy! by croftj · · Score: 0, Troll

    Not only can I torment myself programming in Java, but I can do it freely! Thanks GNU!

    Life sucks, then you have to program in Java and learn just how bad it can get!

    --
    -- Many men would appreciate a woman's mind more if they could fondle it
  21. Re:Really ? by Anonymous Coward · · Score: 5, Funny

    You forgot the corrolary to Moore's Law, Which is Gates's Law: Every 18 months, the speed of software halves.

  22. Spelling by blueforce · · Score: 2, Funny

    He actually spells it "Ice T": http://en.wikipedia.org/wiki/Ice_T

    --
    If you do what you always did, you get what you always got.
  23. Re:Really ? by Anonymous Coward · · Score: 2, Interesting

    You don't realize (or maybe you do) how accurate this is. As much as I hate to admit it, I'm a perfect example.

    I sit right next to a guy at work that went to the same university I did. However he's got 10 years on me. Both degrees are in Computer Science. Yet he knows a LOT more about E.E. stuff than I do. It seems the curriculum at our school got softer (pun intended) as the years went on.

    I realize this at least and do my best to pick up bits and pieces from him and the other E.E. guys here at work. But it does disappoint me a bit that I didn't get the same level of education as my co-worker.

  24. Re:Really ? by afidel · · Score: 2, Informative

    Sure they could the Cray T90 came out in 1995 with up to 8GB of ram and the Y-MP M90 came out in 1992 and had up to 32GB of ram, the T3D came out in 1993 with up to 64GB of ram. Basically your run of the mill supercomputer had several times that much ram by the mid 90's =)

    --
    There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
  25. Re:Really ? by jalet · · Score: 1

    Sorry I was thinking about individuals or small companies.

    --
    Votez ecolo : Chiez dans l'urne !
  26. Comment removed by account_deleted · · Score: 1

    Comment removed based on user account deletion

  27. Maybe you don't understand .Net? by encoderer · · Score: 4, Informative

    For the last 2 years I've been doing Python work with a little PHP but the 2 before that were spent almost exclusively in .Net (C# and IronPython).

    Right now on my dev box I have 4 versions of .Net.

    They run side-by-side without issue.

    There is no forced upgrade. It's like saying that C wasn't predictable because C++ emerged.

    1. Re:Maybe you don't understand .Net? by Anonymous Coward · · Score: 2, Informative

      You may not have hit any issues this way but I have. There's one strange case I know of without a good solution. The .NET control container in IE will by default use the newest runtime installed on the machine when rendering a web page that contains an embedded .NET object (client side control). If the control was compiled against 1.1 and you have 1.1 and 2.0 on your machine it will try to run it in 2.0. In the case I had, it failed due to API changes from 1.1 to 2.0. You can specify which version IE will use using a config file (iexplore.exe.config I think it was called) but that setting will hold across all web pages, so that's not so great.
        Developers dislike Java's way of deprecating old APIs, figuring it leaves cruft, but if MS had deprecated what they changed and made new versions I never would have had this issue. Then again maybe my company deserves their resources being wasted this way by letting my predecessor actually write a web page using .NET client controls, but still.

    2. Re:Maybe you don't understand .Net? by Saint+Stephen · · Score: 1

      I have heard many Java developers complain that applets in browsers fail in different JVMs.

    3. Re:Maybe you don't understand .Net? by Garen · · Score: 1

      So prior to IronPtyhon's first 1.0 production release in 2006 you had been using it for a couple years?

    4. Re:Maybe you don't understand .Net? by GleeBot · · Score: 1

      Considering how long .NET has been around, I'm not sure whether it's a good thing that you have to run 4 different versions of it side by side.

      Nice thing about Java is that I can just install the 1.6 JRE, and be more or less assured that everything still works.

    5. Re:Maybe you don't understand .Net? by Anonymous Coward · · Score: 0

      You wrote controls for IE in .NET? Whatever.

    6. Re:Maybe you don't understand .Net? by encoderer · · Score: 1

      Try this: Go back and actually read what I wrote. And then reply again, and quote me where I said I used IronPython for 2 years.

      And then go check out the IronPython project and check the release dates for the 0.9x previews.

      See? That wasn't so hard.

    7. Re:Maybe you don't understand .Net? by Anonymous Coward · · Score: 0

      C didn't have bugs that required an upgrade to Microsoft C 2.0, as I remember it.

    8. Re:Maybe you don't understand .Net? by encoderer · · Score: 1

      Do you think the C language was static from the moment the first C compiler was created?

      Of COURSE not.

      But back then, things were of a smaller scale. It didn't matter quite as much.

      So maybe you "remember it" with the haze of something that happened 35 years ago?

    9. Re:Maybe you don't understand .Net? by Anonymous Coward · · Score: 0

      I think that is the point, you have to run 4 version of dot net. The latest and greatest version should be able to support the older versions.

    10. Re:Maybe you don't understand .Net? by encoderer · · Score: 1

      I disagree. This is one of the major choices facing all platform developers.

      For example:

      In one corner, weighing in at 55 Million lines of code, wearing the ActiveDesktop, is the fully backwards compatible Mi-Cro-Soft Wiiiiiiiindoooooows.

      In the other, weighing in at a 15 Million lines of code, wearing nothing but an iPod, is Ooooooh-Esssss-Exxxxxx.

      In OSX you have to run old apps in an emulator.

      It's just not possible to maintain full backwards compatibility without introducing bloat and cruft.

      Even Microsoft has learned this. They're going to use the VM approach to backwards compatibility in Windows 7.

      I mean, what is the downside to running a few versions side-by-side?

  28. Re: by clint999 · · Score: 0

    But this itch obviously is not powerful enough to cause the community to scratch. So is it really a matter of immaturity or wrongness? Or is someone going to claim that the issue is that Java just isn't in use enough?

  29. you're wrong by speedtux · · Score: 1

    Those are JVM implementations, not complete Java implementations.

    There are a few non-Sun implementations that have passed certification, but they are not independent implementations; they contain licensed code from Sun.

    As I was saying: there are no independent implementations that have passed Sun's certification.

  30. Re:Really ? by Jesus_666 · · Score: 5, Funny

    Does this mean it consumes 2 GB of RAM to display "Hello World" ???
    So does C(++) because of all the memory leaks, every BASIC dialect because of interpreter overhead, Dotnet/Mono because it includes half of Windows, Python and Ruby because of all the objects, Lisp to store all the braces and Perl just because it can. PHP doesn't because nobody has tried it yet. ASM also doesn't because it always drops the processor back to 8080 emulation mode and can't address 2 GiB of RAM.

    The One True Language, beloved by all (Objective-C) also uses 2 GiB of RAM for "Hello World", but just because it needs to use that memory to cure cancer and feed starving children.
    --
    USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
  31. Re:Really ? by mischi_amnesiac · · Score: 3, Insightful

    Don't you think he has more knowledge than you because he has been working the last 10 years and learned new things? After all, you don't learn everything in a university.

    --
    "Die endgueltige Teilung Deutschlands - das ist unser Auftrag." - Chlodwig Poth
  32. Re:Really ? by Anonymous Coward · · Score: 0

    Electrical engineers can't code. The real problem is cs professors teach that memory, disk and cpu is cheap. That has to stop.

  33. Re:Really ? by Reverend528 · · Score: 4, Insightful
    But linux runs on more hardware than OS X or windows. And it runs faster than both.

    Maybe it has more to do with the skill of the developers than anything else.

  34. Re:Really ? by bsDaemon · · Score: 3, Insightful

    If you can design the logic circuits, you should be able to code. Had "computer science" even been developed as an independent discipline when they were building the Apollo guidance systems? I don't know the answer to that.

    I agree with the rest of the statement though. I think that the real problem is that too many departments are teaching using Java and the like, which are "industry standards" because too many students are looking at computer science as a gateway to a career coding JBoss apps for a bank, or working in IT -- basically a 4 year trade school.

    Computer Science has about as much to do with IT as mechanical engineering has to do with working in a lube shop. Sure, you could do it -- but you should have been taught to do a whole hell of a lot more. If all you want to do, or can do, is the trade aspect then I'm not sure that an extended education in what is essentially applied mathematics is really the route to go, and those who want that advanced theoretical knowledge shouldn't have to have their class time watered down by the kid who is still in .com mode.

    Then again, what the hell do it know. *goes back to working in Quark*

  35. Re:Really ? by kipman725 · · Score: 1

    thats why I have built a very basic computer out of logic gates EEPROMs, static rams and a Z80A running at 4MHz. I have also done projects that involve taking things like PIC chips beyond the limits of what they should rearly be able to do (acting as a simple MMU and controller for a delta sigma modulator based voice recorder). I can honestly say I have wrote a bug free program that runs as fast as is posible on the hardware available as I spent 2 weeks on just over 200 lines of asyembler. Those 200 lines are perfect there is no posible speed up... somehow that is satisfying.

  36. Re:Really ? by Anonymous Coward · · Score: 0

    No. We've had this discussion and compared "notes"...he did a lot of EEPROM programming, using scopes, took more E.E. like classes than I ever did (remember, same C.S. degree from the same Univ.).

    Matter of fact, the only time I had to flash an EEPROM was in my assembly class (1 class in 4 years). I'm not saying all of this just because he did more with EEPROMs than I did, that's just one example.

    Of course I've learned a lot over the years (just like he has), so you are correct there...but what he knew right out of school and what I knew right out of school was very different.

  37. Re:Really ? by Rycross · · Score: 1

    I think that if you looked at the software 10 years ago, you'd find that it did less, was less stable, and was less secure. I know that I'm doing a lot more with my computer these days than I ever did 10 years ago and my programs crash less. Hell, my development environment alone is light-years ahead of where it used to be.

  38. And yet no OpenGL support. by Anonymous Coward · · Score: 0

    So, us 64-bit users are still in need of 32-bit emulation to use that... What tests exactly does this JVM pass?
    Not mine.

  39. Re:Really ? by HJED · · Score: 0

    > and behaves like any other Java SE 6 implementation Does this mean it consumes 2 GB of RAM to display "Hello World" ??? No it wouldn't JAVA is NOT SLOW it can do execute an endless nothing loop faster then C (I have seen evidence of this but can't find it now :-( )
    --
    null
  40. Re:Really ? by HJED · · Score: 0

    thank your hardware for that not your programs *it is more stable then 10 yrs ago *it works faster then 10yrs ago *it has more memory then 10yrs ago that is why the programs are more stable (some of it might have something to do with your OS but I can't say that here can I......)

    --
    null
  41. Actually yes by SuperKendall · · Score: 1

    There are many billions of IT projects out there written using Visual Basic 6. I guess no one should try and pass Visual Basic off as immature, incomplete, incorrect, or insufficient either, right?

    Yes, that is true.

    It's also true that products produced with VB6 tend to be rather shoddy. But you appear to be unable to distinguish VB6, the framework and development platform, from the things people build from it.

    Just what you'd expect from someone who can't even figure out how to register on Slashdot.

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
  42. Re:Really ? by Anonymous Coward · · Score: 0

    Wow! Good for you! Want a gold star?

  43. Re:Really ? by prockcore · · Score: 1

    It explains why OS X can do everything Vista does on a quarter of the hardware.


    That's not true anymore. OSX has been getting slower and slower with each revision.

    Hell, look at the requirements for Spore. Spore for XP requires 512 megs of ram, Spore for Vista requires 768 megs of ram, and Spore for OSX requires 1 gig of ram.
  44. Re:Really ? by Rycross · · Score: 2, Insightful

    I don't remember saying anything about faster. I said its more feature-full, which is true. I can run emulators for systems like the Playstation. My games are prettier and have more features. My word processor checks my spelling and grammar as I type. My IDE checks for syntax errors, displays possible methods to use, compiles documentation, checks my coding for various coding standards. I'm streaming, transcoding, and playing video. I'm doing video chat. You have web apps giving you a more user-friendly experience, like gmail. Granted, a lot of these things were possible or even implemented in '98, but were they widespread, stable, useful, and feature-full? I'm sure you could make an argument that you're doing the exact same things on your computer today that you were doing 10 years ago, but only if you generalize it to a degree that it becomes meaningless ("coding", "writing a document", etc).

    Your comment about having more memory is wrong. My programs didn't crash because I didn't have enough memory. They crashed because they were shoddily written and didn't do a lot of stuff that modern languages and programmers do as a matter of course. I mean, C++ programmers make heavy use of RAII and smart pointers these days. They slow down the program but they prevent memory leaks. C# and Java have garbage collection to do the same things. Most modern languages have containers that do bounds-checking automatically. Thats slower than if you just threw the input at it. More validation, etc.

    And yeah, my OS is better these days. Thats an improvement in the OS. And some of those improvements take *drumroll* more processing power, because bugs need to be coded around, and more checks and validations need to be performed.

    To be sure there are some things that are designed to save developer time given programming time. The .Net remoting framework often generates overly-verbose network traffic compared to something that you wrote using plain sockets. But at the same time, in addition to being quicker, you also get strong typing, and the libraries take care of making sure the data you pass between layers is appropriate.

    Its just irritating to have people repeatedly say that developers are lazy and writing inefficient code. These days I worry more about the code I'm writing than I was in the past. And most developers I know are the same. You may be able to get your super-awesome "bloat" free programs, but they'll probably take twice as long to develop with less features, be full of bugs, crash all the time, and leak like a sieve. The 90's was not the golden age of computer software that a lot of people make it out to be.

  45. Bloat? by ttfkam · · Score: 4, Informative

    Are you sure you're not overreacting? If you hop on over to perl.com, you'll notice that the *compressed* source of Perl 5.10.0 is 14.9MB. The compressed source of Python 2.5.2 is 11MB. Ruby 1.8.7 comes out well at 3.9MB, but that's without any gems (good or bad depending on your point of view). The source for Common Lisp 2.4.5 is 7.1MB.

    However you're singling out Java as the one that's bloated? Get real.

    --

    - I don't need to go outside, my CRT tan'll do me just fine.
    1. Re:Bloat? by Watson+Ladd · · Score: 1

      Which Common Lisp implementation?

      --
      Inventions have long since reached their limit, and I see no hope for further development.-- Frontinus, 1st cent. AD
    2. Re:Bloat? by Nikker · · Score: 3, Insightful

      There really isn't that much bloat in Java. The reason the source is so huge is because of all library's. They have much more than a standard C distribution and cover every thing from OS calls to network sockets, thread management, encryption, HTML tools, the list still goes on. Being able to compile a Java class file that can be run natively by the kernel your class size would be quite small compared to the class file + run time files.

      --
      A loop, by its nature, continues. If that didn't make sense, start reading this sentence again.
    3. Re:Bloat? by oldwarrior · · Score: 0

      It is because a java app has to bring in it's own operating system into every application. All the calls, runtimes, etc. are there. Java as a language may not be overweight but a Java Platform application (or Exclipse Platform app) is always obese.

      --
      If it were done when 'tis done, then t'were well it were done quickly... MacBeth
  46. Re:Really ? by asamad · · Score: 1

    Yes it's called M$Cobol' 2008 (Microsoft's version of Cobol)

  47. Re:Really ? by kjots · · Score: 1

    ASM also doesn't because it always drops the processor back to 8080 emulation mode and can't address 2 GiB of RAM.

    Wow, you have a processor with 8080 compatibility?

    That rocks (in 1976)!

  48. TCK stands for by Anonymous Coward · · Score: 0

    Technology Compatibility Kit, not Test Compatibility Kit.

  49. Re:Really ? by setagllib · · Score: 1

    That's very geeky and impressive, but basic economics suggests that work like that will become a net loss, not a net gain, as cheap good-enough alternatives emerge. So while it's very geeky, I suspect it's not a good idea to base a business on.

    --
    Sam ty sig.
  50. Re:Really ? by Tanktalus · · Score: 2, Insightful

    Memory is about $20-$40/GB. Disk space is down to about $0.30-$0.50/GB. CPU is about $0.01 per bogomip (hey, there isn't really a good measurement out there, so what the hell).

    Yeah, let's teach a fantasy.

  51. Re:Really ? by JonnyChaos · · Score: 1

    one thing about these language wars is that everyone claims "language X implements feature k better than language Y" where in general its also true that language Y implements feature i better than language X.
    best tool for the job really.

    when it comes to languages why not pick what fits?

    I use java for work, since its got better tool support and a nice comfy syntax. I use C# for interfacing with windows/MS because its just better at it. I use C++ for runtime speed and LISP for fun.

    --
    we were somewhere just out of Barstow when the patent trolls attacked.
  52. Re:Really ? by Jesus_666 · · Score: 1

    Yup. Look at Visual Basic and PHP. Both have an abysmal reputation and both are extremely widespread because they have excellent support for getting things done. The result might not be pretty, but it works (even correctly, if you know what you're doing) and it's fast to implement. That featureset happens to be compelling in many cases.

    --
    USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
  53. GNU CLISP by ttfkam · · Score: 1

    http://clisp.cons.org/

    Considering that Emacs is a lot of folks' LISP engine of choice, the standalone GNU implementation seemed a legitimate choice.

    --

    - I don't need to go outside, my CRT tan'll do me just fine.
  54. Re:Really ? by dave87656 · · Score: 1

    Yes, nowadays everyone has the 2GB of RAM, due to Windows Vista, so it isn't a problem. Yeah, but if you're running vista you have about 1 MB left over from your 2GB when Vista's done.

  55. Re:Really ? by dave87656 · · Score: 1

    I think that if you looked at the software 10 years ago, you'd find that it did less, was less stable, and was less secure. I know that I'm doing a lot more with my computer these days than I ever did 10 years ago and my programs crash less. Hell, my development environment alone is light-years ahead of where it used to be. You are talking about the Windows world. If you expand that to include Unix, VMS and so on, it might be true that it did less, but it was very stable.
  56. Re:Maybe you don't understand Java? by Anonymous Coward · · Score: 0

    Java running in a browser currently limits you to a single VM. (This is likely to be changed soon.)

    However, there is no reason you can't run multiple stand-alone Java VMs of many different (or same) versions at the same time. Indeed, you can download almost any version Sun ever produced if you need to, and run them all at once.

    I'm not sure how you are forced to upgrade, although if you do, you're likely to see benefits, including improved performance and reliability.

    -John

  57. Re:Really ? by sm62704 · · Score: 1

    No, but it's a GREAT idea to base learning on. Not everything needs to be based on economics, unless of course you are a practitioner of America's State Religion (Mammon Worship).

    I never thought I'd see the day when so-called "nerds" at slashdot would bash someone for hacking (old-school meaning of the word).

    --
    mcgrew's razor: Never attribute to stupidity that which can be explained by greedy self-interest
  58. Re:Really ? by Anonymous Coward · · Score: 0

    Jaschnizzle bombs! You're right.

    Being a byproduct of Reaganomics, I have become tremendously detached from the inner workings of the 'puter. Very few of my generation understand the low level workings of assembly or the reasonings behind the tech. Now, we can computer parts like giant pieced legos, but none I know can decipher the inner workings of most drivers. We are high level programmers and only feed are drive for efficiency through inefficiency.

    But then, you're statement holds true to any technology created. Inventions such as automobiles and televisions are more constrained to specialists albeit still with its hobbiests. Eventually, you will have a generation that just hardware as just a machine again, and have no clue of the process.

    Adhere my words, the machines shall rule...

  59. Re:Maybe you don't understand Java? by encoderer · · Score: 1

    Who said anything about Java?

  60. Re:Really ? by sm62704 · · Score: 1

    Maybe it has more to do with the skill of the developers than anything else

    OS A has ten programmers working on it.
    OS B has two hundred programmers working on it.
    OS C has fibe hundred thousand programmers working on it.

    Which OS is most likely to have the programmer with the most skill?

    --
    mcgrew's razor: Never attribute to stupidity that which can be explained by greedy self-interest
  61. Re:Really ? by Tacvek · · Score: 1

    He was obviously trying to reference the 8086 compatibility inherent in Real Mode. (Some Bios'es limit the first few instructions to 8086 compatible code, despite real mode have some newer 80186 and I think even 80286 instructions available. It does seem a bit odd that there is a mode in current gen processors, (which by the old naming would be 80686, and by modern naming is 686) for the 8086 ( which by modern naming would be the 86, or perhaps 086). However, I must say that is excellent backwards compatibility.

    --
    Stylish sheet to fix many problems in Slashdot's D3: https://gist.github.com/801524
  62. Re:Really ? by ArAgost · · Score: 1

    My vote for the best post of the year 2008 goes to parent. To be perfect though, I think it needs to talk about at least Haskell and mySQL :)

  63. Re:Really ? by alextmqazwsx · · Score: 1

    And i think Spore for Mac runs in Cider/Wine. This is based on the fact that the creature creature trial uses it.

  64. Re:Really ? by kipman725 · · Score: 1

    it's a net gain as money is irelivent as long as you have enough of it to survive and persue your interests. aquasition of wealth is only a means to do other things.

  65. Re:Really ? by petermgreen · · Score: 1

    The problem isn't so much the raw price as other related considerations.

    I can't just tell a non techie to buy themselves another gig of ram, I have to check what type it needs, check the motherboard and OS aren't at thier limits already (in which case tough luck, they simply can't have any more without making other potentially expensive changes). I may have to order more to make up for memory that is going to get pulled out (which drives up the effective cost per gig of the upgrade) and finally I will probablly have to fit it for them.

    The same goes for disk space, they can't just pay 50 cents and get another gig of disk space, To get disk space at a reasonable price per gig they have to buy in units of at least 160 gigs or so. Again compatibility has to be checked, someone has to do the installation and depending on the machine an existing drive may have to be replaced (which in addition to it's affect on the effective cost per gig will also mean a load of downtime while the data is copied)

    and then there are laptop users and worse users of flash based ultraportables to consider.

    --
    note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
  66. Re:Really ? by ewanm89 · · Score: 1

    I'm currently studying CS at university. This is why I have my own micro-controllers, I already learnt to code and I have efficiency arguments with my lecturers etc. I even have friends who want to learn this stuff, and we help each other to do so. Of course this is where I get moaned at for have 8GB of ram in my desktop, however I always optimise before release of any code. Anther reasons they use java is because the libraries guarantee that they can have basic animation in GUI to keep those where (as likely) it is their first time writing code engaged in programming. I'm not sure this way works to well though.

  67. Re:Really ? by ewanm89 · · Score: 1

    Unless that C is running on the Linux kernel, then it does infinite loops in 5 seconds. :P

  68. vs. speed by tepples · · Score: 1

    But unfortunately, this lack of fluff comes with a drawback: the CPython bytecode interpreter is less efficient than the JVM. In fact, the JVM was found to be faster than CPython for everything but startup time and I/O. From that page, I gather that it's more likely with Python than with Java that you'll have to rewrite an inner loop in C and then recompile it for each CPU/OS combination.

  69. By that metric... by ttfkam · · Score: 1

    Perl, Python, and LISP are all more "obese" than Java.

    --

    - I don't need to go outside, my CRT tan'll do me just fine.