Slashdot Mirror


Red Hat Joins Open Source Java Project

narramissic writes "Red Hat has signed on to Sun's OpenJDK project and agreed to coordinate its own Java development efforts for Linux with the project. Red Hat will align the work it has done on IcedTea (its own implementation of some parts of the Java SE JDK) with OpenJDK. As part of its participation in OpenJDK, Red Hat will eventually create a compatible OpenJDK implementation for its Enterprise Linux distribution and will also use OpenJDK to create a runtime for its JBoss Enterprise Middleware that is optimized for a Linux environment."

121 comments

  1. mono by Miguel+de+Icaza · · Score: 2, Funny

    what about mono?

    --
    Before adopting WHATWG, read the moonlight.NET EULA [http://www.microsoft.com/interop/msnovellcollab/moonlight.mspx]
    1. Re:mono by Alphager · · Score: 0

      what about it? Since when does Sun do mono?

    2. Re:mono by AKAImBatman · · Score: 1, Insightful

      As you may have figured out, that's not the real Miguel. This is his doppelgänger who tries to be funny. "What about mono?" is obviously a gag based on how hard Miguel tries to push Mono as being a one-true-OSS-replacement-for-Java-that-is-potentially-encumbered-but-you're-supposed-to-trust-Miguel-that-it's-not.

      I dunno. I chuckled. Mods, make your own decision.

    3. Re:mono by ChunderDownunder · · Score: 1
      You may wish to check out IKVM.NET

      It's a Java Virtual Machine implemented on top of .NET.

      The author was using GNU Classpath for the class libraries but has recently been integrating the OpenJDK ones.

      Why? To embed Java functionality without a messy JNI layer.

  2. Will anything change for end users? by visualight · · Score: 2, Interesting

    With all the "openness" going on with Java these days will things get even more complicated? I have 3 important commercial apps that run on java, all three have their own run time environments that are incompatible with each other. I have no end of trouble with jre and firefox. I can't count how many times I've had problems with classpaths trying to run java stuff.

    Will the OpenJDK mean another runtime? As in Blackdown, Sun, Open?

    --
    Samsung took back my unlocked bootloader because Google wants me to rent movies. They're both evil.
    1. Re:Will anything change for end users? by Anonymous Coward · · Score: 0

      So when can I use Java websites on amd64?

    2. Re:Will anything change for end users? by petermgreen · · Score: 2, Informative

      You can already, icedtea contains a java plugin from amd64 based on work from the gnu classpath project.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    3. Re:Will anything change for end users? by bytesex · · Score: 3, Informative

      That's not the result of the openness of the JDK or the JVM; the specs for both were always open. Sun always gave you the src.zip for the JDK, and they provided the bytecode spec and in what way to run such bytecode openly and free op charge.

      --
      Religion is what happens when nature strikes and groupthink goes wrong.
    4. Re:Will anything change for end users? by visualight · · Score: 1

      Ok, "openness" is not a factor, but it is yet another runtime isn't it?

      --
      Samsung took back my unlocked bootloader because Google wants me to rent movies. They're both evil.
    5. Re:Will anything change for end users? by Z00L00K · · Score: 2, Insightful
      If you run three different VM:s that are incompatible then something is amiss unless at least one of them is the Microsoft VM that is known to be incompatible.

      Only a few issues makes it harder to run all on the latest SUN JRE, and none of them are considered good programming practice. I suggest that you take that back to the app vendors and tell them to get it right and working on the latest released Java (1.6).

      The major problem I have recognized is actually related more to the centrally distribution of software packages in a company network where an older JRE is installed and overrides the path of the latest JRE. That causes more problems than you deserve. Of course - in the end it depends on the installation software that thinks that since I'm last to be installed I'm the latest version, which is REALLY WRONG in many cases.

      --
      If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
    6. Re:Will anything change for end users? by hey! · · Score: 3, Insightful

      I think the biggest problem with the original write once, run everywhere promise was this: Java was almost, but not quite, an operating system. If you had a system that worked on WinXP but not Vista, you'd fix the problem; you wouldn't tell your customers to install both operating systems on the same machine because he can't. If I had A,B and C that only ran on Windows versions X,Y and Z respectively, I'd take the trouble to make A and B run on Z.

      In Java I can get by with A, B and C each running only on JDK 1.2, 1.4 and 1.6 respectively, but I have to call upon the user, working with the host OS, to deal with any confusion that arises. Now, multiply that by any libraries you use that aren't part of the standard java distribution, and things start to get really interesting.

      In part the problem of Java classpaths is one of an embarrassment of riches. There are so many powerful frameworks and amazingly useful little libraries that are out there, free for the taking. However, once you open that Pandora's box, it isn't simply a matter of write once, run everywhere; you have to deal wit the dependency issues that come out of that box. It can be done, and it's not really all that difficult, it's just one of those craft things that some people seem to have figured out how to do and others seem to leave as an afterthought after all the fun stuff has been finished.

      The embarrassment of riches also applies to the biggest pitfall in Java development: making bad framework choices, which you can do in multiples at the same time on any project. Leaving aside the case where you have a bad framework (the early EJB stuff -- ugh), or where you have made a bad mistake in requirements analysis, there are so many frameworks that are wonderful for one set of requirements and dreadful overkill for others. Working with a set less than optimally chosen frameworks sucks the joy out of a project, as you set aside the pleasure of solving the client's problem for the tedious drudgery of gluing together mismatched bits of architecture.

      --
      Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
    7. Re:Will anything change for end users? by aled · · Score: 1

      I understand that OpenJDK is the open source version of Sun JDK. I'm curious about which are the runtimes that you need to use, or are they 3 different versions of the SUN runtime?

      --

      "I think this line is mostly filler"
    8. Re:Will anything change for end users? by visualight · · Score: 1

      A JRE is installed with the apps, and they have start scripts that setup they're own environment in the running shell, except one that adds itself to /etc/bashrc (I took that out and made a new script like the other two though). I'm not at that workstation but I think all three Sun.

      Anyway, there are different versions of different runtimes and not all apps work with all of these variations, and this sometimes makes me want to throw them all out.

      --
      Samsung took back my unlocked bootloader because Google wants me to rent movies. They're both evil.
    9. Re:Will anything change for end users? by Anonymous Coward · · Score: 0

      Openjdk will hopefully mean an end to jvm multiplications because there will be a system jdk and ISV will have better use it.

      JVM multiplication is a direct result of the provious non-open java

    10. Re:Will anything change for end users? by M.+Baranczak · · Score: 2, Informative

      The src.zip only contained parts of the source code.

    11. Re:Will anything change for end users? by LizardKing · · Score: 1

      It contained all of the JFC that was written in Java, the idea being that this was the stuff to look at for best practices in Java coding. The native code was released under the SCSL (Sun Community Source Code License) which is what kick started the Blackdown project and ultimately brought decent Java support to Linux. The native code stuff was largely uninteresting to the average Java coder so I can understand why it wasn't shipped as part of the JDK.

    12. Re:Will anything change for end users? by LizardKing · · Score: 1

      The answer is not to ship a JRE with your application if it's likely that the user already has one. Alternatively, just ship the most recent JRE, as backwards compatability is pretty darn good with Java and well written code should just run irrespective of whether it was written for 1.2 through 1.6. An example of badly written code is anything that uses the "hidden" sun.com classes, although I have used them myself for signal support.

    13. Re:Will anything change for end users? by Antique+Geekmeister · · Score: 1

      Oh my stars and garters. Editing bashrc directly is begging to break other apps. These modifications should be in /etc/profile.d/jre-[version].sh

      That sort of abuse of the system default settings is another reason I detest the Sun installers.

    14. Re:Will anything change for end users? by mercadodiego · · Score: 1

      IMHO I think that OpenJDK is an unnecessary effort. Apache Harmony project has the same principle. It would be better to spend that effort in some other open-source project.

    15. Re:Will anything change for end users? by MinnowGuy · · Score: 1

      You can use something like the OSGi framework to wrap library jars and manage classpaths. There are several solid implementations.

  3. parallel universe by squoozer · · Score: 2, Insightful

    I must have slipped into a parallel universe or something because it's starting to look like Java might finally make it's way onto the Linux platform in a useable way. Fair enough we have been deploying Java apps on Linux boxes for a while but it's been much harder than deploying a PHP, C, C++, etc etc application. That always struck me as strange because I would have thought that Java was the perfect language for open source projects. Fairly quick, simple to develop in, stacks of libraries, popular.

    --
    I used to have a better sig but it broke.
    1. Re:parallel universe by Antique+Geekmeister · · Score: 1

      You mean they might pry the installer out of Sun's hands? Great!

    2. Re:parallel universe by Anonymous Coward · · Score: 1, Interesting

      Fairly quick, simple to develop in, stacks of libraries, popular. Not to mention it's great for creating slow, unresponsive, hideously ugly GUI's. What's not to love about that?!

      Seriously, though, Java rocks, but Swing needs to die. At the very least it need to do a wxWidgets and actually look and feel native. The "Native" L&F in Java 6 is much better than Java 5, but it's still freaking ugly and stands out horribly. Even after all of these years and the increases in processor speed an memory, Swing apps still feel very unresponsive. I'm not saying SWT is the answer (Eclipse rocks) as it still doesn't look fully native (select boxes, for example), but it does feel significantly faster and is much easier on the eyes.

      At least if they can't get it to look native, they should at least get it to look decent. That ugly purple theme needs to go away.
    3. Re:parallel universe by morgan_greywolf · · Score: 5, Informative

      I must have slipped into a parallel universe or something because it's starting to look like Java might finally make it's way onto the Linux platform in a useable way. Java has been available and has worked well on the Linux platform for years. The main problem in trying to deploy Java on most Linux distros is that the more popular distros started putting GNU Java and GNU Classpath as the default Java VM and classpath on Linux. Sun's Java has been available in binary form for as long I've been using Linux (I started using Linux in 1994). I'm not sure when they started offering source, but it's been available, too, and things like Blackdown have been based on it for a long, long time.

      And there are plenty of nice Java apps and environments on Linux -- Eclipse is one of the big ones, obviously. The bottom line is that gcj/gij gave Java on Linux a bad name because standard Java apps and programming examples never have worked on it right. Install Sun's JRE/JDK or Blackdown, and you'll find that Java works great on Linux.
    4. Re:parallel universe by Wolfger · · Score: 0

      Fairly quick, simple to develop in, stacks of libraries
      You're talking about Perl, right? I would not call Java "fairly quick" or "simple to develop in". When a Hello World takes more than one line of code, it's most definitely not simple to develop in.

      Now popular I'll give you... but I don't think popular == good.
    5. Re:parallel universe by EricTheRed · · Score: 5, Informative

      The main problem with unresponsive Swing apps, is that most developers do everything within the Event thread, so the app is unable to respond in a reasonable manner.

      If Swing developers remember to move intensive operations off the Event thread and into a background thread, then Swing app's are really nice and responsive. It's not that difficult, but for some reason most developers are either unable to, or unwilling to do this simple task.

      Believe me, I've seen the source of plenty of Swing app's that have been written with everything in the Event thread and the developer (one of whom I had employed at that time) refused to do this because they couldn't be bothered.

      As for the look and feel, it's getting better but it still has a long way to go.

      --
      Java gaming nut - http://www.retep.org/ or for the rail http://uktra.in/
    6. Re:parallel universe by M.+Baranczak · · Score: 1

      The reason they used the wacky GNU Java is that Sun's licensing made it hard to include their Java on free distros. This is now changing, fortunately. In Ubuntu, you can now install the Sun JDK with apt-get, just like any other package. (I think you have to activate the Universe repo first... it's been a while.)

    7. Re:parallel universe by morgan_greywolf · · Score: 1

      The reason they used the wacky GNU Java is that Sun's licensing made it hard to include their Java on free distros. Hence the reason for the existence of Blackdown: it was created specifically to allow the free distros to include a Sun-compatible JRE and JDK.

      I imagine with Java going Open Source, the need for Blackdown will end.
    8. Re:parallel universe by Anonymous Coward · · Score: 3, Funny

      public class HelloWorldDemo {public static void main(String args[]){System.out.println("Hello World");}}

      How many lines?

    9. Re:parallel universe by heffel · · Score: 1

      Sun's Java has been available in binary form for as long I've been using Linux (I started using Linux in 1994).


      Quite an amazing feat since Java didn't come out until 1995. When I first started working with Java (1996) there was no official Sun Java under Linux, there was a port from BlackDown (their web site seems to have gone AWOL recently).



      I can't remember exactly when Sun added Linux as an officially supported platform, however I know it wasn't from the get go. As a matter of fact, the number one bug in Sun's Java Bug Parade for a long time was a petition to officially support Linux.

    10. Re:parallel universe by petermgreen · · Score: 1

      That always struck me as strange because I would have thought that Java was the perfect language for open source projects. Fairly quick, simple to develop in, stacks of libraries, popular.
      But not foss leading to poor integration with linux distros.

      Hopefully it won't be too long before the remaining encumbered components are properly replaced and opensource java becomes a part of all major general purpose linux distros.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    11. Re:parallel universe by Anonymous Coward · · Score: 1, Funny

      At least 5, but you apparently had a problem converting from unix to dos line endings before you posted. Also, it contains a bug, as the title of your post is not the same as the class name.

    12. Re:parallel universe by Dragonslicer · · Score: 2, Funny

      You're talking about Perl, right?... When any program you can possibly imagine takes more than one line of code... Fixed that for ya.
    13. Re:parallel universe by Anonymous Coward · · Score: 0

      > The main problem with unresponsive Swing apps, is that most developers do everything within the Event thread, so the app is unable to respond in a reasonable manner.

      Which is the same way they do it in every other framework. Swing is slower than the others and now it is all Swing users fault? I can understand that for very large operations but if I have to create a thread for every event driven operation, I am done for.

      > Believe me, I've seen the source of plenty of Swing app's that have been written with everything in the Event thread and the developer (one of whom I had employed at that time) refused to do this because they couldn't be bothered.

      Multi-threaded programming is just hard. Perhaps he felt that he wasn't paid enough for that?

      > As for the look and feel, it's getting better but it still has a long way to go.

      Translation: Swing sucks.

    14. Re:parallel universe by EricTheRed · · Score: 2, Informative

      > Which is the same way they do it in every other framework. Swing is slower than the others and now it is all Swing users fault?

      I wasn't blaming swing users, but from past experience most don't follow the Swing event model, even when it's documented well. Virtually all are creating swing objects outside of the Event thread (EDT).

      > I can understand that for very large operations but if I have to create a thread for every event driven operation, I am done for.

      No is did not say for every operation, I said for the expensive ones like file or network IO. When swing appears slow 99% of the time its because of something in the background holding up the Event thread.

      > Multi-threaded programming is just hard.

      Sure it can hard if you have to handle concurrency, but what I was trying to say here isn't that hard.

      Making the Action (running inside the EDT) invoke some code within a thread Executor or thread pool is only a couple of extra lines. Making state changes to a swing component to display the result is a couple of extra lines (using SwingUtilities.invokeLater()). That's not hard at all...

      > Perhaps he felt that he wasn't paid enough for that?

      As for if he wasn't paid enough, that didn't come into the equation. Yes he was a junior developer, but he refused point blank to learn which the other junior developers (not just the Java ones) were eager to do.

      --
      Java gaming nut - http://www.retep.org/ or for the rail http://uktra.in/
    15. Re:parallel universe by marcosdumay · · Score: 1

      Assuming you are using a x86, then yes, Java is available for you on Linux. Don't try to be cute using 64 bits, if you do so you'll start to see the limitations.

      Also, the Linux jre has a different set of bugs from the Windows one, and since both sets aren't small (try to do anything different from what the designers intended and you'll see them) Java tends to not be very portable.

    16. Re:parallel universe by Anonymous Coward · · Score: 0

      I wasn't blaming swing users, but from past experience most don't follow the Swing event model, even when it's documented well. Virtually all are creating swing objects outside of the Event thread (EDT). Since when were you not allowed to create Swing objects outside of the event thread?

      The answer is since Java 1.4, if I'm not mistaken. (Or maybe 1.3? I don't know.) Sun used to say that there was nothing wrong with creating Swing objects in any thread, with a few caveats. (Namely that, once the object was visible, it could only be accessed from the event thread.)

      Now they say you're only allowed to do Swing-related work within the event thread. This is new and a change from earlier versions, and it's why so many programmers don't know about it. Sun's tutorials were full of examples of creating Swing UIs in just any thread and then making it visible. You're not allowed to do that any more.
    17. Re:parallel universe by 0xABADC0DA · · Score: 1

      Which is the same way they do it in every other framework. Kindof. In Swing all of a GUI runs through the same event loop, so while something is processing an event all parts of the GUI are frozen. In other toolkits a lot of basic functions like redrawing are handled by the OS or by a separate thread that manages low-level gui 'controls'. In Swing you can have for instance a drop down list with tables as the entries instead of names. But since the GUI is are so flexible nothing can be done really while other events are being processed.

      Also, some toolkits allow the application to 'cooperatively' multitask the event loop, for instance Qt has something like "eventLoop->processEvents(noUserInput)" that you can call from time to time during your long-running operation to repaint the GUI. Of course your application might crash because some event caused the object you are working on to be free'd. Or it might paint the wrong information, or do all kinds of badness.

      Swing is actually a really freakin' awesome toolkit for creating the building blocks of a GUI and for creating new components. It's just really bad at being an application GUI since your application code is running in the same mix as all the little details of a component. What they should do is create a 'application GUI' layer on top with simpler component APIs that just handle the high-level logic of the component -- these can run in a separate thread so that all the layout and repaint can still happen while your slow processing code is busy. Like have a list component where you can add a freaking string entry without having to have some custom ListModel. If you need the low-level stuff only then do you need to worry about threads and repaints and all the other little details.
    18. Re:parallel universe by jma05 · · Score: 2, Interesting

      > Swing is actually a really freakin' awesome toolkit for creating the building blocks of a GUI and for creating new components. It's just really bad at being an application GUI since your application code is running in the same mix as all the little details of a component.

      This is unfortunately true of all of Java. At one end it tried to provide a low level virtual "machine" and the framework accordingly, and at the same time pretends to be a business class, high level framework. Likewise, the language is fine as a base but unsuitable for productivity. Java language (as opposed to the VM and the framework) should take a backseat similar to how C is regarded everywhere else. It should be a language for the tools, for performance and to provide a standard interface (cf: C data types and the OOP flavor in this case) and then step out of the way. JVM languages should respect this interface but take over what exactly goes on in the methods. Much of this has already been realized in made-for-JVM languages such as Groovy. They just need to get the same love from Sun.

      Java badly needs a REAL framework on top of the present API that can provide productivity in level with Delphi and .NET. I don't mean something along the lines of Swing Application Framework. A proper framework should be flexible and yet simple enough for a VB developer to pick it up in a weekend. Delphi's VCL fits this bill well. With respect to framework design in terms of developer usability, Java has been a step backwards from what was available in 1996. Of course, there are a lot of nice things about Java when compared to the tools then but the disadvantages seem unwarranted.

    19. Re:parallel universe by chrb · · Score: 1

      Hence the reason for the existence of Blackdown: it was created specifically to allow the free distros to include a Sun-compatible JRE and JDK.
      No, it was created because there was no Sun JDK for Linux. Blackdown predates Sun's official Linux port.

      I imagine with Java going Open Source, the need for Blackdown will end.
      The Blackdown project has already closed.
    20. Re:parallel universe by TheSunborn · · Score: 1

      In other toolkits a lot of basic functions like redrawing are handled by the OS or by a separate thread that manages low-level gui 'controls' What other toolkits would that be? Both Win32 and QT have the same basic problem, that you MUST recieve events in the gui thread, and that the gui thread is the only one that draw. So if you recieve an event end do a
      while(true) { } neither win32 or qt will redraw your window.

      The basic problem is that neither windows gui(win32) nor X11 are thread safe, and that they use the same thread to draw and handle events.

    21. Re:parallel universe by chrb · · Score: 1

      The reason they used the wacky GNU Java is that Sun's licensing made it hard to include their Java on free distros.
      Hence the reason for the existence of Blackdown: it was created specifically to allow the free distros to include a Sun-compatible JRE and JDK.
      Red Hat wanted an open source Java stack that they had some control over, so that they could do development, bug fixes etc. Neither Sun's JDK or Blackdown were open source, so they heavily invested in gcj and classpath, porting Openoffice to use both, to try and head off the possibility of Openoffice (and eventually, the Linux desktop) becoming dependant on something over which they had no control.
    22. Re:parallel universe by HiThere · · Score: 1

      Like NetBeans?

      Sorry, but NetBeans has convinced me that even Sun selected specialist experts can't write a responsive GUI in Java. The reason why may be debateable, the fact is observable.

      Also, I've heard lots of complaints about the responsiveness of OpenOffice. I'm presuming that these are from people who are using versions that aren't compiled with gcj...but if that's what makes the difference, then it's Java rather than Swing that's the problem. (N.B.: This *IS* a presumption. I've noticed that OpenOffice on the Mac is unresponsive, but it's running via X layered on top of the Mac OS. NeoOffice seems to be ... sort of OK, but not comparable to a gcj compiled OpenOffice on Linux. Too many variables, but the position of the jvm is suspiciously central.

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
    23. Re:parallel universe by Anonymous Coward · · Score: 1, Insightful

      The problem with you argument is SUN never managed to create a good installer. People didn't use gcj because they preferred it they used gcj because red hat/fedora/debian packaged it and (unlike SUN) knew how to create working linux installers

      So SUN gave Java on Linux a bad name by making its stuff harder to install than alternatives

    24. Re:parallel universe by EricTheRed · · Score: 1

      > Since when were you not allowed to create Swing objects outside of the event thread?

      > Now they say you're only allowed to do Swing-related work within the event thread.

      That's because Swing is not a thread safe API. The EDT is responsible for executing any method that modifies a component state, including it's constructor.

      I know that many tutorials (even some of Sun's older ones) show this, but if you check some of the more recent tutorials, they will show that even main() should create Swing components from within the EDT.

      --
      Java gaming nut - http://www.retep.org/ or for the rail http://uktra.in/
    25. Re:parallel universe by noldrin · · Score: 2, Interesting

      Actually Sun precompiled Java consistently causes processes to hang and I end up needed to kill -9 firefox. Now that I have the open source sun java compiled by Fedora the system is rock solid and haven't needed to kill -9 firefox once. I've had the same results with flash vs gnash. Besides being overly restricting, closed sourced software just tends to suck more.

    26. Re:parallel universe by EricTheRed · · Score: 1

      > Like NetBeans?
      >
      > Sorry, but NetBeans has convinced me that even Sun selected specialist experts can't write a responsive GUI in Java. The reason why may be debateable, the fact is observable.

      I agree with you. I actually use NetBeans all the time, and it's one of the things that's annoyed me the most that it becomes unresponsive, like during a refactor. Why the hell that's running in the EDT I don't know.

      This does boil down to what I originally said about a lot of developers (and in this case Sun's own "experts") not following that simple rule.

      Here I'm currently working on a Swing app that has a lot of network IO in it and I'm taking a lot of care to ensure that the GUI is responsive. The amount of extra code, negligible. It just takes a couple of extra minutes to think things through before typing it. Not that hard, and yet you get an app that doesn't piss off the users.

      --
      Java gaming nut - http://www.retep.org/ or for the rail http://uktra.in/
    27. Re:parallel universe by chromatic · · Score: 1

      Also, I've heard lots of complaints about the responsiveness of OpenOffice. I'm presuming that these are from people who are using versions that aren't compiled with gcj...

      OpenOffice.org is primarily C++. As I understand it, a few parts of the database layer use Java, but most of the source code is and always has been C++.

    28. Re:parallel universe by FunkyELF · · Score: 1

      If Swing developers remember to move intensive operations off the Event thread and into a background thread, then Swing app's are really nice and responsive. It's not that difficult, but for some reason most developers are either unable to, or unwilling to do this simple task.
      Doing trivial stuff on another thread is easy but its a pain in the ass when you need to access a class's members or methods from within an Anonymous inner class. What Java needs is closures, then there wouldn't be any excuse for not using a new thread. I started to program Swing the right way for a while but I'm finding myself doing more and more on the EDT just because anonymous inner classes are a pain.
    29. Re:parallel universe by HiThere · · Score: 1

      In that case it's *really* strange that the version I installed on Debian was labelled compiled with gcj. And it's strange that the version on the Mac crawled, while The Gimp ran fine. Still, too many variables.

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
    30. Re:parallel universe by LizardKing · · Score: 1

      NetBeans wasn't written by Sun, they bought out the original developers, by which time it was already a clusterfuck. There's an article by Gosling (can't find the link at the moment, but that's beside the point) where he describes it as a good example of how not to write a Swing app. The trouble is that people see the Reflection API and don't think how inefficient it can be. This is largely Sun's own fault for emphasising the use of Reflection when they started pushing the whole Bean concept.

    31. Re:parallel universe by LizardKing · · Score: 1

      Simply don't use anonymous inner classes. They're the kind of stuff (like the Reflection API) that appeals too much to the former Perl programmer in us all. They may seem to be an elegant feature, but they're more of a hack that's been made to popular by the frequency of their use in example code.

    32. Re:parallel universe by LizardKing · · Score: 1

      Utter bullshit. I develop on NetBSD, using a native build of Sun's JDK from the SCSL sources. I deploy to Linux on x86, x86_64, ppc32 and ppc64 as well as Windows, Solaris and Mac OS X. I've never once run into a problem with portability with my own code, and only once in someone else's code (which used com.sun classes - which is frowned on anyway). Compared to coding in C for POSIX platforms, Java's a fskcing dream when it comes to portability.

    33. Re:parallel universe by aled · · Score: 1

      Didn't you hear? Sun Java implementation is open sourced under GPL. You may want to check jpackage.org if you use an RPM based distribution.

      --

      "I think this line is mostly filler"
    34. Re:parallel universe by aled · · Score: 1

      Some recent components of Open Office are in Java, like database access I believe. The rest is the old C++ code.

      --

      "I think this line is mostly filler"
    35. Re:parallel universe by Antique+Geekmeister · · Score: 1

      Now go look at the SRPM for those jpackage releases. It's fairly nasty to build, and the SRPM's hide a lot of the nastiness. The naming and numbering schemes alone for the different versons of JDK, I mean SDK, I mean "whatever the heck it's called this week" is extremely painful and leads to serious issues with systems that requie two distinct versions of Java for different applications.

      You can work around this with wrappers, but the Sun installation practices make the whole deal pretty painful to deal with.

    36. Re:parallel universe by Antique+Geekmeister · · Score: 1

      You also couldn't compile the Sun Java: the RPM installers, for example, were simply wrappers and the binary blobs from Sun. Didn't we have that argument about the NVidia and other binary blob installers?

    37. Re:parallel universe by ChunderDownunder · · Score: 1
      Cryptic installers are steadily vanishing. :)

      At least on my linux distro, it's integrated with the standard packaging system and, for first-timers, has an installation guide complete with screenshots.

      Since it's now being released under the GPL, no doubt the dialog box asking one to agree to a license will disappear.

    38. Re:parallel universe by laejoh · · Score: 0

      I think you mean:

      echo 'public class HelloWorldDemo {public static void main(String args[]){System.out.println("Hello World");}}' > HelloWorldDemo.java ; javac HelloWorldDemo.java ; java HelloWorldDemo

      Because in perl it would be:

      perl -e 'print "Hello World"';
  4. Sun has found religion.. by downix · · Score: 4, Interesting

    Open Sourced Solaris, SPARC, now Java... Halleluiah cries the OSS choir.

    But seriously, this business move by Sun has made it far more attractive to my company, enabling us to test out Solaris on our existing server before we perform a rollout. In addition, having the source code for the UltraSPARC T1 has enabled us to do research into how the chip functions on a lower level, with an eye to further optimizing our software to perform even faster on it. Sun, you might win over my heart just yet.

    --
    Karma Whoring for Fun and Profit.
    1. Re:Sun has found religion.. by trjonescp · · Score: 1

      Sun, you might win over my heart just yet.
      I don't think they care about your heart. It's your wallet they are going after.
      --
      Only speak when it improves the silence.
    2. Re:Sun has found religion.. by publicworker · · Score: 3, Insightful

      Sun, you might win over my heart just yet.

      I don't think they care about your heart. It's your wallet they are going after. For most geeks the way to their wallet is via their heart.
  5. FYI by Saija · · Score: 5, Informative

    The official news on the red hat site:http://www.redhat.com/about/news/prarchive/2007/sun_java.html/
    because i can't find references on the sun & openjdk site.

    --
    Slashdot ya no es que lo era! ;)
    1. Re:FYI by LarsWestergren · · Score: 1

      because i can't find references on the sun & openjdk site.

      Mark Reinholt (chief engineer for the java platform) blogs about it. Also the experimental Mercurial repositories are open.

      Slightly offtopic, so are the JavaOne 2008 Call for Papers.

      --

      Being bitter is drinking poison and hoping someone else will die

  6. I truly hope for the end of gcj/gij by Anonymous Coward · · Score: 5, Informative

    Why? Sure, it was a novell idea to try and create an open sourced java but the whole arguments which backed it up were false. Many people seriously believed that Sun was not opening up the Java source code period, while in fact that was a mere lie. The Java source code was available but simply licensed in such a way which didn't really go well with some. And so they simply declared it "closed source" and fooled many people into thinking that the Java sourcecode wasn't available period.

    Why I mention this? Because it was perfectly legal to adopt certain pieces and sniplets of code, check the way things were build an adapting those ideas. All of that might have made a difference for the gcj/gij projects. Personally I condemn those 2 projects, but having said that I will have to admit that they did make a good effort.

    But the main reason I hate this stuff with a passion is because its not compatible with Java, and it is my belief that all the nonsense (gcj/gij + the bs about the closed source java) has left Java with a bad name / reputation on the Linux platform. Which I think is unfair and an utter shame. Would this have not been the case I think Java could have lifted some interoperable development movements to higher levels. Sure; it has already done this to some extend and Linux is still a big market for Sun, but when the bs was still spreading you could already easily download binary installers (self extractors) to install Java on Linux. But I have met simply way too many people who had problems to "do java on linux" and when you started disecting the problems it all boiled down to Linux distributions shipping gcj/gij thus resulting in non-working Java software. And as well all know; a good user doesn't blame his tools but the product he's trying.

    I once spend 45 minutes on the Sun Java tutorial and couldn't get some examples to work. Eventually I tried on another platform, that did work, and so I knew where to look. Eventually I ended up dumping gcj/gij and replacing it, unfortunately I think many others ended up dumping Java.

    1. Re:I truly hope for the end of gcj/gij by basiles · · Score: 4, Interesting

      Yes, but a (maybe minor) feature of GCJ is its ability to build self-contained Java applications, i.e. to compile some Java source code into an executable which does not require any previous JVM installed, etc...

      I admit that there are few Java applications (at least on Debian) which are compiled by GCJ and packaged as plain old binary executables. Of course, this means avoiding some fancy Java tricks (the dynamic class loader, some reflection abilities, etc...).

      Still, I believe GCJ does have at least such a niche market (for those few applications which don't want to depend on a JVM being installed).

      Besides, GCJ is GCC based, and GCC is still a nice project (even if it is old).

    2. Re:I truly hope for the end of gcj/gij by Ed+Avis · · Score: 2, Informative

      Well, quite. If Java doesn't have a good-quality, free implementation then I'll dump Java and use something else instead. gcj and gij are heroic efforts but they were always trying to catch up to a semi-proprietary standard.

      'closed source' is an inane term. I don't think anyone from gcj or gij was describing Sun's Java as 'closed source'. It's non-free, which is what matters. Merely being able to look at the source code doesn't mean you have freedom to use, share and change the software.

      --
      -- Ed Avis ed@membled.com
    3. Re:I truly hope for the end of gcj/gij by Anonymous Coward · · Score: 0
      >Why? Sure, it was a N ovell idea to try and create an open sourced java but the whole arguments which backed it up were false.


      There, fixed that for you.

    4. Re:I truly hope for the end of gcj/gij by Anonymous Coward · · Score: 0

      Posting as coward,

      I wholeheartedly agree. We should dump gcj/gij.
      Folks at Ubuntu need to do this, it's hurting the adoption of their OS by Java developers.
      I have to COMPLETELY un-install EVERYTHING AND ANYTHING Java, then install Sun's JDK for
      anything to work, NetBeans, Tomcat, JavaKit, etc...
      Get Rid of It!

    5. Re:I truly hope for the end of gcj/gij by dan+the+person · · Score: 1

      I truly hope for the end of gcj/gij

      I think there is still a place for gcj as a native java compiler. What's stopping them now compiling against the OpenJDK class libraries instead of classpath? Should be a huge improvement for compatibility.

    6. Re:I truly hope for the end of gcj/gij by civilizedINTENSITY · · Score: 5, Informative
      Actually, instead of the end, this is just the official beginning: From the intro at http://gcc.gnu.org/java/

      Compiled applications are linked with the GCJ runtime, libgcj, which provides the core class libraries, a garbage collector, and a bytecode interpreter. libgcj can dynamically load and interpret class files, resulting in mixed compiled/interpreted applications. It has been merged with GNU Classpath and supports most of the 1.4 libraries plus some 1.5 additions.
      From TFA:

      Red Hat has signed Sun's OpenJDK contributor agreement and will now align the work its done on its IcedTea project, which was its own implementation of some parts of the Java SE JDK, with OpenSDK, said Shaun Connolly, vice president of product management for JBoss. IcedTea brought together the Fedora project with key Java technologies in a Linux environment, and currently provides open-source alternatives for the few remaining proprietary sections in the OpenJDK project, he said.
      Yet looking into the IcedTea project:

      Red Hat has launched the IcedTea project, with the goal of creating a hybrid fully free Java implementation based on OpenJDK and GNU Classpath. The project replaces binary plugs that are still non-free with code from GNU Classpath "We have been working within Red Hat to replace these binary plugs with free software based on GNU Classpath and to remove the need for bootstrapping with unfree software. This is important for a number of reasons, the most pressing being that only free software may be used to build operating systems like Fedora", said Andrew Haily on an OpenJDK newsgroup.
      Also, Wikipedia references "Wielaard, Mark (2007-06-07). IcedTea. Retrieved on 2007-06-09":

      IcedTea replaces the binary plugins with the equivalent GNU Classpath code, compiles it all using GCJ and optionally bootstraps itself using the HotSpot Java Virtual Machine and the javac Java compiler it just built.
      So again, this is not the end of end of GCJ but part of its validation.
    7. Re:I truly hope for the end of gcj/gij by petermgreen · · Score: 1

      IcedTea replaces the binary plugins with the equivalent GNU Classpath code, compiles it all using GCJ and optionally bootstraps itself using the HotSpot Java Virtual Machine and the javac Java compiler it just built.
      That wikipedia quote is neither entirely accurate or entirely up to date

      Initially icedtea was built with ecj as the compiler running on gij (a close relative of gcj and often packaged with it which may be where the idea that it was built with gcj came from).

      Right now icedtea only builds with older versions of icedtea though they are trying to fix that.

      So again, this is not the end of end of GCJ but part of its validation.
      While it won't be the complete end of gcj/gij/classpath it seems very likely to me that every major general purpose linux distro is likely to move to openjdk based java as the default java implementation. The gnu java stuff may remain as a bootstrapping system and some bits of code from it may either be merged into suns tree or kept in distro operated branches (like icedtea is now) of openjdk but I don't see much future for it beyond that.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    8. Re:I truly hope for the end of gcj/gij by Anonymous Coward · · Score: 0

      "You could already easily download binary installers (self extractors) to install Java on Linux"

      And every one who had to use them on production system hated them with a vengeance and spent the past years praying either for gcj to crush SUN Java or SUN to liberate its Java.

      The reason being: SUN has no fucking clue on how to make a good Linux software installer. SUN never made the effort to understand the platform and ignored Linux bugs even when they made it to the top-25 bug parade.

      Oh sure the SUN installer worked for Java hobbyists that were ready to devote as much time on updating Java as updating the whole of the rest of the system. For everyone else it was and is a nightmare.

      You can have all the nice code you want if you're utterly unable to deploy it it's not used (except by vendors of expensive J2EE solutions were paying someone to deploy this stuff is nothing compared to the licensing prices)

    9. Re:I truly hope for the end of gcj/gij by chrb · · Score: 1
      You are glossing over many of the legitimate concerns people had with Sun's Java. Your argument basically boils down to "Linux users were stupid, they tried Java but got GNUs gcj, didn't realise the difference, and complained that it was Java's fault. Every problem they had stemmed from gcj, not Sun's Java, which rocked and had no problems". Well, that's one possibility. You might like to also consider some others: that Java was marketed as high performance but found lacking, that distributor's couldn't ship Sun's Java, that neither Java nor Blackdown or the libraries were actually opensource (yes, if you jump through some hoops you could get *some* of the source, but if you jump through hoops you can also get the Windows CE source, but that doesn't make Windows CE "open source").

      Java source code was available but simply licensed in such a way which didn't really go well with some
      What, like not allowing distributors to apply bugfixes and ports, compile a JRE+libs, and shipping it to end users? You don't see why not being allowed to do these things might pose a problem for a Linux distributor?

      but when the bs was still spreading you could already easily download binary installers (self extractors) to install Java on Linux.
      The problem people had with this approach is that self extracting binary installers were already obsolete. Dpkg/Rpm/emerge track every single installed file. Those self extracting installers write files all over the file system without any regard to native packaging. And the license prevented distributions from shipping their own pre-packaged JRE.
    10. Re:I truly hope for the end of gcj/gij by HiThere · · Score: 1

      This is a part of the confusion over the term "open". "Free" would have been more appropriate, but would have had it's own sorts of confusion.

      Sun's license was "open" in the sense that you could see the code. It wasn't "free" because you couldn't redistribute it. This made it unuseable by Linux distros. To avoid confusion over price, they said the code wasn't open. Technically the wrong term, but free would have caused as much, or more, confusion, and many more people would have thought that they were lying.

      Yeah, I dumped Java because of this (and other reasons), but it wasn't out of misunderstanding. It was because it kept getting broken. (I also really detest the way that they handle files...even though I understand some of the reasons for their choices.)

      P.S.: When I installed Sun Java on Linux, I could always get it to work except in places where others were also having trouble. gcj I have trouble with because of scanty documentation, and because I'm not really familiar with the linker, building library files, etc. I've usually been able to work through any adequately documented example, I just haven't been able to adapt it and keep it working. I think the gcj documenters expect one to be familiar with compiling with gcc and g++, which I'm not. (The documentation REALLY needs to be improved! It's almost absent.)

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
    11. Re:I truly hope for the end of gcj/gij by Anonymous Coward · · Score: 0

      I definitely agree. It would be awesome if we could port the GCJ compiler to OpenJDK and produce native apps, as well as interpreted ones.

      This is similar to what .NET has, with their ngen compiler and dynamic interpretation options.

    12. Re:I truly hope for the end of gcj/gij by civilizedINTENSITY · · Score: 1
      "Initially icedtea was built with ecj as the compiler running on gij (a close relative of gcj and often packaged with it which may be where the idea that it was built with gcj came from)."

      Isn't it "a part of", rather than "a close relative to"?

      GNU Interpreter for Java (GIJ) is a Java bytecode interpreter for the Java programming language. It is part of the free software GNU Compiler for Java (GCJ). GCJ is the compiler counterpart to GIJ.
      And in fact, to make it really confusing, since the GCJ is part of GCC...

      The GNU Compiler for Java (GCJ) is a free software compiler for the Java programming language that is part of the GNU Compiler Collection. It can compile Java source code to either Java Virtual Machine bytecode, or directly to machine code for any of a number of CPU architectures. It can also compile class files containing bytecode or entire JARs containing such files into machine code. Almost all of the runtime libraries used by GCJ come from the GNU Classpath project. Since gcj 4.3 (currently alpha), it is integrated with ecj, the Eclipse Compiler for Java.
      ...then we could accurately, but with loss of detail say, "its all really just GCC".

      In terms of this Eclipse Compiler for Java, it is perhaps worth noting:

      June 6, 2006 RMS approved the plan to use the Eclipse compiler as the new gcj front end. Work is being done on the gcj-eclipse branch; it can already build libgcj. This project will allow us to ship a 1.5 compiler in the relatively near future. The old gcjx branch and project is now dead.
    13. Re:I truly hope for the end of gcj/gij by petermgreen · · Score: 1

      Isn't it "a part of", rather than "a close relative to"?
      Not sure, they are seperate binaries in the gnu compiler collection (gcc) but I think gij is part of the gcj project.

      But to me "built with gcj" implies built with the gnu java compiler not built with some other compiler that happens to be running under gij/classpath.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
  7. Other Linux Java Options? by tji · · Score: 1, Interesting


    My problem with the Sun JRE is that it is HUGE. Why do I need 100MB+ to run a simple Java application?

    Are there other good JRE options for Linux? Maybe something geared towards embedded environments?

    1. Re:Other Linux Java Options? by Saija · · Score: 3, Informative

      Thats the reason because sun is working in what they call "the consumer jre", please check this pages: http://weblogs.java.net/blog/chet/archive/2007/05/consumer_jre_le.html/
      and this https://jdk6.dev.java.net/6uNea.html/

      --
      Slashdot ya no es que lo era! ;)
    2. Re:Other Linux Java Options? by drig · · Score: 1

      There's Kaffe at http://www.kaffe.org./ It's an optimized version for embedded uses (either embedded in devices or embedded in a larger program). It's not 100% compatible, but I believe it's more than usable for many purposes.

      --
      Citizens Against Plate Tectonics
    3. Re:Other Linux Java Options? by Anonymous Coward · · Score: 0

      How is Java a learning language? Many of the worlds leading companies use it for enormous applications.

      Ease does not mean it's a toy language. I can do all the "hard stuff", I can even write my own C complier(I've done it), but why would I want to?

      Why would I want to bother with all that when the VM can do it for me? This allows me to work on what really matters and create applications way faster. It's all about trade offs, you trade a little bit of speed in runtime for a big gain in development time and portability.

    4. Re:Other Linux Java Options? by quintesse · · Score: 4, Informative

      That number is a bit exaggerated, my install of the latest Java 6 JRE is about 80MB (and the download is only 14MB).

      One of the reasons it's so big is because it has a LOT of functionality. But you're right of course when you say that you don't need all of that to run a simple Java application. So Sun decided to do something about that: in the upcoming Java 6 Update N (what was previously called the "Consumer JRE") only a relatively small "kernel" will be installed which has only the most essential components. The rest will be downloaded "when needed".

    5. Re:Other Linux Java Options? by Anonymous Coward · · Score: 1, Interesting

      Dude, you should know by know that "embedded" and "garbage collection" don't go well together. At least for most embedded applications I'm familiar with - flight simulators, heart monitors, anti-lock braking and engine control systems, etc. Real-time performance and "oh, I'm just gonna spend half a second over here reclaiming memory, don't mind me!" just don't go together. Yes, I know there's been talk of real-time friendly garbage collectors, but .. well, I won't believe it until I see it in action, and if it doesn't perform any better than systems with manual memory management then I won't bother.

    6. Re:Other Linux Java Options? by drig · · Score: 1

      Of course, I forgot J2ME. That's the "mobile" edition, designed for space/cpu constrained mobile devices.

      --
      Citizens Against Plate Tectonics
    7. Re:Other Linux Java Options? by deander2 · · Score: 5, Informative

      My problem with the Sun JRE is that it is HUGE. Why do I need 100MB+ to run a simple Java application?

      you don't. a simple stroll over to java.sun.com will show you that the JRE is 14M for windows and 18M for linux.

      the "100M+" is if you're also downloading all their development tools and documentation (and possibly netbeans, depending on the link). not atypical in the least.

    8. Re:Other Linux Java Options? by civilizedINTENSITY · · Score: 1

      "Download the final release of the .NET Framework 3.0 Runtime Components" results in a 50.3 MB executable being downloaded. Surely this is compressed. Does anyone know if JRE is as large as the .NET "RE"?

    9. Re:Other Linux Java Options? by Anonymous Coward · · Score: 0

      Java == High Level Language.
      C == Low Level Language.
      The End.

      Pascal *IS* the learning language.

    10. Re:Other Linux Java Options? by civilizedINTENSITY · · Score: 1

      From MSDN:
      Deployment in Visual Studio
      Deploying Prerequisites (Visual Studio)
      In order to successfully deploy an application, you must also deploy all components referenced by the application. For example, most applications created with Visual Studio 2005 have a dependency on the .NET Framework; a required version of the common language runtime must be present on the target computer before the application is installed. The deployment tools in Visual Studio 2005 enable you to install the .NET Framework and other components as a part of your installation -- a practice known as bootstrapping.

      The following components are included in Visual Studio 2005:

      Microsoft .NET Framework 2.0
      Microsoft .NET Framework 2.0 Language packs
      Windows Installer 2.0
      Microsoft Visual J# .NET Redistributable Package 2.0
      Microsoft Visual J# .NET Redistributable Package 2.0 Language packs
      Microsoft Data Access Components 9.0
      Microsoft SQL Express 1.0
      Crystal Reports for .NET
      Microsoft Data Access Components 2.8
      For both Windows Installer and ClickOnce deployment, bootstrapping of the .NET Framework is enabled by default. You can disable bootstrapping for the .NET Framework, but you should only do so if you are sure that the correct version of the Framework is already installed on all target computers or if your application does not require the Framework. Additional components should be bootstrapped only if your application has a dependency on them.

    11. Re:Other Linux Java Options? by bberens · · Score: 2, Insightful

      If you need Real Time efficiency use specialized hardware, OS, and not Java. If you're making a little app that you want to be able to run on virtually any cell phone on the planet... use Java. Use the right tool for the job. How difficult is that?

      --
      Check out my lame java blog at www.javachopshop.com
    12. Re:Other Linux Java Options? by damaki · · Score: 1

      This stuff is the fucking java holy grail. I develop mostly java applications and was always astonished that there is no way to lazily load the core libs as separate parts and not as a huge stinky whole. Sure, once it's loaded, it's fast, but I really would prefer a faster load of the needed classes and small hiccups when I dynamically try to load a partial lib.

      --
      Stupidity is the root of all evil.
    13. Re:Other Linux Java Options? by petermgreen · · Score: 1

      From that page

      "The fix, then, is for us to take advantage of the disk cache to make sure that the memory pages on disk that we must read at startup have already been loaded before we need them. How do we do this? We cannot magically pre-load the pages just prioir to launching; unfortunately, the VM currently lacks the ability to see into the future to detect when the user will be launching Java (we would love to have this feature in the future, but it is not yet present). But we can pre-load at some earlier time, such as Windows boot or login time. And we can keep the pages warm in the disk cache as machine and memory conditions allow."

      I translate that from sales speak to english as

      "we can't get the bloat down to a level that will give acceptable startup times so we are going to hide it in the windows boot process"

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    14. Re:Other Linux Java Options? by prefect42 · · Score: 1

      You can call it interpreted if you're trying to win a pub argument, but JIT compiled code very much different.

      --

      jh

    15. Re:Other Linux Java Options? by nuzak · · Score: 1

      There isn't just "talk of real-time gc", it's already out there.

      Pardon moi if I would rather not deal with someone forgetting to free mallocs because they decided to shave a few microseconds off something already running within 50 milliseconds of deadline. Especially when the controller is buried under 10 tons of concrete.

      Anyway, the research that's all the rage these days is static garbage collection. It works just like manually freeing memory, but you never have to actually do it yourself. It just inserts the proper free statements at the point of execution where it can prove that your data is unreachable. Systems like this tend to be a bit more conservative (not to be confused with conservative collectors) and might hang on to your data a bit longer, but how many times have I seen freed memory dereferenced later?

      --
      Done with slashdot, done with nerds, getting a life.
    16. Re:Other Linux Java Options? by Anonymous Coward · · Score: 0

      Compression. The installers are, not surprisingly, compressed.

      And my JRE - just the JRE - install of the latest version of Java is 82MB. The JDK dwarfs it at 164 MB, and that doesn't include the documentation. (Which dwarf both, combined, at 272MB.)

      Java is massively bloated. I don't know where to start. It could be the two GUI libraries. The three RPC libraries. The two XML parser libraries. The JavaScript interpreter. (Really!) The two different I/O libraries.

      I'm sure I could go on, but you get the picture.

    17. Re:Other Linux Java Options? by jeks · · Score: 1

      There is no good reason not to use Java for real time systems as well. The very first JSR, JSR#1 proceeds to specify what is required for real time Java. Later, it has been enhanced in JSR#282, which is implemented in The Sun Java Real-Time System 2.0 (Java RTS).

    18. Re:Other Linux Java Options? by ttfkam · · Score: 3, Informative

      What does the uncompressed local copy have to do with download times? 14MB compressed takes just as long as 14MB uncompressed. If you think that your CPU can't handle fast decompression, just think of all of the web sites that gzip their content for network efficiency.

      As for the complaint about docs, are you serious? Are you seriously complaining that there is too much documentation available in HTML format? And optional documentation at that? Think about what you're saying for a second: that you consider it a drawback that every class, method, and member of the JRE is consistently documented in detail.

      GUI: AWT versus Swing are native widget peers versus internally rendered widgets.

      RPC: RMI, CORBA, and XML-RPC/SOAP are for the following in order: RPC in a 100% Java environment, cross-platform binary RPC, and XML text-based RPC. There is a place for each of those.

      XML parsers: are you referring to the SAX, DOM, and StAX parser APIs -- which would make three? Or do you mean two parsers like Crimson and Xerces. I think the former is self-evidently a good thing. The latter is due to compatibility and consistency through multiple releases as the older parser behavior may be necessary for an older app even if it's a little slower or more memory inefficient.

      I can see your argument against including a scripting language, but Sun wanted to include a reference implementation of their pluggable scripting interface.

      I/O: Blocking vs. non-blocking. What's the problem? Both have their uses.

      What you call bloat, some would call completeness. Let's compare against some other popular languages.

      Common Lisp: 10MB
      Latest Python download for OS X: 17.9MB
      Latest Perl download for OS X: 33.5MB (Linux version is between 18.9 and 24.8MB)
      Latest Ruby (without Rails) download for OS X: 13.71MB

      But don't take my word for it. Download for yourself. The only reason these other languages seem smaller to you is because they are bundled seamlessly with your Linux distribution.

      Want database access, RPC, non-blocking I/O, XML parsing, etc. from those languages? Too bad, that's another download. Sure there are resources like CPAN, but why are their cores so bloated? Somehow Java is able to provide all of those "bloated" APIs at about the same download size as those languages that lack them.

      And don't get me started on C and C++. They don't even have a standard database layer, XML library, or the like for you to download separately. Learned one non-blocking I/O library? Too bad, your new company uses a different one. Do you think ODBC is a good solution? Obviously you've never programmed for it.

      I'm sure I could go on, but you get the picture.

      --

      - I don't need to go outside, my CRT tan'll do me just fine.
    19. Re:Other Linux Java Options? by Anonymous Coward · · Score: 0

      Before of the "pacto con el diablo", this was java-1.7.0-icedtea-1.7.0.0-0.19.b21.snapshot.fc8.src.rpm.
      After, how to will be it?

    20. Re:Other Linux Java Options? by Antique+Geekmeister · · Score: 1

      Could I hire you to rewrite the US tax code?

    21. Re:Other Linux Java Options? by petermgreen · · Score: 1

      no

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    22. Re:Other Linux Java Options? by Ryu_Zwei · · Score: 1
      Comparison to dotNET

      The download size for the dotNET 2.0 Redist package is 22.4MB.
      The dotNET 3.0 Redist is 50MB for x86 and a whopping 90MB for x64.

      According to M$,

      System Requirements: (2.0)
      ...
      Disk Space Requirements: 280 MB (x86), 610 MB (x64)
      Not quite small. If the 2.0 framework install is 27 times larger than the download for x64 architecture, does that mean the 3.0 install is 2.4GB??

      The JRE is huge, because Java applications are not 'compiled', they run on a virtual machine. dotNET code isn't really compiled either. All of the programs are compiled to run on the framework. It's not like they are compiled to machine code.

      Programmers are no longer encouraged to try to optimize code.
      Just because we aren't encouraged to optimize, doesn't mean that a good programmer won't do it anyway.
  8. IcedTea will be in Fedora 8 by Anonymous Coward · · Score: 0

    Fedora 8 will be available on the 7th ( Wednesday ).
    IcedTea is only on i386 and x86_64, there are issues compiling it on PPC and PPC64. Also, there are some classes that are simply stubbed out, the actual code has not been released by Sun because of copyright or licensing issues. Some classes where the code was not released have been filled in by the Classpath project code.

    Applets run much better under IcedTea than GCJ.

    Oh, and help is needed to package NetBeans for either Fedora or JPP.

  9. Mutant bastard! by Anonymous Coward · · Score: 0

    Let this mutant bastard die in a closet, already!

  10. That's how flash won the web by porkThreeWays · · Score: 2, Informative

    It's probably too late for java to overtake flash in that market segment, but if Sun had originally done this, they would have probably won the web war. The two biggest complaints about java are, the JRE is too big to download, and the programs take too long to start. This is 99% of people's impression of java. They don't care that it's perhaps one of the best general purpose languages out there right now. They care it takes 10 seconds longer than flash to run a simple program. Sun should have never half-assed that aspect. Either do it right or don't do it at all.

    --
    If an officer ever threatens to taze you, say you have a pacemaker.
  11. but... by Anonymous Coward · · Score: 0

    will it run linux?

  12. Getting harder to choose: Java or Python? by pembo13 · · Score: 1

    How do you folks intelligently and objectively choose between Python and Java? Or at this point is it a subjective decision?

    --
    "Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
    1. Re:Getting harder to choose: Java or Python? by jpfed · · Score: 4, Informative

      They each have their advantages and disadvantages. According to the great computer language shootout, Java is faster by an order of magnitude, but is more verbose and usually consumes about twice as much memory. The ultimate decision depends (at least) on your application's needs and the capabilities of the environments you're targeting.

    2. Re:Getting harder to choose: Java or Python? by Anonymous Coward · · Score: 0

      You choose based on the problem you have to solve, who will use it, who/when you have to solve it and what the future of the solution will be. The same way you choose between C/Mono/Java/C++/Perl.

    3. Re:Getting harder to choose: Java or Python? by LizardKing · · Score: 1

      Unfortunately Python's threading is a bit of a joke at the moment, but work is being done to sort this out. Until then, Python's performance is pretty poor compared to Java, although if I had to use a "traditional" scripting language Python and Ruby would be my first two choices with Tcl a distant third and Perl a definite no.

    4. Re:Getting harder to choose: Java or Python? by ChunderDownunder · · Score: 1

      Why choose, you can have both! :)

  13. Closed source by Per+Abrahamsen · · Score: 1

    Sun Java was not open source by the original meaning of the term, which was simply a new more "business acceptable" phrasing for the term free software.

    It is true that the gcj/gij "camp" probably didn't call it closed source, but that is because they were part of the GNU family, who preferred the original term (free software) with all its connotations.

    Later the term "open source" has been diluted on message boards byt people trying to "reverse engineer" a meaning from the name. But this is no different from "free software", which some people also guess includes any software that doesn't cost any money.

    1. Re:Closed source by Ed+Avis · · Score: 1

      I think that calling it 'not open source' is fine but the term 'closed source' sounds lame (IMHO) and is just likely to confuse people.

      --
      -- Ed Avis ed@membled.com
  14. Static typing by Per+Abrahamsen · · Score: 1

    Only one of them has static typing. That alone ought to be the deciding factor for most people, one way or the other. Some people hate static typing, others can't live without it.

    Personally, I find static typing annoying for small programs, and godsend for large programs.

    1. Re:Static typing by dbIII · · Score: 1

      Also in one whitespace has meaning and in the other it doesn't. Some see that as a big drawback and others as a major advantage. Personally I don't like enforcement of readablity to be another source of potential bugs but on the other hand more readable code is easier to debug.

    2. Re:Static typing by DragonWriter · · Score: 1

      Also in one whitespace has meaning and in the other it doesn't.


      Whitespace has meaning in both -- if you don't believe that, try compiling any Java file after removing all the whitespace. Its just that in Java, any contiguous block of whitespace outside of a string literal usually has the same meaning as any other contiguous block of whitespace would in the same place, though there are some exceptions.

  15. this will finally means java for PPC :-) by sid77 · · Score: 1

    RH interest in OpenJDK has some interesting side effects: they're actively working on porting it also to powerpc, both 32 and 64 bit.
    Gary Benson, main RH powerpc developer, is keeping a journal about his work, quite interesting stuff.

  16. Huh? by Anonymous Coward · · Score: 0

    -1, studiously misses the entire point of the conversation.