Slashdot Mirror


Have a Nice Steaming Cup of Java 5

wap writes "The language/VM/religion that everyone loves to hate is now serving another cup: Java 1.5 is ready for download. The new features of 1.5 have been discussed here before. I, for one, welcome our new virtual machine overlord. I have been using the release candidate, and startup times are noticeably faster, as is overall performance, and the new features like typesafe collections and static imports are great to have. Let the Java flames begin!"

859 comments

  1. Thanks to our supporters by NoInfo · · Score: 5, Funny

    "This release was made possible by our world-wide development community.

    Oh, yeah, and ridiculously large settlement payments by Microsoft."

    1. Re:Thanks to our supporters by cermanius · · Score: 1

      Wait, if it was made possible by the world-wide development community, which I'm a part of, where's my damned cut? Where's my pay check?

      Or is this like those Public Broadcasting Station things where it's like "This was made possible by people like you. Thank You. Come again."

      --
      "Don't sweat the petty stuff and don't pet the sweaty stuff." -- by an Unknown Wise man.
    2. Re:Thanks to our supporters by Anonymous Coward · · Score: 5, Insightful

      I hate to say this, but:
      your cut is the fact you can use it for free!

      A. Coward

    3. Re:Thanks to our supporters by Anonymous Coward · · Score: 4, Funny

      You forgot to add "Netcraft confirms it - Java is dying" onto the end. But not a bad effort for a beginner troll.

    4. Re:Thanks to our supporters by grammar+fascist · · Score: 1

      Yeah, but...free as in beer, or free as in speech?

      I WANT EVERYTHING IN THE WORLD ON MY TERMS!

      /me ducks

      --
      I got my Linux laptop at System76.
    5. Re:Thanks to our supporters by coopaq · · Score: 3, Informative
      "This release was made possible by our world-wide development community. Oh, yeah, and ridiculously large settlement payments by Microsoft."

      I hate to say this, but: your cut is the fact you can use it for free!

      I hate to say THIS but that money DID come from me over the course ten years of PC systems with buggy operating systems on them.

      Maybe I should just get a linux PC next time and install Windows if I need it.

  2. My question is... by beware+of+the+robot · · Score: 0, Offtopic

    When is the selv-aware Java version due?

    1. Re:My question is... by Anonymous Coward · · Score: 1, Funny

      When is the selv-aware Java version due?

      Right when it becomes aware of its spelling errors!

      Thanks, I'll be here all week.

    2. Re:My question is... by Anonymous Coward · · Score: 0

      Try the veal!

  3. Comment removed by account_deleted · · Score: 2, Funny

    Comment removed based on user account deletion

  4. I wait! by orangeguru · · Score: 5, Insightful

    I wait for the first bug reports ... and version 1.5.1 ...

    1. Re:I wait! by Anonymous Coward · · Score: 0

      Just look at the bug database on developer.java.sun.com. There's tons of bugs, most of which they have no intention of ever fixing. For a system built on jar (zip) files, you think they'd at least fix my most hated bug which causes the file listing of jars/zips with lots of files to be incomplete!
      I for one hate our VM overlords and my employer's unwillingness to force users to install native apps.

    2. Re:I wait! by saden1 · · Score: 1, Informative

      If you have a variable name or package name called "enum" anywhere in your source code you'll have to replace every instance of it with something other than "enum." Apache Axis suffers from this problem and I am sure a lot of other projects do too. Have fun renaming stuff.

      --

      -----
      One is born into aristocracy, but mediocrity can only be achieved through hard work.
    3. Re:I wait! by Anonymous Coward · · Score: 0

      refactoring

    4. Re:I wait! by Anonymous Coward · · Score: 0

      I'm wondering if enum was not a reserved word anyway.

    5. Re:I wait! by Anonymous Coward · · Score: 0

      Refactoring is too broad and can encompass many things. Renaming is more specific than simply saying refactoring.

    6. Re:I wait! by UfoZ · · Score: 1

      This horrible problem can be solved with approximately one line of bash code, or three mouseclicks in Eclipse.

    7. Re:I wait! by jekewa · · Score: 1

      Nope.

      --
      End the FUD
    8. Re:I wait! by Southpaw018 · · Score: 1

      You mean 5.0.1. Or 2.0.1. Or you might actually mean 1.5.1...what the hell were they thinking with this numbering system? :p

      --
      ACs are modded -6. I don't read you, I don't mod you, I don't see you. Don't like it? Don't be a coward.
    9. Re:I wait! by memodude · · Score: 0

      The language doc you linked to was for Java 1.1 back in 2000.

    10. Re:I wait! by Surt · · Score: 2, Funny

      whew! shift-f6 that was hard.

      --
      "Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
    11. Re:I wait! by markfive · · Score: 2, Informative

      > perl -pi -e "s/enum/myEnum/g" *.java

    12. Re:I wait! by tobinibot · · Score: 1

      Hehe, a fellow IntelliJ IDEA user?

    13. Re:I wait! by Surt · · Score: 1

      but of course! Anyone trying to develop java without it is missing out.

      --
      "Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
    14. Re:I wait! by DChristensen · · Score: 2, Informative

      > perl -pi -e "s/\\benum\\b/myEnum/g" *.java

      Don't forget the \b for word breaks, or you might end up with something a little different than you intended.

      --

      --
      Mac OS X--Unix without the assholes^Whassles.

    15. Re:I wait! by pclminion · · Score: 1
      This only works if the sequence of letters "enum" does not occur anywhere but in the given variable name. Your "solution" would mutate the word "renumber" into "rmyEnumber"

      Having to mass-rename symbols can be a much worse problem than you make it seem. A simple text search and replace isn't smart enough. You need something which actually understands the syntax.

    16. Re:I wait! by pileated · · Score: 0, Troll

      So that brings up another topic: how many languages have to use another language to fix their own problems? And how often is perl the language used to fix things?

    17. Re:I wait! by FnH · · Score: 1

      or alt-shift-r for all eclipse users out there :)

    18. Re:I wait! by markfive · · Score: 1

      That was an exercise left to the reader.

    19. Re:I wait! by aled · · Score: 1

      Nice troll. Not too much bully, not too much subtle, one can smell the irony without tasting it. I would give it a 9.
      However, it's just a troll anyway.

      --

      "I think this line is mostly filler"
    20. Re:I wait! by JamieF · · Score: 1

      Good point! Global search and replace is a feature that's unique to Perl, after all, just like regular expressions.

      OTOH sometimes Perl is the right tool to use for a given problem. In this case it isn't. An IDE is the right tool to use; IDEA or Eclipse can do this more accurately, without fucking up your code as "an exercise left to the reader" turns into iteration after iteration of a not-quite-right regex. ("Oh wait, it can't just be / enum /, it has to tolerate [ and ] and . and + ...") With an IDE it'd be changed, and compiled, and you'd be running the test suite already.

    21. Re:I wait! by saden1 · · Score: 1

      Think outside the box. Renaming things is not as easy as you make it out to be. On a big project you can potentially have 20+ library packages and for every one of those packages that has "enum" anywhere you have to get the source code to the package, make the changes, recompile them, build the library. Of course this assumes that the source code to these libraries are open source. If they are not open source, you have to go to the vendor of the library who in all likelihood will not expedite the request and give you a new library quick. Finally, if you are familiar with formal software development you know you have to perform regression testing to make sure you didn't break anything. I'm also sure you are familiar with the phrase "whatever can go wrong will go wrong." In conclusion, this not an easy task and time is money.

      --

      -----
      One is born into aristocracy, but mediocrity can only be achieved through hard work.
    22. Re:I wait! by Chandon+Seldon · · Score: 1

      Not much. I don't know about Java, but I've written some pretty simple perl code to re-write C, Python, and Perl code. Usually all you have to do is check for word borders (i.e. s/\benum\b/myEnum/g;).

      --
      -- The act of censorship is always worse than whatever is being censored. Always.
    23. Re:I wait! by Anonymous Coward · · Score: 0
      perl -pi -e "s/enum/myEnum/g" *.java

      Can anyone re-write that in Java?

    24. Re:I wait! by AstroDrabb · · Score: 1

      Most Java IDE's make renaming a piece-of-cake. Eclispse and IntelliJ both do it very well IME. As for naming a variable or package "enum", what ID10T Java developer would do that? I come from a C/C++ background and would never name a variable or package "enum" or struct or class or int or string or ... Seriously, what silly Java developer named a variable or package "enum"? Please, if there is _one_ Java develper out there that did name a variable or package "enum", please reply to this post as an AC with the reason _WHY_ you did that!

      --
      If Tyranny and Oppression come to this land,
      it will be in the guise of fighting a foreign enemy. -James Madison
    25. Re:I wait! by AstroDrabb · · Score: 1
      His solution was not complete. If you use the perl \b for word breaks, you get what you want.
      example: perl -pi -e "s/\\benum\\b/myEnum/g" *.java
      The poster above you pointed this out.
      --
      If Tyranny and Oppression come to this land,
      it will be in the guise of fighting a foreign enemy. -James Madison
    26. Re:I wait! by saden1 · · Score: 1

      You've just called quite a lot of smart people at the Apache Foundation incompetent. The reason you wouldn't use enum as your variable name is because enum is a reserved word in C/C++. This is not the case in Java, at least till 1.5. I have used variable named enum in some of my classes and the reason I did that was because 1) it didn't violate the language specification, 2) It was descriptive (i.e. Enumeration enum = getEnumeration();) and 3) becuase I actually had my own implementation of Enumeration since the language lacked C/C++ like enumeration.

      And FYI, I come from a C/C++ background too but that doesn't mean I'll stick to C/C++ rules.

      You might also want to take a look at my response to those who think IDEs can solve your problem easily.

      --

      -----
      One is born into aristocracy, but mediocrity can only be achieved through hard work.
    27. Re:I wait! by AstroDrabb · · Score: 1
      If you paid money for 3-rd party Java code that got hit by this problem, they you have a right to demand a quick fix or take your money somewhere else.

      I still do not agree with you about "Enumeration enum". It never occured to you that Java might get a feature like that one day? Your post said to "think outside the box". To me developers should be "thinking outside the box" about future development. Things like making the code robust enough to add features and try for future language changes. Especially with a language like Java that is still having core changes made to it.

      --
      If Tyranny and Oppression come to this land,
      it will be in the guise of fighting a foreign enemy. -James Madison
    28. Re:I wait! by Yaztromo · · Score: 1
      If you have a variable name or package name called "enum" anywhere in your source code you'll have to replace every instance of it with something other than "enum."

      Yup -- I ran into this test building the jSyncManager yesterday.

      Thankfully it was only four instances, all within the same source file. I fixed the latest CVS copy accordingly, alerted the developer mailing list, and posted a new item about it to our project page on SourceForge.

      Otherwise, so far, so good. I'm looking forward to this release getting much wider availability (ie: on more platforms) in order to use the typesafe collection mechanisms.

      Yaz.

  5. Love the product, hate the hype? by Octagon+Most · · Score: 0, Flamebait

    Is it really Java that we love to hate, or is it the failure to live up to the "write-once, run-anywhere hype"?

    1. Re:Love the product, hate the hype? by isomeme · · Score: 1

      We develop a big, complicated J2EE app under WinXP, and deploy it without modification onto Solaris. Pretty impressive WORA as far as I'm concerned.

      --
      When all you have is a hammer, everything looks like a skull.
    2. Re:Love the product, hate the hype? by jilles · · Score: 1

      Seems to be really write once run anywhere where I work. We develop on win32, we deploy to sun, HP, & wintel (basically any server environment capable of running java). Also we support both 1.3 & 1.4 generation VMs. I'm not sure where this bullshit about write once run anywhere comes from. You'd have to be very thick to still compare things to the long discontinued Microsoft VM which is what I assume you are referring to (last version released around 1998?). We depend on some post 1.3 APIs so we don't support 1.2 and earlier. IMHO java compatibility between platforms is much better than e.g. compatibility between different versions of gcc on the same machine & OS. There are some well documented differences with older versions and some commercial J2EE application servers are buggy (we generally prefer tomcat/jboss for this reason).

      --

      Jilles
  6. Finally! by arhar · · Score: 4, Informative

    I've been waiting for this for a long time! Now waiting for Eclipse to release a working plugin (well, there's this ,but it's not that great.

    1. Re:Finally! by pottymouth · · Score: 1


      This is off topic but I just downloaded Eclipse and I've been using NetBeans. So far I like NetBeans better. What's the advantage of Eclipse. It seems, sort of, awkward and ugly.

      Not flamebait, just the opinion of someone that's been using it for all of 15 minutes. Any insites?

  7. Java is to C as ... by SamSeaborn · · Score: 4, Interesting
    Java is as far above C as C is above Assembly.

    Microsoft was right to be afraid, developing in Java is a delight.

    Sam

    1. Re:Java is to C as ... by Anonymous Coward · · Score: 0

      Microsoft has C# on their side, which is, of course, their interpretation of Java. (Of course, though, since it's Microsoft, you can't buy C# at Starbucks).

    2. Re:Java is to C as ... by uberchicken · · Score: 1, Flamebait

      Oooo but developing in C# and VS.NET with all
      that intellisense is developer paradise!!

      built-in installshield stuff, winforms. luvverly.

      If Java is a cup of coffee, C#/VS is a cup of
      sweet sweet chocolate.

    3. Re:Java is to C as ... by NightWhistler · · Score: 3, Insightful

      Depends on what you define as paradise really... around here we "lovingly" refer to the VS.NET Gui builder as "The Blob Generator". All you anti-patterns folks, you know what I mean.

      --
      PageTurner Reader: open-source e-reader for Android with cloudsync. http://pageturner-reader.org
    4. Re:Java is to C as ... by ookabooka · · Score: 1

      . . .developing in Java is a delight.

      Though I do program in java and think it can be useful, I am not going to dignify that statement with a response. . .

      Oh crap. . .

      --
      If you are about to mod me down, keep in mind that this post was most likely sarcastic.
    5. Re:Java is to C as ... by JUSTONEMORELATTE · · Score: 2, Insightful

      Java is as far above C as C is above Assembly.
      I was about to mod this as Funny, but then I realized that you weren't making a joke.

      Back in the day, the tagline was "C -- all the speed of assembly, with all the programming ease of assembly."

      --
      Free gmail invites

    6. Re:Java is to C as ... by Anonymous Coward · · Score: 0

      Someone who can mention installshield and paradise in same post is insane!

    7. Re:Java is to C as ... by tgd · · Score: 0, Flamebait

      Honestly, not to start a flame war, I think most people who have used Java and C# would disagree.

      I'm a full-time Java developer, have been for ages, but Java (even 1.5) has a ways to go to be as nice to work in as C#.

      1.5 is a BIG jump forward, but I find it hard to believe you could be so pro Java/anti-C# if you've ever done any real development in both. At best you could six of one/half dozen of the other between them... but its hard to imagine someone thinking Java was that much better.

    8. Re:Java is to C as ... by Chrax · · Score: 0, Troll

      Good lord, have you actually programmed in Java? Object orientation is a terribly inefficient way to program. True, at some points it may come in handy, but I have yet to see an implementation that couldn't be done with fancy subroutines in a function oriented language. Also, what about compile times and the fact that Java actually doesn't work on all interfaces? They changed their virtual machine too much when porting it (seems the only logical explanation to me) and didn't change it in the versions they ported from. (And as a side note, I don't like the fact that you have to type four lines of code to do what C++ could do with a simple cin >> var;

      On another note, why should Microsoft be afraid? Are you under the impression that they own C or C++? The only thing Microsoft's in danger of losing to Sun is the worst implementation of a good idea.

    9. Re:Java is to C as ... by MarkGriz · · Score: 3, Funny

      "If Java is a cup of coffee, C#/VS is a cup of sweet sweet chocolate."

      Too bad you can only drink "sweet sweet chocolate" in a dark, virus infested alley, while coffee can be enjoyed by everyone, everywhere.

      --
      Beauty is in the eye of the beerholder.
    10. Re:Java is to C as ... by Chrax · · Score: 1

      Ah, I see you were referring to C#. I don't particularly use C-based languages (I prefer perl, but I do have a little grounding in C++, and to my great regret, Java), so I don't know much about it. Meh, if it's that bad it wouldn't surprise me, as other Microsoft languages tend to suck, (think Basic and VB.) but I seriously doubt that it could possibly be worse than Java.

    11. Re:Java is to C as ... by Technonotice_Dom · · Score: 1

      Too bad you can only drink "sweet sweet chocolate" in a dark, virus infested alley, while coffee can be enjoyed by everyone, everywhere.

      Unless you believe that the ingredients and recipe of the cup of coffee should be available and distributed with the cup of coffee.

    12. Re:Java is to C as ... by Anonymous Coward · · Score: 0

      "C -- all the speed of assembly, with all the programming ease of assembly"

      Holy Christ, comparing C to assembly is like comparing changing your cars' oil filter by yourself with rebuilding your cars' engine. You need to know where to look and how to access the oil filter for the specific car, but the principal is the same for all cars. Rebuilding an engine requires reams of knowledge on a specific car. In this scenario, Java would be like changing the oil. If you've changed the oil on a car, you can pretty much change the oil on any car without any prior knowledge of that car.

    13. Re:Java is to C as ... by Mant · · Score: 1

      Except you can run C# on Linux with Mono

      Still, lets not let the facts get in the way of a joke ;)

    14. Re:Java is to C as ... by ultranova · · Score: 1

      Unless you believe that the ingredients and recipe of the cup of coffee should be available and distributed with the cup of coffee.

      It's kinda difficult to distribute a cup of coffee without also distributing the ingredients and recipe, since the ingredients make up the substance of coffee and recipe can be reverse engineered from it's structure.

      Besides, .NET programs depend on .NET runtime and native code executables depend on libraries and kernel calls, and thus are no more independent than Java.

      --

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

    15. Re:Java is to C as ... by Anonymous Coward · · Score: 0

      Hey, a two pebble machine could do the same thing too. What nonsense! And please don't confuse functional languages with procedural ones, it makes you sound like you don't know what you're talking about.

    16. Re:Java is to C as ... by Anonymous Coward · · Score: 0

      > Good lord, have you actually programmed in Java? Object orientation is a terribly inefficient way to program.

      You forgot to insert "Java's primitive version of " before your second sentence. No operator overloading, very poor polymorphism, no structural type inference (ok, that's an uncommon feature and comes with its own problems), no multiple inheritance (python and smalltalk don't seem to be too corrupted by it), no ability to inherit from "primitive" types. Not even decent templates (1.5's "type erasure" comes with all sorts of gotchas), let alone algebraic types.

      But hey, a very successful indoctrination program that convinces legions of mediocre programmers that all of these things are icky and dangerous and might cause moral corruption. Java's a mediocre language -- don't let it turn you off completely to OOP unless you have a decent paradigm (ew there's that word) to replace it with.

    17. Re:Java is to C as ... by rishistar · · Score: 3, Funny

      I'm English dammit! I want a cup of tea!!!!

      --
      Professor Karmadillo Songs of Science
    18. Re:Java is to C as ... by mongus · · Score: 1
      C != C#

      The original poster was talking about C which has about as much in common with Java as it does with C#.

    19. Re:Java is to C as ... by Anonymous Coward · · Score: 0

      Good lord, have you actually programmed in Java? Object orientation is a terribly inefficient way to program

      You sound like a first year CS student who failed his OOP class.

    20. Re:Java is to C as ... by sbrown123 · · Score: 4, Interesting

      Object orientation is a terribly inefficient way to program.

      OOP advantage is best seen in large projects. Particullary collaborations. I've worked on large codebase non-OO projects before and know the headaches.

      Also, what about compile times and the fact that Java actually doesn't work on all interfaces?

      Dunno. What interfaces are you talking about?

      Compile times? Java's pretty speedy compiling. Than again, I dont have a 286. Will say this though: Make is a hell of a lot quicker than Ant. Ofcourse you could always use Make for building java though.

      (And as a side note, I don't like the fact that you have to type four lines of code to do what C++ could do with a simple cin >> var;

      in Java would be:

      System.in.read(var);

    21. Re:Java is to C as ... by Bitchslap_69 · · Score: 1, Insightful
      You're confusing development tools with the language and platform. I can say the same thing about developing in Java with IntelliJ (or Eclipse if that's your thing) and a J2EE app server. All kinds of fun stuff to work with in there, but it doesn't affect the basic characteristics of the language itself.

      Don't get me wrong, I like C#/VS.Net quite a lot. But it's a different animal. I can run Java apps anywhere (yes, you can run .Net apps on Linux, but sorry, it's not an official part of the release and is reminiscent of the old Blackdown ports of the JDK/JVM: interesting, but not ready for production), while C# has some great aspects and a bit niftier development environment (I like IntelliJ better for what it does, but there are more tools in VS.Net). But basically C# only overrides Java if you're platform-dependent and I'm not even sure about then.

      --
      -- Bitchslap aka Echo the Wonder Tube
    22. Re:Java is to C as ... by SamSeaborn · · Score: 1
      Good lord, have you actually programmed in Java? Object orientation is a terribly inefficient way to program.

      Oh my.

      On another note, why should Microsoft be afraid? Are you under the impression that they own C or C++? The only thing Microsoft's in danger of losing to Sun is the worst implementation of a good idea.

      Microsoft was afraid of the Java platform.

      Microsoft is successful because they own the platform (Windows). The only way to beat Microsoft is to change the platform.

      When Java emerged, they got scared and were right to do so.

      Sam

    23. Re:Java is to C as ... by uberchicken · · Score: 1

      I'm no Windows-phile, but if I was developing a new gui-based desktop product, I'm pretty much targeting Windows, ummkay?

      So if I'm stuck in this alley of yours, I'm going
      to play with the lego, not the fuzzy felts; and wait for Miguel's mono moped to take me away from the alley.

    24. Re:Java is to C as ... by uberchicken · · Score: 1

      This is not good news. Are you really hating it that much? Seriously, what would you prefer to be using.

    25. Re:Java is to C as ... by E_elven · · Score: 2, Interesting
      --
      Marxist evolution is just N generations away!
    26. Re:Java is to C as ... by tgd · · Score: 1

      No the original poster was talking about Microsoft being scared of Java. Considering Microsoft didn't invent C, and most new development there is in C#, its reasonable to assume if they were scared of Java, it would be because they thought the language didn't stack up to C# not C.

    27. Re:Java is to C as ... by freqres · · Score: 1

      GW-Basic is teh suck, QBasic is teh bomb!

      --
      Rampant Ninja related crimes these days...Whitehouse is not the exception
    28. Re:Java is to C as ... by mongus · · Score: 1

      When he says Microsoft was afraid of Java I think of Microsoft's attempt to pollute Java with J++ long before C# was a consideration. They were afraid of programs being written that don't rely on the Windows platform and are portable across Windows, Mac, and Linux. They attempted to lock Java developers into the Windows platform by introducing core features in their own version of Java that would make programs unusable on other platforms. That was what the Sun - Microsoft lawsuit was all about.

    29. Re:Java is to C as ... by joss · · Score: 1

      He didnt. "function oriented language" is not the same as a functional language.

      --
      http://rareformnewmedia.com/
    30. Re:Java is to C as ... by NoYes19 · · Score: 1

      That will produce an unhandled exception error. And, doesn't even work if var is not type byte[].

      byte[] x=new byte[20];
      try{
      System.in.read(x);
      }catch(IOException e) {
      System.out.println(e);
      }

      And you need to import IOException. icky.

    31. Re:Java is to C as ... by metasyntactic · · Score: 1
      You want a:
      Cup<T>
      ???

      -- Cyrus (http://blogs.msdn.com/cyrusn)
    32. Re:Java is to C as ... by sploxx · · Score: 1

      Heh.
      No one right in his/her mind compares Java with C. Compare it with C++.
      Come back after you learned about the difference between C and C++.

    33. Re:Java is to C as ... by 4of12 · · Score: 1

      OOP advantage is best seen in large projects.

      OOP can be a life saver if applied judiciously.

      For for sheer agony, there's nothing like a large project to show just how awesome a muddy hole you can create with OOP.

      --
      "Provided by the management for your protection."
    34. Re:Java is to C as ... by sbrown123 · · Score: 1

      That will produce an unhandled exception error.

      Yep. Because both "System.in.read" and "cin > var" can both produce exceptions. The only difference is Java requires that you atleast try to do something about it when someone does the unexpected. Sorta like defining var as an int and then someone goes and enters "hello world". I can not image how you could say that C/C++ has an advantage since it lets programmers create easy ways to have their programs trashed.

      And, doesn't even work if var is not type byte[].

      A byte array can convert to all primitives. Its about as base as you can get. Java supports more advanced stream wrappers that extend InputStream if you want simplified methods for particular primitive types. DataInputStream, for example, gives simplified and secure methods for getting ints, chars, longs, shorts, and Strings. For example:

      DataInputStream ds = new DataInputStream(System.in);

      With that you could now do things like:

      ds.readByte()
      ds.readChar()
      etc, etc, etc.

      The wrappers also make the streams very robust with features like i8n and buffering.

    35. Re:Java is to C as ... by Bob+Davis,+Retired · · Score: 1

      Yeah, because device drivers and operating systems are being written in Java and deployed in Java all over the world.

      Moron.

    36. Re:Java is to C as ... by mrawl · · Score: 1

      Compile times are a HUGE advantage of Java. I have worked on countless huge s/w eng projects many with thousands of files scattered over large src trees. With a C compiler it can take ages to compile a mess like that. With Java often it is mere seconds. Because the compiler is launched ONCE. There is no comparison, Java blows C away for compile times. And if you find that is not true, then you don't know how to organise your src code.

    37. Re:Java is to C as ... by ahdeoz · · Score: 1

      Here's the recipe for coffee: Water and brown coloring. Put some sugar or something in there to hide the taste of the brown. It's just there for coloring, the lousy taste is an afteraffect that we didn't get rid of because it turned out to be addictive.

    38. Re:Java is to C as ... by dcam · · Score: 1

      Object orientation is a terribly inefficient way to program.

      and

      And as a side note, I don't like the fact that you have to type four lines of code to do what C++ could do with a simple cin >> var;

      Care to resolve the differences between these remarks? I know it is possible to write non-OO code in C++, but it basically means you are writing C with a C++ compiler.

      --
      meh
    39. Re:Java is to C as ... by ttfkam · · Score: 1

      Pad programmers in any paradigm create muddy holes, not the paradigm. Some paradigms just make it easier to avoid the muddy holes.

      Just as is the case with young children, some programmers just don't get why the older folks avoid the mud. After they have to clean the mess themselves for a change, avoiding the mud becomes important for them too.

      --

      - I don't need to go outside, my CRT tan'll do me just fine.
    40. Re:Java is to C as ... by Coward+the+Anonymous · · Score: 2, Interesting

      " Yeah, because device drivers and operating systems are being written in Java"

      http://jnode.sourceforge.net/portal/
      "The goal is to get an simple to use and install Java operating system..." ;-)

      --
      -- Jason
    41. Re:Java is to C as ... by shutdown+-p+now · · Score: 1

      Unfortunately, WinForms is far away from being a perfect GUI toolkit for developing Windows applications. It's definitely not the best: Qt is much more productive, and good old VCL occasionally beats it as well (owner-drawn controls, anyone?)

    42. Re:Java is to C as ... by x3ro · · Score: 1

      C++ is a superset of C.

      The syntactic (as opposed to architectural) differences between Java and C++ are largely based on the fact that while C++ has backward compatibility with C as one of its core aims, Java has made no such attempt.

      Therefore the comparison (Java vs. C) is a valid one. I would argue that C++'s OO capabilities are crippled by being tied to the legacy of C.

      --
      [ UNSIGNED NOT NULL ]
    43. Re:Java is to C as ... by McPierce · · Score: 1
      Compile times? Java's pretty speedy compiling. Than again, I dont have a 286. Will say this though: Make is a hell of a lot quicker than Ant. Ofcourse you could always use Make for building java though.
      Why would you want to use Make? With Make it would load javac for every single class compiled which is terribly inefficient and slow. With Ant Javac is loaded exactly once and used to compile all classes.
      --
      Darryl L. Pierce "What do you care what people think, Mr. Feynman?"
    44. Re:Java is to C as ... by NoYes19 · · Score: 1

      can not image how you could say that C/C++ has an advantage since it lets programmers create easy ways to have their programs trashed.

      ummm...well I didn't say that so I guess your imagination fits reality pretty well, even if you are delusional on what I say :). You made a false statement; I corrected it; that is all. I am not defending or attacking Java, but you seem a little over defensive.

      IMHO Java is just another language with its own set of strengths and weaknesses, for some problems it is excellent for others a different language works better.

    45. Re:Java is to C as ... by sbrown123 · · Score: 1

      Original statement from Chrax:

      And as a side note, I don't like the fact that you have to type four lines of code to do what C++ could do with a simple cin >> var;


      My response:

      in Java would be:

      System.in.read(var);


      Which you are stated was incorrect because, (quoting you):

      That will produce an unhandled exception error. And, doesn't even work if var is not type byte[] [sun.com].


      But where did Chrax say that var was not a byte array? In fact, he never said what var was. And as I demonstrated with using wrappers you could read all primitive types even if they were not byte arrays. Your other statements were incorrect in that you stated that you need to import IOException which is not true. Infact, you could simply make the method throw an Exception which would not require any try/catch blocks in the method or require importing IOException. Its a bad practice IMHO. In C/C++, you should ALWAYS check for exceptions when reading from stdin. Thats basic good programming practice.


      I am not defending or attacking Java, but you seem a little over defensive.


      Actually you responded to my response to Chrax with incorrect, or probably just misguided, information. Im sorry that misunderstood my response and took it personal.

    46. Re:Java is to C as ... by Kyojin · · Score: 1

      C
      A language with the power and flexibility of Assembly language, with the ease of use of Assembly Language.

    47. Re:Java is to C as ... by rishistar · · Score: 1

      This link gives the full interpreter as well as the lessons.

      --
      Professor Karmadillo Songs of Science
    48. Re:Java is to C as ... by ninejaguar · · Score: 1
      Object orientation is a terribly inefficient way to program.

      But it's a great way to think. And, since it's advisable to think when designing a program, OO becomes appreciably sensible.

      = 9J =

  8. How long will the MacOS X release take? by Offwhite98 · · Score: 5, Interesting

    After they took all that time to rewrite it with the latest API they claim they can closely track Sun releases. This will be the first big thing since then, so it will be a test of Apple to get it out quickly.

    --
    Brennan Stehling - http://brennan.offwhite.net/blog/
    1. Re:How long will the MacOS X release take? by Anonymous Coward · · Score: 2, Informative

      Well there's been a Developer Preview available since June.

    2. Re:How long will the MacOS X release take? by CoolMoDee · · Score: 1

      probably not very soon as the JVM was just updated last week or so.

      --
      Jisho - A Japanese English German Russian French Dictionary for the rest of us.
    3. Re:How long will the MacOS X release take? by adavies42 · · Score: 2, Funny

      I don't know when it will be out, but I can tell you what the Apple headline will be: "Tiger on Tiger".

      --
      Media that can be recorded and distributed can be recorded and distributed.
      -kfg
    4. Re:How long will the MacOS X release take? by Sanity · · Score: 3, Interesting

      Apparently it is planned for release with Tiger, the next major release of OSX. I don't know whether it will be available prior to the release of Tiger, if not, it is likely to prevent most developers from coding in it (what is the point in coding in Java if it won't work on the #2 desktop OS?).

    5. Re:How long will the MacOS X release take? by Anonymous Coward · · Score: 1, Interesting

      It won't take that long. the reason they say they can now track it closely, is that the current impl isn't the nasty hack that was the mrj, but just a simple port of the sun sources, which have been working on freebsd for ages. os9 required complete rewrites/reimplementations of huge chunks of the java api.

    6. Re:How long will the MacOS X release take? by koehn · · Score: 3, Informative

      I downloaded the beta (from where I can't say :-), but it only installs on Tiger (OS X 10.4). Since I don't really want to run a pre-release OS, I took a pass. But JDK 1.5 is coming, it's just several months off.

      But by your post, you had probably already guessed that. At least it's probably less than four years, like it was before Mac folks got JDK 1.2...

    7. Re:How long will the MacOS X release take? by angel'o'sphere · · Score: 3, Informative

      ... it is likely to prevent most developers from coding in it
      Not really. CodeGuide, www.omnicore.com, thats an IDE, has a MAc release since years. That allows using Java 1.5 features in coding. And as you can create byte code compatible with JDK 1.4 released software will run on a Mac as well. Tehre are minor issues however e.g. new methods in java.lang.String wich work fine in the IDE (becase the classpath is different) but not in standalone mode. Nevertheless, I'm coding on a Mac, not necessaryly for a Mac, thats why I use java with generics and the later Java 1.5 betas since over 2 years now. (And since about 14 month on a Mac).

      I would expect that Eclispe and other major IDE vendors have a Mac version bundled with JDK 1.5 runtime libraries as well.

      angel'o'sphere

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    8. Re:How long will the MacOS X release take? by douthat · · Score: 1

      Do you have a link available? I haven't been able to find it.

      --
      She loves me: 09F911029D74E35BD84156C5635688C0 She loves me not: 09F911029D74E35BD84156C5635688BF ...
    9. Re:How long will the MacOS X release take? by Cederic · · Score: 5, Informative

      >> what is the point in coding in Java if it won't work on the #2 desktop OS?

      Perhaps because it will work on the #1..n server OSes?

    10. Re:How long will the MacOS X release take? by Anonymous Coward · · Score: 2, Funny

      So I had the opportunity to talk to some Sun employees a few weeks ago.

      And I asked them, "do you know, will Java 1.5 be in Tiger?"

      And they just looked at me really funny and were like "well, obviously."

      Later I found out apparently "Tiger" is also Sun's codename for their version of the Java 1.5 release.

      Oops.

    11. Re:How long will the MacOS X release take? by joshmccormack · · Score: 1

      "...it is likely to prevent most developers from coding in it (what is the point in coding in Java if it won't work on the #2 desktop OS?)."

      Don't forget Java isn't just desktop.
      Also, presumably it will be available at some point on Mac.
      And speak for yourself. People write software for their own reasons, and it's not always to reach the widest possible audience.

    12. Re:How long will the MacOS X release take? by Anonymous Coward · · Score: 1, Interesting

      (what is the point in coding in Java if it won't work on the #2 desktop OS)

      It doesn't work on Linux?

    13. Re:How long will the MacOS X release take? by Anonymous Coward · · Score: 1, Informative
      what is the point in coding in Java if it won't work on the #2 desktop OS?


      Java already supports Linux.

    14. Re:How long will the MacOS X release take? by Anonymous Coward · · Score: 0
    15. Re:How long will the MacOS X release take? by douthat · · Score: 1

      I still can't find it under there. Are you sure you haven't confused Java 1.5 with XCode 1.5?

      --
      She loves me: 09F911029D74E35BD84156C5635688C0 She loves me not: 09F911029D74E35BD84156C5635688BF ...
    16. Re:How long will the MacOS X release take? by Anonymous Coward · · Score: 0
      no

      but you need to have a select or premier membership to access the java 1.5 preview, since it requires the OS X 10.4 preview (also called Tiger) which is only available to select/premier members at this time.

    17. Re:How long will the MacOS X release take? by Rick+and+Roll · · Score: 1

      I remember hearing that unless you use new libraries, it will work under an old VM.

    18. Re:How long will the MacOS X release take? by BorgCopyeditor · · Score: 4, Funny

      Shouldn't that be: "Hot Tiger-on-Tiger Action"? The spokesmen will of course be Siegfried and Roy.

      --
      Shop as usual. And avoid panic buying.
    19. Re:How long will the MacOS X release take? by KZigurs · · Score: 0

      I was offered to download "Java 1.4 Update 2" today. A great timing ;D

    20. Re:How long will the MacOS X release take? by Anonymous Coward · · Score: 0

      Sun did take their time with JDK 5 official but looks like they didn't ge some things done yet... including the Java Language Spec linked from the JDK 5 Doc page hasn't been upgraded to reflect changes made in 5.

  9. Passe... by gowen · · Score: 5, Funny

    Don't you know, we don't hate Java anymore. These days we all love Java due to its major new feature -- its not C#

    --
    Athletic Scholarships to universities make as much sense as academic scholarships to sports teams.
    1. Re:Passe... by Anonymous Coward · · Score: 0

      Dammed right! I remember trying to code Micro$oft crap WFC GUI code and realizing it was engineered SPECIFICALLY to be incompatible with everyone else and to lock in developers who spent thier lives learning MS's obscure crappinola.

      Java is small and pretty clean like a *nix kernel, with libs and APIs built around it by the world community.

      For that I can forgive a couple langage shortcomings.

    2. Re:Passe... by spellraiser · · Score: 4, Interesting
      Yes, it's not C#, but it is getting closer and closer to being C/C++ (or something very very close). For instance, Java 5 borrows features heavily from C. Just take a look at some of the new features:

      - Generic Types (AKA templates)
      - Enumerated Types
      - Static Import (usage of this looks quite similar to the #define method)
      - Formatted Output / Input (printf/scanf style)
      - Varargs

      I like this trend. These, among other changes in version 5, are all steps towards reducing the awkwardness in the Java syntax that many people complain about. Java is a young, evolving language that still has a lot of potential.

      It is a bit funny, though, that this evolution takes the form of borrowing stuff from an ancient language. Maybe C just got things right in the first place, huh?

      /me puts on a flameproof suit

      --
      I hear there's rumors on the Slashdots
    3. Re:Passe... by Anonymous Coward · · Score: 1, Interesting
      (usage of this looks quite similar to the #define method)
      #define isn't a method, its a preprocessor directive.

      Anyway, adding features like this from C doesn't necessarily make a language better. It just makes it more like C. But given that the aim of a language is to by widely used, and you can't swing a USB cable without hitting a C programmer, thats not necessarily a bad thing either.
    4. Re:Passe... by maxwell+demon · · Score: 1

      Well, generic types are not from C, but from C++ (at least I'm not aware that C would have templates, too).

      For varargs, I really hope they didn't take them from C: Java is designed to be type-safe, and C varargs are the worst thing you can do to type safety at all. Hopefully they found a sane way to implement the varargs functionality (no, I don't consider the C varargs to be sane, it's basically a hack codified into a standard).

      --
      The Tao of math: The numbers you can count are not the real numbers.
    5. Re:Passe... by Moley · · Score: 1
      "Yes, it's not C#, but it is getting closer and closer to being C/C++"

      Or is it getting closer to C#?

      I've been using C# and found a few of the features such as Enumerated Types very helpful compared to using the Java Interface with constants etc...

      I wonder if Java 1.6 will be more like C# 2.0!

      By the way, can't wait to start developing in Java again. As good as C# is for RAD, it's just not Java, despite the added features. Nice to see SUN redressing the balance and adding the stuff I actually like from C# into the new release.
    6. Re:Passe... by gh · · Score: 2, Informative

      Yes, heavy influence from C/C++, but funny thing is that the Java camp has avoided introducing these features until C# made a lot of them popular again.

      New Features in Java 5:
      - Generics (C# 2.0)
      - Enumerated types (C# 1.0)
      - Static import (not available in C#)
      - Formatted output / input (C# 1.0)
      - Varargs (C# 1.0)
      - for loop changes (C# 1.0, equiv foreach)
      - autoboxing (C# 1.0)
      - metadata (C# 1.0)

      In C# 2.0, it will have features that Java 5 does not support:

      - iterators
      - anonymous methods (includes support for closures)
      - nullable types
      - partial classes (good for code generators)

      Not saying C# is the be all end all... in fact, I'm more partial to languages like Ruby. ;)

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

      Generic types - C++, however Java implementation has real dynamic types
      Enumerated Types - Java has real typesafe enumerations
      Static import - isn't like define - in java, public static final is like C/C++ define
      Formated output - was designed so
      Varargs - typesafe

      Of course Java and C/C++ are similar but Java is .... well done.

    8. Re:Passe... by master_p · · Score: 1

      We would have been better if we put garbage collection in C++ and called it Java.

      As for templates, they are a hack. The requirement was to not modify the VM. Therefore, all templates provide is automatic boxing/unboxing. Inside collections, primitives are stored as Object instances.

    9. Re:Passe... by Trejkaz · · Score: 1

      Java announced Generics before C# did, so if it does get closer to C#, we know that it's not Java doing the walking.

      --
      Karma: It's all a bunch of tree-huggin' hippy crap!
    10. Re:Passe... by Trejkaz · · Score: 1

      I assume you mean generics, since Java doesn't have templates. "Template" implies that extra classes are generated, but "generics" simply have type parameters.

      It's a bit annoying, yes, that autoboxing is required to use primitives with collections, but that was going to be a problem irrespective of whether generics were implemented at all.

      I guess we're just lucky that the majority of collections in the real world are NOT of primitive types.

      --
      Karma: It's all a bunch of tree-huggin' hippy crap!
    11. Re:Passe... by Anonymous Coward · · Score: 1, Insightful

      Uhh...Java of course borrows heavily from C and C++, but the language fixed so many problems with C++ objects and C pointers. The requirement for JIT forces certain simplifications into the language and these turned out to provide a more complete and useful language set than the free-for-all that C provides. I personally enjoy the free-for-all in C as it offers the best chance (aside from assembly) to explain to the compiler exactly what you want to do from a performance perspective while Java makes the creation of user interfaces and simple, non-performance critical applications simple and safe to express.

      Awkwardness in syntax? Sorry, just don't see it and haven't heard any legitimate complaints. No, it's not Visual Basic because it actually has to do something. The virtual machine that is provided in Java is generic and a simple environment to code in. The language tends to enforce decent coding style due to the VM restrictions (no odd pointer dereferencing/wordsize assumptions).

      If you are really looking for C/C++, you can always leverage the native integration that has been available since day 1 to ease the migration to the Java platform.

      Hats off to K+R for C is appropriate, but don't revise history by thinking that Java was developed in in vacuo of other languages. It stood on the successes of C and C++ and closed up language holes by providing a better class/inheritance/object representation.

      A.C.

    12. Re:Passe... by fusey_2004 · · Score: 1

      Except Java's generics are nowhere near as powerful as C++ templates. They bottled out and implemented them using type erasure. The main advantage of the generic-based collections is that the compiler does the cast for you -- the bytecode produced is still the same, and the collections are full of objects and implictly cast coming out.

    13. Re:Passe... by dave1791 · · Score: 1

      I assume that the iterator you mention is something different than the iterator available in java.util.Iterator.

      Pardon my ignorance, but what are the other three C# goodies and why would I ever want a "partial" class?

    14. Re:Passe... by FriedTurkey · · Score: 1, Funny

      Yes, it's not C#, but it is getting closer and closer to being C/C++ (or something very very close). For instance, Java 5 borrows features heavily from C. Just take a look at some of the new features: - Generic Types (AKA templates) - Enumerated Types - Static Import (usage of this looks quite similar to the #define method) - Formatted Output / Input (printf/scanf style) - Varargs

      Crap. As a Java programmer, some show off programmer is going to use that crap unnecessarily and I am going to figure what all this stuff means.

    15. Re:Passe... by mcc · · Score: 1

      It is a bit funny, though, that this evolution takes the form of borrowing stuff from an ancient language. Maybe C just got things right in the first place, huh?

      Um, why is this surprising? From the very beginning Java was mostly geared to be a variant of Smalltalk (1978) with C-like syntax.

      Java is less important for its new concepts than it is for the fact that it takes a whole lot of very good ideas from mostly painful languages and puts it all together in a coherent, usable package...

    16. Re:Passe... by jeremyp · · Score: 1

      Generic types are in C++ not C.

      Enumerated types are originally from C++ - backported to C. The Java version is better - it's type safe and also more powerful.

      Static import is closer to const declarations than #defines again a C++ feature backported to C.

      Formatted output is a C feature. I have a love-hate relationship with it. It's great for output to a stream but sprintf is a total mare (how big a buffer should I allocate for the destination?).

      Varargs... hmm not sure about that. The original K&R C just didn't worry about how many parameters you passed a function. The use of elipses in the protoype/declaration came in with ANSI C but I'm not sure if it's a C++ back port. The constructs for accessing the varargs i.e. stdarg.h are just hacks because ANSI C / C++ only implemented half of the feature. The Java version which wraps up all the var args into an array of objects (using autoboxing for primitive types) seems much cleaner.

      --
      All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
    17. Re:Passe... by Anonymous Coward · · Score: 1, Informative

      - Generic Types (AKA templates)


      I know it's somewhat nit-picking, but generics are named differently for a very good reason, template meta-programming (the oh-god-it's-hard-to-get-your-head-around c++) is just not something that java generics, or c#'s upcoming similar feature do.
    18. Re:Passe... by mmusson · · Score: 4, Interesting

      I was actually looking forward to templates in Java but was disappointed once I saw the implementation of generics.

      Every cast operation in Java is expensive because the VM invokes security code to verify that the cast is legal. Java generics don't allow you to avoid the implicit cast so you still get the performance hit. Generics only make the code look cleaner.

      Template meta-programming is also a very important part of the modern C++ libraries and is also something that generics cannot do.

      --
      SYS 49152
    19. Re:Passe... by Anonymous Coward · · Score: 1, Insightful

      It's a bit annoying, yes, that autoboxing is required to use primitives with collections, but that was going to be a problem irrespective of whether generics were implemented at all.

      Why? ML manages generic collections perfectly well without wrapping everything in an object.

    20. Re:Passe... by Anonymous Coward · · Score: 0

      The Java version which wraps up all the var args into an array of objects (using autoboxing for primitive types) seems much cleaner.

      And, of course, something remarkably similar was available at least 6 years ago in Delphi - an underrated language if ever there was one. (The syntax wasn't quite as nice - you had to put [] around the varargs, and you had to manually unbox any primitive types you passed - but the principle was the same.)

    21. Re:Passe... by aminorex · · Score: 1

      Agreed. I used to complain about C++ bloat, and the way it turned every program into a performance dog. Java became the ruling paradigm, and continually pushed the envelope of gratuitous bloat, and managed to make current user interfaces sluggish until the hardware caught up. But C# out does even the antique 1.2 JRE (which was a high water mark for Java resource consumption, but could be run comfortably on a 400MHz K6-2). Just two small C# programs running simultaneously on a 3GHz P4 laptop are sufficient to bring the system to an intermittent crawl, so it's no surprise that Microsoft tells us multiple 3GHz cores and a gigabyte of RAM are needed to run their next generation OS.

      If I were cynical, I'd conclude that Intel had suckered Microsoft into C# by some clever connaivance, to justify new hardware sales. Or perhaps Infineon. It certainly seems as though Microsoft is shooting itself in the foot to spite the marathon, with dotnet.

      --
      -I like my women like I like my tea: green-
    22. Re:Passe... by lpp · · Score: 1
      you can't swing a USB cable without hitting a C programmer


      That sounds like my manager at my old job. Very effective productivity tool. Though he tended to use CAT 5 cable. Seemed to hold up better under repetitive use.
    23. Re:Passe... by Jon+Pryor · · Score: 5, Informative

      My apologies for the horrible look of the code samples. Slashdot won't let me use nice, short lines, as it results in lines which are too short. Gah! Apparently I need ~40 characters per line (average) to get past the @#$% filter... This has to be the most annoying filter I've ever come across; I've spent more time getting past the filter than responding to your question!

      Iterators are similar to java.util.Iterator. C# iterators are compiler support for implementing the System.Collections.IEnumerator interface. For example, in Java you'd write:

      public class MyIterator implements Iterator {
      private String[] hw = {"hello", "world"};
      private int pos = 0;
      public boolean hasNext () {
      if (pos >= 0 && pos < hw.length) return true;
      return false;
      }
      public Object next () {return hw[pos++];}
      public void remove () {throw new UnsupportedOperationException ();}
      }

      public void UseIterator ()
      { Iterator e = new MyIterator ();
      while (e.hasNext())
      System.out.println (e.next().toString());}

      C# iterators make this much easier:

      public IEnumerable SayHello ()
      { yield return "hello";
      yield return "world";}

      public void UseIterator ()
      { foreach (string s in SayHello())
      Console.WriteLine (s);}

      C# iterators are particularly useful when implementing your own collection objects. Google for them; they're very powerful.

      Anonymous Methods are methods without a name, just like Java anonymous classes are classes without a name. Same basic idea, fewer braces. They also act as full closures; while Java requires that all stack variables referenced from an anonymous class be final, C# doesn't require this.

      int n = 42;
      EventHandler h = delegate {Console.WriteLine ("something happened:" + n);};
      h ();

      The above example is bad, but you can let your imagination run wild. This is very useful for event handlers.

      Partial Types

      allow you to split a single class definition across multiple files. This is useful to prevent > 50 KB source files (yech!), and makes it easier to have part of a class machine generated (by a GUI builder) and part hand-written. Some people hate it, others are ambivalent, but it can be handy:

      // File a1.cs
      partial class Foo {public int a;}

      // File a2.cs
      partial class Foo {public int b;}

      Nullable types are primarily useful for database support in the .NET type system. DB types can be "nullable" -- not present. For reference types, this is easy -- use null. For .NET value types, this isn't possible, as value types can't be null. The solution is to introduce a generic class System.Nullable<T>, which can wrap value types such as int.

      The C# compiler adds syntactic sugar to this, to simplify usage:

      int? nullable_int = GetMyNullableInt ();
      if (nullable_int.HasValue) /* use nullable_int */

      Nullable types are more special purpose, but are useful for those who need them.

      Ignore the rest of this: it's just garbage to get past Slashdot's wonderful "too few characters per line" problem: lk jfjdlkajdsfl;kja sdfl;kja fjklsafjd l;kj lasjd lkjds fl;kja sdflkajsd lkj afs lk jfjdlkajdsfl;kja sdfl;kja fjklsafjd l;kj lasjd lkjds fl;kja sdflkajsd lkj afs lk jfjdlkajdsfl;kja sdfl;kja the quick brown fox jumps over the lazy dog l;kajdsfl;kj;lkj l;kjasdilfj l;kjoiewqruq[op 0-9314u75 lkfjx ;lkajdsfmopiac un0p3u5n1-0329u kl 0a9u 3214o5ilj hello out there in tv land! q 09

    24. Re:Passe... by gh · · Score: 1

      Anonymous methods: typically will be used to simplify writing callback/event handling code. Providing closure support also provides useful capabilities that lisp/ruby/etc programmers are familar with.

      Iterators: They provide a language feature to supply the values or implementation of the iterator. So, instead of hand-coding an implementation of java.util.Iterator or the C# equivalent of IEnumerator, the language simplifies it by allowing you to "yield" the sequence of values for the iterator.

      Partial classes: Allows breaking a type definition like a class into multiple files. For a developer doing all the coding for a given class, they really are not that useful and likely should be frowned upon. Where they become useful is in cases where the developer codes part of the class and the remaining part is code generated. Example: a web page.

      Nullable types: When working with value types, there is traditionally no way of representing the absence of the value. Nullable types allows you to specify the full range of the value type (for ex, integer) AND deal with the absence of that value. Usefulness? Interacting with databases.

      (This post was written hastily and not reviewed for spelling/grammar.)

    25. Re:Passe... by cyborch · · Score: 1

      Partial classes lets you split class definition over several files. That way you can hide all the ugly autogenerated code from your gui building tools in seperate files. Partial classes definitely go in the "nice to have" - not the "must have" category.

    26. Re:Passe... by aminorex · · Score: 1

      > Java was mostly geared to be a variant of Smalltalk (1978) with C-like syntax.

      You seem to have mistakenly mentioned 'Java' when
      you meant to say 'Objective-C'. Java's static
      typing and lack of closures makes it much more like
      C++ than Smalltalk, both semantically, and in application. If I were tracing the roots of Java, I would draw a line through C++ straight to Simula (1962-1967). Reading and writing Java code is much more like reading and writing Simula than Smalltalk.

      --
      -I like my women like I like my tea: green-
    27. Re:Passe... by WaterBreath · · Score: 1
      The more comments I see like this, the more I'm convinced that one of the following must be true:
      1. There are a lot of bad programmers out there who don't know how to write anything that's not a resource-hog, or
      2. There are a lot of people who have no understanding of how to choose a language based on the application.
      If you're using C#, or Java, for a performance-intensive application, and you're not an expert in squeezing performance out of that language, then guess what? You're using the wrong language. There is no "best language" for every application, so why do we complain when we can't get a language to do the thing that everyone knows it's not meant for?

      Rule of thumb for the inexperienced:
      C# and Java are good for UI's. VB is good for little UIs and little automated processes. C/C++, Perl, Lisp, etc. are good for apps that are light on the UI and heavy on information processing.

      What's so hard about that?
    28. Re:Passe... by grammar+fascist · · Score: 1

      Generics only make the code look cleaner.

      Generics also let the compiler enforce valid typecasting. It's great to have the compiler catch problems at compile time rather than have the JVM catch them at run time.

      Template meta-programming is also a very important part of the modern C++ libraries and is also something that generics cannot do.

      Template meta-programming is confusing to most people, and generally an absolute nightmare in a business setting. Since Java is aimed at business development (the new COBOL, and all that), it makes sense that it would be somewhat restricted.

      --
      I got my Linux laptop at System76.
    29. Re:Passe... by iabervon · · Score: 2, Informative

      Actually, C/C++ had a lot of good ideas, but it took a while for Java to get them right. The new Generic Types add compile-time typechecking and remove a lot of typecasting without adding a huge amount of complexity to the language like C++ templates do, and without causing multiple copies of the code to be generated. Enums in Java are full-fledged classes of actual objects with methods, unlike in C where they are just markers (they are object constants instead of integer constants; no difference in efficiency for comparison). Static include is actually more like Python's "import", where you can skip the class name for some class statics. Formatted output is much the same, and was just waiting for other features. Varargs has strong checking in Java, unlike C; the called function can limit the type of the extra arguments, can find out at runtime how many it got, and can't run off the end of the set, because it gets them as a Java array.

      Java, unlike C++, has a policy of putting features off to become future extensions any time the language team can't specify them right at the time. C++ is constantly finding that changes they need to make break things that they've been recommending. Java's main mistake so far has been that they didn't have arrays use generic types, so the two don't play quite right together. Of course, that was a matter of historical necessity, because Java wouldn't have gotten to the point where generic types were worked out correctly without supporting arrays.

    30. Re:Passe... by mmusson · · Score: 1

      Generics also let the compiler enforce valid typecasting.

      That's not exactly true. Generics provide automatic typecasting and that's really it. The underlying rules are unchanged.

      One very common construct in generic programming as implemented in other languages is defining a template function that deduces its type at compile time.

      For example:

      public <T> void foo(T o) { o.somemethod(); }

      If this worked like other generic languages, you would be able to make this call passing any type of parameter that included somemethod(). And this would be enfored at compile time.

      This does not work in Java because generics are implemented using erasure. So in this "any" type example, only methods of Object are callable.

      This is unfortunate because it make generics only useful for the casting problem with containers.

      --
      SYS 49152
    31. Re:Passe... by godefroi · · Score: 1

      C# 2.0's implementation of generics removes the casting, whereas Java 1.5's implementation just hides it.

      Note that rumour has it there was a generics package for 1.4 that implemented it the Right Way, but Sun apparently wanted to go the quick way.

      --
      Karma: Poor (Mostly affected by lame karma-joke sigs)
    32. Re:Passe... by Anonymous Coward · · Score: 0

      Both teams have been tinkering with generic support since their 1.0 releases.

    33. Re:Passe... by Anonymous Coward · · Score: 0

      Iterators: They provide a language feature to supply the values or implementation of the iterator. So, instead of hand-coding an implementation of java.util.Iterator or the C# equivalent of IEnumerator, the language simplifies it by allowing you to "yield" the sequence of values for the iterator.

      Actually it looks more like what the scripting language folks call a generator, not an iterator. Same idea, but generators are more general, more expressive, and usually more efficient. The closure that's implicit in a generator makes for an easy way to do ultra lightweight threads -- something Java still can't manage ever since it got rid of green threads.

      Partial classes: also good if you want to implement interfaces or MI in separate files. Though one should imagine that if your class is that complex, maybe it shouldn't be one class...

      Nullable types: Java of course has the lovely property of ALL object types being nullable... What I would prefer is a feature from the Nice language, which is non-nullable bindings. As in, it becomes an error to ever assign null to that variable.

    34. Re:Passe... by psetzer · · Score: 1

      Implementing generics the 'Right Way' would have required making the JVM incompatible with any previous versions. Java lives on its ability for the programs written for it to always work, no matte the platform, and getting rid of that was not an option, period. If they did it the 'Right Way' then nobody would really want to switch to the new VM and compiler. Thus, they went with the 'Wrong Way'.

      --
      "Anyone who attempts to generate random numbers by deterministic means is living in a state of sin." -- John von Neumann
    35. Re:Passe... by mcc · · Score: 1

      Objective C lacks closures as well. Meanwhile Java's anonymous inner classes when used properly allow you to partially regain the convenience of closures, a convenience Objective C lacks.

      True dynamic binding for method dispatch would certainly be a lovely feature, but Java is dynamic enough that much of the functionality lost can be regained by use of the (admittedly clumsy) reflection features.

      Admittedly the list of non-superficial differences between Java and C++ is somewhat short. However these differences are fundamental enough that in practice Java programmers wind up far more likely to use Smalltalk-like principles of coding; it does not have to the same extent C++'s problem of becoming "C with classes" in practice. Java, like Objective C, is legtimately an attempt at a balance between Smalltalk and C, whereas C++ is just a better C. Objective C and Java attain this balance in different ways but overall I do not really think either one is really closer to Smalltalk than the other.

    36. Re:Passe... by sv0f · · Score: 1

      Java is not necessarily borrowing from C(++). There are a lot of other programming languages out there which implement these features (e.g., varargs), some of which the Java developers (e.g., Guy Steele) designed decades ago (e.g., Common Lisp).

      The scandal isn't that Java is borrowing from C++. It's that it has taken so long for "mainstream" languages to provide constructs that should have been there a long time ago.

    37. Re:Passe... by Anonymous Coward · · Score: 0
      Java are good for UI's

      umm were you serious? Java is really best for web application development.

    38. Re:Passe... by BorgCopyeditor · · Score: 3, Funny
      Very effective productivity tool. Though he tended to use CAT 5 cable.

      Ah, yes. The old "CAT-5-o'-nine-tails."

      --
      Shop as usual. And avoid panic buying.
    39. Re:Passe... by Baki · · Score: 4, Informative
      In Java5 you would write the C# iterator just about the same.

      For example

      for (Shape tShape : pList) {
      System.out.println("X is " + tShape.getX());
      }

    40. Re:Passe... by M.+Baranczak · · Score: 1

      Iterators: They provide a language feature to supply the values or implementation of the iterator. So, instead of hand-coding an implementation of java.util.Iterator or the C# equivalent of IEnumerator, the language simplifies it by allowing you to "yield" the sequence of values for the iterator.

      How often does anybody ever do that, though? The only time you'd have to implement java.util.Iterator is if you were writing your own container class, (a pretty rare case) and even then you might be able to avoid it.

      Nullable types: When working with value types, there is traditionally no way of representing the absence of the value. Nullable types allows you to specify the full range of the value type (for ex, integer) AND deal with the absence of that value. Usefulness? Interacting with databases.

      All objects may be null in Java, just not primitive types. You could use a java.lang.Integer instead of an int. This would incur a performance penalty, but so would nullable primitives.

    41. Re:Passe... by rreyelts · · Score: 2, Insightful
      Every cast operation in Java is expensive
      I have my own fair share of criticisms to level against Java Generics (no support for primitives, no type reification which leads to bastardisms like Class<T> and limitations like no new T[], etc...), but the cost of a cast has to be the worst criticism I've heard yet to date. A cast is implemented as a single VM instruction (checkcast) which generally takes nanoseconds to execute.
    42. Re:Passe... by Anonymous Coward · · Score: 0

      As someone who once dabbled with Smalltalk for a while before grudgingly going to the more mainstream C++ I can say Java is MUCH MORE like Smalltalk than C++ (that's GOOD by the way).

      In partciular the way it handles references and avoids implicit copying gave me that impresion. It is also more "pure" OO, and has a more academic feel (read: only one way to do things, good safe defaults). So as an ex-wannabe Smalltalk programmer I'd say it is more Smalltalk.

      The only thing it borrowed from C++ was its unfortunate (but very well known) syntax. This made it easier for C++ programmers to accept. I wish they had gotten rid of the word "static" though (which is too overused).

      I have no comment about Simula, since I never coded in it.

    43. Re:Passe... by Anonymous Coward · · Score: 0

      Generics are an abomination, and a waste of valuable resources that should have gone into developing better libraries. Instead they modified a gazillion libraries to add generics support which only got rid of some annoying casts (which aren't that bad anyway). No cost / benefit here..

      I think the smart ones at Sun knew this but caved in at the insistence of C++ programmers who moved too quickly to Java just as STL was getting popular in C++ and hence missed their new found favorite feature.

      Today C++ programmers are saying that templates are really a new style of programming and no longer OO. Fine. But Java is and always should be an OO language.

      Java is smart to be slow at changing the LANGUAGE spec. Instead they should be working on libraries and LEAVE THE DAMN LANGUAGE ALONE.

      (that being said.. I like foreach.. and easiy enums, while not very OO, improve the code a lot of people write because they're too lazy to write a whole class)

    44. Re:Passe... by Anonymous Coward · · Score: 0

      hogwash.. there are a huge number of developers that don't support the addition of generics (tho now they are going to have to live with it).

      There is nothing a "mainstream language should have". Languages have different design philosophies. They aren't all the same (that's the point). Otherwise it just becomes a battle for syntax..

      Don't agree??

      How about:
      - adding generics to Prolog
      - adding generics to Lisp
      - adding generics to HTML
      - adding generics to SQL
      - add a bloody FOR statement to SQL, and assignment too...sheesh!!!
      - add aspects to XML

      See what I'm getting at.. this makes no sense..
      just like your statement that "it has taken so long for "mainstream" languages to provide constructs that should have been there a long time ago".

      You need to take a Computer Languages class and learn what they are for. Or just use Perl or C++.

    45. Re:Passe... by 21mhz · · Score: 1

      Actually, nothing prevents you from implementing typesafe unboxed collections of primitive types in Java (or even natively via RMI). Of course, these collections can't be generic, and using them through normal collection interfaces will still incur boxing/unboxing. But if speed is an issue, even uglier things have to be done routinely.

      --
      My exception safety is -fno-exceptions.
    46. Re:Passe... by gh · · Score: 1

      Actually it looks more like what the scripting language folks call a generator, not an iterator. Same idea, but generators are more general, more expressive, and usually more efficient. The closure that's implicit in a generator makes for an easy way to do ultra lightweight threads -- something Java still can't manage ever since it got rid of green threads.

      Agreed. They should have called it a generator or something similar and said it could be used to implement an iterator.

      Java of course has the lovely property of ALL object types being nullable...

      C# is no different. The difference is that C# allows creation of custom value types which are not nullable. Hence, ironically enough, the need for nullable types.

      What I would prefer is a feature from the Nice language, which is non-nullable bindings.

      I can see that being useful. I'll have to check out Nice. :)

    47. Re:Passe... by bckrispi · · Score: 1

      The "no support for primitives" argument is pretty much a moot point now that we have autoboxing.

      --
      Xenon, where's my money? -Borno
    48. Re:Passe... by gh · · Score: 1

      How often does anybody ever do that, though?

      Not often enough, actually. Yes, one primary use would be with container/collection classes. However, as mentioned in another post it has more general purposes. If you think of it as something that can generate values and not just for iteration it has far more potential.

      All objects may be null in Java, just not primitive types. You could use a java.lang.Integer instead of an int. This would incur a performance penalty, but so would nullable primitives.

      C#, all objects are also null. Value types cannot be null because they are stored on the stack. What you suggest is to box the value, i.e. make it a reference type which is stored on the heap. There can be significant performance penalties for that. From what it appears, they don't cause a boxing operation to be performed for nullable value types. So it may not be as efficient as working with the value type directly, but should be more efficient both from performance and memory usage than boxing the value type.

    49. Re:Passe... by isomeme · · Score: 1

      Actually, they do a lot more than make the code look cleaner. By specifying the type of a collection's elements at run time, generics can move a class of programming errors from run time to compile time. Needless to say, compile time errors are a lot cheaper to find and fix.

      --
      When all you have is a hammer, everything looks like a skull.
    50. Re:Passe... by pthisis · · Score: 1
      public IEnumerable SayHello ()
      { yield return "hello";
      yield return "world";}
      This looks like a generator (a la Icon or Python), which is more powerful than a simple iterator--that is, assuming the "yield return" is basically a limited continuation (ie stores the local state between yields). Generators are very cool.
      http://en.wikipedia.org/wiki/Generator_(computer_s cience)
      http://en.wikipedia.org/wiki/Iterator
      --
      rage, rage against the dying of the light
    51. Re:Passe... by rreyelts · · Score: 2, Interesting
      No, autoboxing suffers an entirely new set of problems. For example, let's take a container, which is the most commom usage case of generics.
      1. You will be forced to box and unbox upon every single access to that container. Boxing can be quite expensive, compared to simple operations, because it will usually involve a memory allocation - which can suffer even more under multiprocessor boxes due to heap contention.
      2. Your container will use a much larger amount of memory compared to an array of primitives. Compare an int[] to a List<Integer>. The int[] will cost you 4*N bytes. The List<Integer> will cost you 16*N bytes - 4*N for the Object[], 8*N for the two-word object header for each Integer, and 4*N for the actual int value stored in each Integer.

      For systems like mine, that store 100 million objects in memory, a 4X memory increase is hugely unacceptable, and the access penalty is also unacceptable. My situation is not uncommon, and it is the reason why libraries like fastutil exist and are so popular.

      I think .NET is mostly a rip-off of the JVM with very little innovation, but they seem to have a much better approach to primitives, with JIT type-specialization

    52. Re:Passe... by metasyntactic · · Score: 1
      Anonymous methods are not full closures, but they come close enough for many situations.

      -- Cyrus (http://blogs.msdn.com/cyrusn)

    53. Re:Passe... by metasyntactic · · Score: 1
      Baki: That is not how you would write the C# iterator, that is how you would write the C# iterator consumer. Consumption of iterators in both languages has been easy from the start using the while/for constructs. However, creating iterators is actually somewhat difficult in C# 1.0 with its cursor based iterators (.Current and .MoveNext) and even more difficult with java's .HasNext and .Next.

      For example, take a tree structure and try to write an iterator for it in java. Now do the same in C#, what you'll see is code like this:

      IEnumerator<T> GetEnumerator() {
      ...foreach (T child in left) {
      ......yield return child;
      ...}

      ...yield return val;

      ...foreach (T child in right) {
      ......yield return child;
      ...}
      }

      Pretty simple to understand and to create.

      -- Cyrus (http://blogs.msdn.com/cyrusn)

    54. Re:Passe... by master_p · · Score: 1

      "I guess we're just lucky that the majority of collections in the real world are NOT of primitive types."

      Speak for yourself. In the real world of OpenGL applications for Java, using GL4J, 3d objects have ints as keys. Each time you click on the screen, the widget callback must use an Integer instance to find which GL object corresponds to the int that OpenGL gives you as the GL object id that is under the mouse.

    55. Re:Passe... by naoursla · · Score: 1

      It is a bit funny, though, that this evolution takes the form of borrowing stuff from an ancient language.

      Yeah! Its strange how all languages seem to converge towards Lisp.

    56. Re:Passe... by Taladar · · Score: 1

      If that is the way you say why did some Java-program (It was Borland Together I think) I had to use a few months ago for my University insist on using a JRE 1.3 instead of using my 1.4 JRE and crashed constantly when I changed the start-script to use 1.4?

    57. Re:Passe... by Anonymous Coward · · Score: 0

      > Yes, it's not C#, but it is getting closer and closer to being C/C++ (or something very very close). For instance, Java 5 borrows features heavily from C. Just take a look at some of the new features:

      I assume you meant C++...

      > - Generic Types (AKA templates)

      Not the same. Nowhere near the same. Templates are glorified preprocessor hacks (that allow a particularly ugly variant of some of the meta-programming techniques the LISP crowd so enjoy). Generic types, unlike templated C++ classes, are compiled _ONCE_ for every type, and are typechecked properly (as far as typechecking goes in Java, that is).

      > - Enumerated Types

      Unlike C, these are actual types and not just "named integer constants". I'm not sure about C++ in this respect, though.

      > - Static Import (usage of this looks quite similar to the #define method)

      Rather pointless, but if it makes people happy...

      > - Formatted Output / Input (printf/scanf style)

      The same can be achieved by class combinator approaches, in a statically typesafe manner (though the Java syntax, about as overly verbose as the syntax of all C-based languages, may wind up breaking your fingers when trying that). Personally, I believe that this "catering to the C crowd" is pointless. I have the same love/hate relationship to printf that everyone else seems to have, meaning that I certainly don't consider it an essential part of any programming language.

      > - Varargs

      Most stupidestest idea ever. (Yes, I know that this is not proper English, but I never claimed to be a native English speaker, or even a proficient one, FWIW.) If someone could please explain to me why a subtyping-based language with polymorphic lists needs varargs (other than that they stupidly used brackets to index arrays (what's wrong with dot notation?), I'd be quite pleased. Although I admit that the "Java way" would probably be to use arrays, as those are significantly more convenient to use (in the cases where they make sense) than Lists. Again, why arrays get preferential treatment over other container types is beyond me.

      Let's get things straight: C is a great portable assembler, available on lots of platforms. It doesn't do escaping closures (or any closures, while we're at it), nested functions and garbage collection, which offends some compiler writers because they have to take care of these things themselves, but good arguments can be made that these missing is a Good Thing.

      C++ is a slightly evolved macro hack on top of C that borrows a few pieces of object-orientedness in order to "allow" OO programming (for sufficiently disciplined programmers). So C++ is essentially a (semi)portable macro assembler language with a handful of additional checks that actually do come in handy occasionally.

      Java, OTOH, wants to be an application-level programming language, i.e. something that we can use to develop stuff other than OS kernels, device drivers, and system libraries that need to interface with the kernel (which is the area where C currently makes some sense (That's C as in C, not as in C++)). I see no reason for an application-level language to borrow _anything_ from an assembly language. (Frankly, the better application-level languages I can think of don't even use imperative programming styles very much...)

      So, where are we now? If we have a look at Java-the-programming-language (minus the bytecode and the embarrasingly stupid idea of using erasure to implement generics-- it's not like toolkits like BCEL and SOOT won't have to be fixed anyway), it looks like a half-decent imperative programming language with good support for object-orientation. What Java should get rid of are some of its weirder ideas such as arrays being special types (have that in the bytecode, if you want to, but keep the language clean), unsigned types being useless, modifications on containers destroying iterator validity, certain operations yielding return values that are useless 98% of the time (java.util.Collec

    58. Re:Passe... by mrawl · · Score: 1

      My God man. And you are actually supporting this absurd train wreck??? Yikes...

    59. Re:Passe... by Anonymous Coward · · Score: 0

      The most important improvement that generics bring is that they allow for compile type type checking when using generic containers. Avoiding casts saves you few keystroke but having making it so the compiler can verify you types means that a whole class of runtime errors have been turned into compile time errors. This is a really good thing.

      I can't say that I would have approved if they would have implemented generics by generating a new class for each type like C++ does. All those redundent class files floating around.. I mean, does java really need to use more memory? The gc team is stressed enough as it is. Did you know that there's supposed to be an extra 43 different garbage collectors types added java 1.6? Those guys haven't slept in 7 years; desperately trying to make up for Java 1.1..

      Template meta-programming using template.. I have always thought that having a turing complete language for a feature that was designed to allow you to reuse datastructures without resorting to anonymous pointers was a tad overkill. I mean why write for the OS when you can just target the compiler and cut out the middle man?

    60. Re:Passe... by ahdeoz · · Score: 1

      I assume you mean "CAT5-o'-eight-tails"

    61. Re:Passe... by Anonymous Coward · · Score: 0

      JDK 5 generics are definitely not the generic-programming cornucopia that C++ templates are.

      They do provide other nice functionality, though. Suppose we want to feed a list of any pets, but only pets?

      Being familiar with generics, we know List is not a subclass of List. In C++ there is no neat way to allow this: our function must accept a list of pets (List), and anyone using List is must convert it.

      However, in JDK 5 generics:

      class Cat extends Pet { .. }
      class Dog extends Pet { .. }
      List<Cat> cats = ..;
      List<Dog> dogs = ..;
      List<Pet> menagerie = ..;
      List<Alien> aliens = ..;

      void feed(List<? extends Pet> pets) { .. }

      // these work
      feed(cats); feed(dogs); feed(menagerie);

      // this will not compile
      feed(aliens);

      Links:

    62. Re:Passe... by ttfkam · · Score: 1

      Then again, this implementation leaves a great deal of room for optimization on the back end in subsequent versions of the JVM without breaking the interface.

      For example, it seems likely to me that Sun (or someone else) would implement a specialization for collections that hold nothing but primitives.

      But for now, you're right. For tight memory needs, it's an issue. The introduction of a preprocessor like with fastutil doesn't sit well with me though. Once you start with a preprocessor, #pragma and #ifdef directive hell is sure to follow.

      --

      - I don't need to go outside, my CRT tan'll do me just fine.
    63. Re:Passe... by Trejkaz · · Score: 1

      I didn't say ALL collections in the real world, I said the MAJORITY of collections in the real world.

      For each and every math-related edge case like OpenGL, there are a hundred business cases where the collection is of objects.

      --
      Karma: It's all a bunch of tree-huggin' hippy crap!
    64. Re:Passe... by vegetasaiyajin · · Score: 1

      Implementing generics the 'Right Way' would have required making the JVM incompatible with any previous versions. Java lives on its ability for the programs written for it to always work, no matte the platform, and getting rid of that was not an option, period. If they did it the 'Right Way' then nobody would really want to switch to the new VM and compiler. Thus, they went with the 'Wrong Way'.


      This is the reason. But it is not a very valid one. The standard library changes from version to version and it is typical that complex applications like applications servers and IDEs (and some simple apps too) do not work in newer releases.
      And of course, new code doesn't work in previous JVMs.

      --

      My heart is pure, but make no mistake, it's pure evil
    65. Re:Passe... by tonejava · · Score: 1

      Sun wants to convert C/++ programmers over to Java while MS want to convert Java Programmers to C#!?!?!?!

      How is that for a trend?

    66. Re:Passe... by Anonymous Coward · · Score: 0

      Every cast operation in Java is expensive...

      I call shenanigans.

      We had this debate at one of my former employers in the Java 1.3.1 days. To resolve it, one of the architects (who was trustworthy and knew what he was doing) wrote a large test where he casted a lot.

      The code with casting actually ran a bit faster.

    67. Re:Passe... by Anonymous Coward · · Score: 0

      java sucks

    68. Re:Passe... by daiakuma · · Score: 1
      It stood on the successes of C and C++ and closed up language holes by providing a better class/inheritance/object representation. I disagree. I think Java is worse than C++ in more ways than it is better. To improve on C++ would have been (a) to make pointers more type-safe, but still keep pointers, (b) to make operator overloading more disciplined, but still keep operator overloading, (c) to place a few restrictions on multiple inheritance, but not replace it with something as extremely restricted as the interfaces mechanism, (d) to replace "for(x;y;z)" with "for x in range y by z", and (e) to make memory management easy for the user by implementing it within the collections library, rather than by imposing garbage collection on everyone. Garbage collection is less flexible than are smart pointers, and makes Java useless for real-time work. Also, destructors should have been retained -- getting rid of them was a major mistake. Destructors are not only for clearing up memory. Refusing to implement generics for many years was a serious mistake as well. Generic programming is, if anything, more powerful than object-oriented programming. Now they have implemented it, but in a way that carries a run-time cost, so they've lost some of the benefits of generic programming. Also, they've implemented it as a bolt-on, as it is in C++, so the syntax is messy, as it is in C++. If they had implemented it from the first, they could have made it very clean and simple. The int/Integer and other non-object/object pairs, with the clunky conversion between them, are a bad thing, too. The collections and algorithms library is very poor compared to STL and Boost. The way they dealt with branches based on boolean types was wrong as well. Branches (if, while, for, etc.) should not be based on the boolean type, but on zero/non-zero (except "for"). I know they were trying to solve the problem caused by ==/= confusion, but they chose the wrong approach. They failed to implement many good new ideas from recent computer science, so, for instance, didn't provide an easy way to turn two values into a range. "For" loops should have been based on a range type, not the zero test inherited from C. Java could have supported functional programming, but it doesn't.

      Finally, and most important of all, Java has committed suicide on the desktop by refusing to licence the implementation of Java-to-native compilers.

      --

      ~~~ Centigrade 233 ~~~ yaku, yaku, yaku!

  10. J2EE --> 1.3.1 still by tezza · · Score: 5, Interesting
    If you develop apps targeted at Websphere 4, say, they're still 1.3.1 spec.

    I look longingly at typed collections to save yet another ClassCastException on anonymous iterators. *sigh* oh well, maybe 6 years from now...

    --
    [% slash_sig_val.text %]
  11. Fuel for th e flame war by OhHellWithIt · · Score: 2, Interesting

    Scott McNealy got my dander up in the quotes in this Government Computer News article.

    --
    "Who controls the past controls the future. Who controls the present controls the past." -- George Orwell
    1. Re:Fuel for th e flame war by Beyond_GoodandEvil · · Score: 1

      I am not surprised that the guy who runs Sun wants the govt. to code in nothing but Java. I was far more disturbed by the, privacy is a red-herring get over it, speech.

      --
      I laughed at the weak who considered themselves good because they lacked claws.
  12. Still no operators... by mirko · · Score: 1, Interesting

    The operators, a^Hthe feature that I just love in C++ is stil not present in Java, ok, it got faster, but still not as fast as C++ too.
    I guess this will finally come but when ?

    --
    Trolling using another account since 2005.
    1. Re:Still no operators... by timbloid · · Score: 4, Informative

      > ok, it got faster, but still not as fast as C++ too.
      > I guess this will finally come but when ?

      Errr...

      Java 1.4 was comparable in speed to C++ (except obviously for Trig which got a huge overhaul in 1.4 and slowed down some)

      It really depends how you write you code... Sloppy C++ code can be slow too.. ;-)

    2. Re:Still no operators... by mirko · · Score: 1, Troll

      This should become part of a choice, it's like templates.
      Actually, the more I code in C++, the more I feel like explorating it further. Its' not the case in Java where it sounds like there's only 1 way to do each thing, mostly because of the plethora of APIs (WebLogic, etc.) that corporations force you to use over it...

      --
      Trolling using another account since 2005.
    3. Re:Still no operators... by mirko · · Score: 1
      Java 1.4 was comparable in speed to C++

      The authors conclude, "On Intel Pentium hardware, especially with Linux, the performance gap is small enough to be of little or no concern to programmers."


      What about Sun/SPARC, Apple/OSX, AMD ???

      BTW, what about GUI programing ?
      I have worked wth Java/Swing and C++"/Qt2 and I have yet to say that Java GUIs are just a pain in the ass to code and to use...
      Qt/C++ is by far the most elegant way I ever coded GUIs for both Linux/Intel and QTopia/ARM.
      --
      Trolling using another account since 2005.
    4. Re:Still no operators... by billr · · Score: 1

      Exploring C++ is fun. I spent awhile doing it, but when it came to meeting deadlines I could do it faster (and better) in Java and have time to go home at night.

      --
      I've finally found the off by one erro
    5. Re:Still no operators... by timbloid · · Score: 3, Insightful

      > Its' not the case in Java where it sounds like there's only 1 way to do each thing

      I take it from this comment that you haven't actually tried java. You can "explorate" to your hearts content, and there are many ways of doing the same thing (some obviously better than others)

      > mostly because of the plethora of APIs (WebLogic, etc.) that corporations force you to use over it...

      Now this comment just has me bamboozled... You mean that Weblogic holds sway over you and force you to code in one way over another? Surely weblogic is just an appserver? Which runs code designed to the standard J2EE API spec? The same as using Tomcat , JBoss or Geronimo or even Hibernate? (All of which are free and opensource, and follow the same J2EE spec that Weblogic does -- they just solve separate parts of it, and can be combined to do it all if you require)... I fail to see how this is a corporation forcing you to use one method of coding?

      Sure, if you are only going to look at one way of achieving your goals, then there is only one way to go...

    6. Re:Still no operators... by mirko · · Score: 1

      I have been using Java for a very long time.
      For private use, it's ok, I like it.
      Not as much as Perl but I like it.

      For corporate use, you have to obey the architect's guidelines and to code in a very specific way... You have to be replaceable and it's not fun to code in Java in an enterprise, especially when you have to do with Weblogic's Beans.

      --
      Trolling using another account since 2005.
    7. Re:Still no operators... by timbloid · · Score: 1

      Ahhhh....I've always steered clear of Weblogic (as it costs money) and stuck with Jboss/Tomcat (and now Hibernate too)... It's a lot less restrictive... (and having had a quick go with Weblogic, I feel your pain) :-(

    8. Re:Still no operators... by MemoryDragon · · Score: 1

      It is a mentality difference. C++ back then was designed with following mentality. Ok we have C, we need OO, add OO, we have this cool feature in language a, we have that cool feature in language b, we add them. Now think that process going on for almost a decade. At the end there is the result: Ok we have a huge bloated language with myriads of features, the user will deal with it and will use what he needs.

      Now we have the java situation: Ok we have C++, tons of features, too complicated, programs are too slow to develop, to insecure, to many pitfalls which basically are a burden on the coding process. Lets strip features out so that there is a minimalist of features but the advantatages and syntax of C++ are not lost.

      Now to C#, ok we have Java, our attempt to take over the language via embrace and extend was stopped by the courts. What are we going to do now. First buy the best people from Borland, second, clone the language, alter the class lib so that it is not that obvious where it came from, and add a few features from C++ again and then start the marketing drums.

      Java again: Ok we have a blatant ripoff of java, they added something again from C++, now lets rethink our strategy, does this feature make sense or not to be added again.

    9. Re:Still no operators... by csnydermvpsoft · · Score: 1

      Maybe for your mid-sized projects you appreciate the flexibility, but corporations with many developers sharing projects benifit hugely from there being one correct way to do things.

    10. Re:Still no operators... by fatphil · · Score: 2, Informative

      Your link points to this obvious nonsense:

      """
      Consider what happens when you do a new/malloc: a) the allocator wanders through some lists looking for a slot of the right size, then returns you a pointer. b) This pointer is pointing to some pretty random place.

      With GC, a) the allocator doesn't need to look for memory, it knows where it is, b) the memory it returns is adjacent to the last bit of memory you requested. The wandering around part happens not all the time but only at garbage collection. And then (depending on the GC algorithm) things get moved of course as well.
      """

      The guy knows nothing about _either_ efficient dynamic memory allocators, nor garbage collectors, he has no right to pass comment on them.

      FP.

      --
      Also FatPhil on SoylentNews, id 863
    11. Re:Still no operators... by Pieroxy · · Score: 1

      I have worked wth Java/Swing and C++"/Qt2
      I have tried C++/XLib and it is a pain. Hence, C++ must be bad.

    12. Re:Still no operators... by LnxAddct · · Score: 1

      SWT is your friend in java.

    13. Re:Still no operators... by Anonymous Coward · · Score: 0

      Java already have plenty of operators.

      There's +, -, ++, =, == and whatnot. Full listing here. ;)

    14. Re:Still no operators... by aled · · Score: 1

      So, you mean that C++ was actually designed?

      --

      "I think this line is mostly filler"
    15. Re:Still no operators... by MemoryDragon · · Score: 1

      Not really, it was more a collection of "cool" stuff in StrStroups mind :-)

    16. Re:Still no operators... by aled · · Score: 1

      What a relief. If that was unintentional just imagine what could had happen if he would have [Shudders].
      If he just had used his powers for goodness...

      --

      "I think this line is mostly filler"
    17. Re:Still no operators... by Anonymous Coward · · Score: 0

      What do you know?

      The fact of the matter is malloc is typically going to have O(log n) or similar performance. It may be tuned to get better performance in many circumstances, but that may also cause it to fragment it's heap under certain scenarios.

      A GC is going to have a O(1) allocator. They just increment a pointer and return the original value. It's also very easy to have thread-specific allocators because fragmentation of the heap becomes a non-issue. The trade off of course is that you have O(?) performance in the GC, where ? sucks. But like heaps, GC programmers have figured out lots of tricks to make ? suck less for the common case.

      The big difference is that in C++ you get the ability to customize your memory management structures. You can malloc a large block, and use it a little bit at a time like a GC would, and then throw the entire thing away. A GC can't beat custom memory management like this, but then again writing custom memory management takes time and effort.

  13. Well for us Apple elitist bastards by antifoidulus · · Score: 3, Funny

    we still gotta wait....come on Steve, get out of the hospital and give us our static imports and generics!

    1. Re:Well for us Apple elitist bastards by Anonymous Coward · · Score: 0

      Your Reality Distortion Field (TM) is out of whack.

      This doesn't exist until it's released on Apple... and then you can claim you've always had it!

  14. I just got my copy... by melted+keyboard · · Score: 5, Funny

    Now let the slashdotting commence!

  15. Linux with AMD 64? by Anonymous Coward · · Score: 0

    Hi
    Does anyone have .jar files (Azures Bit Torrent Client in particular) working with this? I had Limewire working fine but not Azures with the RC of 1.5 on Mandrake AMD 64 rc2.

    Cheers

  16. Stability/memory leaks by B5_geek · · Score: 2, Interesting

    I have found that most (2 of the 3) Java Apps that I used have horrible memory leak issues. I can't let the computer run for more then 3 days or all kinds of funkyness begins (winxp).

    I have been using Sun's JVM. I realise that the memory leaks are very likely the fault of the apps themselves, but it seems that the whole JMV is kinda flakey too.

    Hopefully this new release works better.

    --
    "The price good men pay for indifference to public affairs is to be ruled by evil men." ~Plato (427-347 BC)
    1. Re:Stability/memory leaks by GreenCrackBaby · · Score: 1, Informative
      >Weeks of coding saves hours of planning.


      What an appropriate sig for your comment. The simple fact is that Java memory leaks are pretty common simply because not enough planning goes into coding. A proper UML diagram of an application can go a long way to highlighting possible memory leak situations.

      --

      "The market alone cannot provide sufficient constraints on corporation's penchant to cause harm." -- Joel Bakan
    2. Re:Stability/memory leaks by Tojo-Mojo · · Score: 2, Informative

      Java's garbage collection sort of creates a general laziness among some coders who don't clean up because they don't have to. Without effective clean up routines, like destructors, you commonly end up with a chain that can hold a lot of memory out that is being unused. All it takes is one pointer *ahem* reference to some object that contanis a reference to another, that contains an array... If you've got a few hashes and arrays in the way, it may be difficult to tell exactly where memory is being used, thus memory leaks.

      Also, I don't know for sure, but would what happen if two objects referenced each other but nothing else referenced them. Would gc know to follow the links between the two and see that nothing in the main app is using them?

    3. Re:Stability/memory leaks by MemoryDragon · · Score: 4, Interesting

      Actually no, it is an app problem. Sun has introduced weak references way back in 1.3 to cope with that problem. And I have to admit, I never had any of these problems since 1.3
      But it also could be that your program simply needs a tad more ram.
      Following, check out the -Xmx and -Xms parameters of your application startup file and add more ram (java fetches 32MB in without any params and fills it up before it starts the GC for the first time) That might help.
      But never count memory leaks out, they are very rare, but can happen if somebody has tangling references, pretty much the only case where the Garbage Collector can do basically nothing.
      The VM itself is not flakey, I have a few servers running here, with an uptime of a year already.

    4. Re:Stability/memory leaks by Anonymous Coward · · Score: 1, Insightful
      It's possible to have memory leaks in Java if you don't write your programs well.

      For example, you could have the following code:

      SomeClass hugeObject = new SomeClass();
      hugeObject.loadUngodlyStuff();
      /* hugeObject is a database, and you've just read 256 MB worth of entries into it. It's sitting there taking up memory. */

      hugeObject.doSomeManipulations();

      /* okay, now we're done with hugeObject. We enter some kind of main loop for our program in which hugeObject is never used again, but there is still a reference to it sitting there, and the garbage collector might not know enough to garbage collect it for you JUST IN CASE you might want to reference it later */

      while(true){
      doSomething();
      }

      This could be fixed by inserting "hugeObject = null" right before while(true){...}. So, yes, you can have memory leaks in Java, but if you do, it's really your own fault.

    5. Re:Stability/memory leaks by Anonymous Coward · · Score: 0

      Check if you are using any kind of native classes (such as the notorious Oracle OCI drivers) and/or if you can upgrade or replace them. The native lib thingy is the most vulnerable point in any Java application, not least because they are sometimes written by Java programmers themselves who are usually (but not always) not equipped to deal with memory management intricacies.

    6. Re:Stability/memory leaks by joib · · Score: 4, Insightful


      Java should never have memory leaks...
      All the memory managment should be done by the VM as far as I know...
      unless there is some advanced stuff i'm just not aware of?


      Not memory leaks as such, but "memory leaks" for all practical purposes. How? Well, if you forget to nullify references to objects you no longer use, the garbage collector obviously cannot reclaim that memory..

    7. Re:Stability/memory leaks by Matje · · Score: 1

      o but it does have memory leaks for sure. The only difference with before is, that now you'll have a forgotten reference to a memory structure somewhere. A couple of years ago I developed a java based GUI component, based on an open-source graphics toolkit. That toolkit created it's own thread to keep track of mouse movements (it triggered a custom tooltip).

      Thing was, when you would shutdown my component the mouse thread would not be killed. And since it maintained a reference to some object which maintained a reference to my component instance, the garbage collector would never clean up my component. So there you have it, a memory leak in Java.

      The only realistic way I know of to find these leaks is to use a tool like JProbe, which will show you the references to each instance.

    8. Re:Stability/memory leaks by NoOneInParticular · · Score: 3, Informative
      Also, I don't know for sure, but would what happen if two objects referenced each other but nothing else referenced them. Would gc know to follow the links between the two and see that nothing in the main app is using them?

      Yes, Java's GC would notice that nothing is referring to them and remove the objects. This unlike a simple reference counting gc such as python's which would not notice this. Java's GC can even relocate memory on the fly to minimize page misses and avoid memory fragmentation.

    9. Re:Stability/memory leaks by XbainX · · Score: 2, Informative

      Actually, under certain circumstances the JVM will reclaim non-null references eventually. But you will still experience memory leak type symptoms until either you run out of available memory or the non-null references are cleaned up...

      Java supports various types of references, check here: http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ ref/Reference.html

    10. Re:Stability/memory leaks by Coz · · Score: 1

      Any language can "leak" memory, depending on how the programmers program. See this IBM developerWorks note for a how-it-happens, how-it's-cured tutorial. If Java didn't leak memory, how would JProfiler exist?

      --
      I love vegetarians - some of my favorite foods are vegetarians.
    11. Re:Stability/memory leaks by Anonymous Coward · · Score: 0

      what happen if two objects referenced each other but nothing else referenced them. Would gc know to follow the links between the two and see that nothing in the main app is using them?
      The circularly referencing objects are seen as orphans and are garbage collected.

    12. Re:Stability/memory leaks by ChrisRijk · · Score: 1

      I have a program that runs 24/7 on a server, doing a bunch of networking and text processing stuff. It has no memory leaks and runs flawlessly. It didn't even require much effort to get it to run this stabily - only found 1 bug since I started doing this.

      Also, if WinXP is going pear-shaped on you, sounds like an OS problem. Why are you blaming it on Java? If you have some long running apps that are causing problems, you can re-start them. Saying you have to re-start the OS sounds rather suspicious.

    13. Re:Stability/memory leaks by Anonymous Coward · · Score: 0

      That's because people have substituted good programming for an easy language.

      A lot of people think that if a language is easier to program in, it'll take care of everything.

      This happened with VB too.

      There is NO substitute for good programming, and Java CAN'T force you to think.

      No language can do that.

      Time to put this toy down and get serious, only I suppose it's worth keeping Java alive just to keep C# in check.

      MODS, feel free to mod me down instead of thinking. After all, if you disagree with me, that must mean you should mod me down, right?

    14. Re:Stability/memory leaks by smallpaul · · Score: 3, Informative

      Yes, Java's GC would notice that nothing is referring to them and remove the objects. This unlike a simple reference counting gc such as python's which would not notice this.

      Your information about Python is about four years out of date.

    15. Re:Stability/memory leaks by angel'o'sphere · · Score: 4, Insightful

      Java's garbage collection sort of creates a general laziness among some coders who don't clean up because they don't have to.

      This is a missconception of yours. In Java, you CAN'T clean up. In C++ you say
      delete x; x = null;
      , in Java you just say
      x = null;
      Probably I should correct my sentence above: freeing memory IS CLEANING UP, nothing else, so all Java programmers clean up automatically.


      All it takes is one pointer *ahem* reference to some object that contanis a reference to another, that contains an array... If you've got a few hashes and arrays in the way, it may be difficult to tell exactly where memory is being used, thus memory leaks.

      Well, for a GC that is not difficult to tell at all. Not harder as for a human :D
      In C++ somewhere somehow one had called delete. So at the point where in Java a hughe amount of memeory is referenced, and probably never used again, you have a dangling pointer in C++.

      but would what happen if two objects referenced each other but nothing else referenced them. Would gc know to follow the links between the two and see that nothing in the main app is using them?

      Of course, thats the point about garbage collection :-D

      If you have a memory leak in java then it comes from things like that:
      ArrayList vector = new ArrayList();
      while (someObscureEndlessLoopCondition) {

      vector.add(new SomeObject());

      }
      If you do somewhere something like this you will run into an OutOfMemoryException sooner or later .... but that problem is the same in all languages.

      It is really no difference if one "forgetts" a delete in C++ somewhere or one forgets a x = null; in Java somewhere, but the Java program won't crash indeterministic, thats a difference.

      angel'o'sphere
      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    16. Re:Stability/memory leaks by erlorad · · Score: 1

      Memory leaks in Java are almost as common as in other languages. The only difference is that in java they appear only when you have a live reference on something that should not be refenced anymore, so gc can't kill it.

    17. Re:Stability/memory leaks by SlowMovingTarget · · Score: 1

      Not so much, no. Memory leaks are usually caused by "leak idioms." Essentially, these are mistakes the developer makes while interpreting the design. UML is useful (and I'm an MDA guy--have a look at my blog), but it isn't enough to prevent a coder from stuffing objects in static collection variables and forgetting about them.

      Unit tests together with code profilers are far more effective at revealing this sort of problem. Also, having an experienced programmer review the code can help tremendously.

    18. Re:Stability/memory leaks by B5_geek · · Score: 1

      Truth be told, I have had a 50/50 sucess rate with just killing the app. (azureus) After running for 3 days it's using almost 1Gb of ram. But like I mentioned killing the JavaVM works about 50% of the time.

      I don't doubt that my OS needs to be nuked & re-installed. I will get around to that when I have enough time to backup my data and install linny instead.

      --
      "The price good men pay for indifference to public affairs is to be ruled by evil men." ~Plato (427-347 BC)
    19. Re:Stability/memory leaks by mgrennan · · Score: 1
      Actually yes. Java is the COBOL of the new century. Companies are converting almost everything into Java. They hire new unexperenced programmers full of "know better" and have old managers who think objects are things sitting on their desk.


      I'm a systems / internet admin for top 100 company and I've heard "Java can't have memory leeks". The JVM has been known to leek and Java is a language. It is defined by the code your wight. When zit faced programmers get lost in their own objects and forget to close a parameter file or serialize objects that never get passed on you have a leak. Call it code and not Java if you want. The system is one its way down.


      OH, and "add more ram" is allways what the programs way too.

      --
      There are 10 type of people in the world, those who understand binary and those who don't.
    20. Re:Stability/memory leaks by Achoi77 · · Score: 1
      Not memory leaks as such, but "memory leaks" for all practical purposes. How? Well, if you forget to nullify references to objects you no longer use, the garbage collector obviously cannot reclaim that memory..

      Hrm, if this is a problem that hurts performance then I would have to attribute it to either:

      1: Poor preplanning/coding or

      2: Not enough ram

      I would have to side with the first choice. Besides, this kind of problem can be seen in almost every programming language, not just java.

    21. Re:Stability/memory leaks by NoOneInParticular · · Score: 0

      Ah, you're referring to the python GC extension in which you can do some cyclic checks by subclassing from a gc object at the expense of a special GC flag that is added to the normal overhead of your classes? I love python, but this is an add-on to the normal reference counting mechanism and not a built-in. The python 'solution' slows down the code instead of increasing its speed (full GC is oddly enough faster than reference counting, especially for copying), and is just there to allow you to make cyclic references without shooting yourself in the foot too easily.

    22. Re:Stability/memory leaks by Jonboy+X · · Score: 1

      Specifically, an object is marked for gc-ing when it's not reachable from any thread.

      Just so ya know.

      --

      "In a 32-bit world, you're a 2-bit user. You've got your own newsgroup, alt.total.loser." -Weird Al
    23. Re:Stability/memory leaks by Anonymous Coward · · Score: 0

      True, there are Java apps that leak. I don't have much experience with Swing but I got a leak once displaying live video. Memory footprint of JBuilder 4 (JDK 1.3 with lots of Swing) grows, the whole app becomes slow for me after several days of extensive use.

      However, Java really allows writing code without thinking about memory managemnt most of the time. You obviously got to be careful when hashing data and if using native calls. As always, you got to test your products (there are nice Java profilers that can be help). I set aside a system and run non-stop stress tests on it for days and weeks. This gives me confidence that the product is stable and leak-free (I like to brag that the only thing that could kill it so far was the August 2003 blackout). It looks like that kind of testing is is often missing for many products so you end up with leaky stuff.

    24. Re:Stability/memory leaks by jyoull · · Score: 1

      You call this a *leak* ?

      I don't see how that's an appropriate description of the issue. You've got allocated memory that's not being used. This is hardly the same as the classic C-language memory leak, where memory is in use and the OS or containing application are not entirely in agreement about it... such that the memory perhaps can't even be reclaimed or deallocated, pointers running past the ends of arrays, that sort of thing. Now THAT is what I'd call a "leak"

      Allocating a big thing and forgetting you have it, that's just inefficient use of resources. But in the stated example, you are NOT finished using that memory, you just haven't released it yet.

      Google thinks this is a well-liked definition of "memory leak":

      I suppose we can quibble about whether it supports or refutes my position, but "leak" seems to imply some failure of structure that prevents reclamation.

    25. Re:Stability/memory leaks by Robb · · Score: 1

      Automatic memory management is based on some kind of reachability analysis. In contrast the intuitive idea behind a memory leak is when program accumulates memory that it no longer uses. Some kinds of memory leaks that occur in languages like C++ do not occur in Java but no language can really save a programmer from himself and eliminate all memory leaks.

    26. Re:Stability/memory leaks by Anonymous Coward · · Score: 0

      Java should never have memory leaks... All the memory managment should be done by the VM as far as I know... unless there is some advanced stuff i'm just not aware of?
      Not memory leaks as such, but "memory leaks" for all practical purposes. How? Well, if you forget to nullify references to objects you no longer use, the garbage collector obviously cannot reclaim that memory..
      A memory leak is a piece of memory that is not accesible to the program or to the garbage collector (tm).
      A dangling reference is when a single piece of memory is used by two objects as if it were their own, because some object called delete on another, but there was a reference somewhere to the deallocated object. This can't happen in Java, but it can happen still in C++ and C# (for unmanaged code).
      A buffer overflow occurs when an array is accessed using an index out of range and no AraayIndexOutOfRangeException is thrown. Again: This can't happen in Java, but it can happen still in C++ and C# (for unmanaged code).
      An unused memory reference by class invariant leak is memory that can be accessed by the program, but the class invariant does not permit to access it. For example you implement an stack in an array and forget to null out elements when popping the stack.

    27. Re:Stability/memory leaks by MemoryDragon · · Score: 1

      Well, I think you brought the whole issue to the point. Java is very easy to learn, but to program a serious system with it is, well lets say it that way, you even could use Logo and it would be hard.

      People who can build enterprise size applications dont fall from the trees or you can hire a dime by the dozend, that is my experience, being almost 8 years into the field now.

      The other thing is memory leaks. The VM in its current incarnations has none that I know of (and my systems seem to proof that by running months, til years without reboot or VM crash) But just because you have a GC saying that memory leaks are impossible is a myth. In the end you have to program carefully not to get them.

      Rule #1 program wisely and wherever you are not sure that an object is referenced more than once and should be disposed use weak references extensively.

      Rule #2 Learn patterns for heavens sake, learn OO design issue, learn about OO, AOP, Protocols and other stuff generally and keep your knowledge up to date and have a look at others code as often as possible. Also have a basic knowledge about the most important performance aspects of such systems so that you can avoid the usual mistakes which result in lousy performing servers.

      If you apply those two rules you can make big stable systems. The problem is, that many companies hire people who jumped onto the train by a I learned java course and then wonder why their multi million thing goes haiwire gets memory leaks or acts weirdly once it reaches a certain loc threshold.

      Btw. another word to memory leaks in VM based languages. Better be prepared to face one once in a while, and better be prepared that finding this leak is one hell of a task, due to the nature of those languages, which start Garbage collectors occasionally. If you are lucky you have a good profiler and dig into the object reference counts and memory usage patterns at various code positions at different times if you are unlucky, then you can hope that you already have enough experience in the underlying vm behavior and lanugage that you basically can get a clue where the problem is by debugging and reading the code.

    28. Re:Stability/memory leaks by Brian+Quinlan · · Score: 3, Informative

      Yes, Java's GC would notice that nothing is referring to them and remove the objects. This unlike a simple reference counting gc such as python's which would not notice this. Java's GC can even relocate memory on the fly to minimize page misses and avoid memory fragmentation.

      Python actually uses a generational garbage collection system that can break cycles to reclaim unused objects. It also performs certain optimizations to avoid unnecessary memory allocations and deallocations.

      In Python, reference counting is a combination of a historical artifact and a performance optimization.

    29. Re:Stability/memory leaks by Anonymous Coward · · Score: 0

      In other words, if you write code that allocates a lot of memory and you hang on to it with all your life even though you don't need it anymore, you blame the language for not predicting the future and freeing it anyway.

    30. Re:Stability/memory leaks by Lusa · · Score: 1

      You do not normally need to explicitly null anything in Java. The GC will work out what is and isn't referenced. At one point (Java 1.0/1.1?) it probably did help the GC but now its a myth. The only place where nulling would be required is with statics.

      Not sure what you mean by crashing in a indeterministic manner. I'm fairly sure C++ allows for core files, at least on unix. In either case you still won't know where the memory is being lost since an out of memory exception in java is not normally thrown from where the problem is.

    31. Re:Stability/memory leaks by Bert690 · · Score: 1
      Java should never have memory leaks...

      Yes it should not ever leak memory (ignoring the issue of shoddy applications failing to clean up references to unused objects), but it does. Here's an example. Run this program under Linux, using any 1.4.* Java runtime. It grows and grows!

      for (;;) { java.net.NetworkInterface.getNetworkInterfaces(); }

      Sun's second-rate programmers have caused enormous problems for Java and its image. It would be much better off in other hands (ideally the open source community).

    32. Re:Stability/memory leaks by Anonymous Coward · · Score: 0

      If it works anything like the C# GC then there is no issue. The GC tracks root references (references directly to a variable). Even if you create a circular reference between two objects and the variables containing said objects go out of scope the root references no longer exist and the two class instances are marked for collection.

      Not having to clean up, or concern yourself with memory management, is the very point of RAD languages like Java and C#. The GC system also uses methods to keep memory allocated and defragmented in order to enhance performance as memory allocation and deallocation is an expensive task. Too much malloc/new and free/delete will slow your app down.

    33. Re:Stability/memory leaks by Dewin+Cymraeg · · Score: 2
      Not memory leaks as such, but "memory leaks" for all practical purposes. How? Well, if you forget to nullify references to objects you no longer use, the garbage collector obviously cannot reclaim that memory..

      Have you guys never heard of scope?!

    34. Re:Stability/memory leaks by fupeg · · Score: 1
      How does such ignorance get modded up? You don't have to understand the many intricacies of the jvm's gc algorithm to understand why this is nonsense:
      would what happen if two objects referenced each other but nothing else referenced them. Would gc know to follow the links between the two and see that nothing in the main app is using them?
      Simple mark and sweep starting at the thread level handles this and any wacky variants of this ( a refs b refs c refs a, etc.) Please try to have SOME clue about what you are talking about before you post...
    35. Re:Stability/memory leaks by Lusa · · Score: 1

      If I may ask, which applications?

    36. Re:Stability/memory leaks by figa · · Score: 4, Interesting
      I ran into a fabulous memory leak just last week thanks to Sun. I wrote a client that was accepting messages and persisting them using ObjectOutputStream. I persisted about 40,000 HashMaps, and next thing, my client was using 200M. I wasn't building any lists of the messages, so I was stumped, and I broke out the profiler.

      I was surprised to find that the ObjectOutputStream has a static HandleTable inside it that creates an entry for each HashMap that I put through, and it keeps a reference to each HashMap. I searched around, and this is a common problem that is not mentioned at all in the javadocs. You're supposed to reset the ObjectOutputStream periodically to free up the HandleTable. I had assumed that reset was like InputStream's reset and never would have guessed that it had to do with Object caching in the stream.

    37. Re:Stability/memory leaks by napir · · Score: 1

      This sort of code can cause major performance problems in real code, so it needs to be termed something, and "memory leak" seems to be an appropriate term to overload.

      And you ARE finished using that memory. "Live" isn't the same as "reachable". GC approximates liveness (whether or not the memory will be used again in the future).

      It is unfortunate that an explicit assign null is required to prevent this though. What can be really fun is if you have a naive optimizing compiler that notices that the assign to null is dead code and takes it out for you.

    38. Re:Stability/memory leaks by Estanislao+Mart�nez · · Score: 1
      All it takes is one pointer *ahem* reference to some object that contanis a reference to another, that contains an array... If you've got a few hashes and arrays in the way, it may be difficult to tell exactly where memory is being used, thus memory leaks.

      This sounds like bad design and implementation skills to me. And by that I don't mean that people should have some sort of super-human capability to keep mental track of what objects are referenced in the environment; rather, I mean that people should think about collection in terms of protocols like stacks, queues, heaps, etc., which enforce discipline on when their elements are accessed, thus implicitly manage the lifespan of collection members.

    39. Re:Stability/memory leaks by pokeyburro · · Score: 0, Offtopic

      Have you guys never heard of scope?!

      This is SlashDot. Mouthwash is irrelevant.

      --
      Lately democracy seems to be based on the skybox, the Happy Meal box, the X-box, and the idiot box.
    40. Re:Stability/memory leaks by Anonymous Coward · · Score: 0

      Have you guys never heard of scope?!

      Have you never heard of a container?!

    41. Re:Stability/memory leaks by Estanislao+Mart�nez · · Score: 1
      in Java you just say x = null;

      IMO if you find yourself saying this, you are probably doing something wrong.

      The trick in a GC'ed language is to manage the lifetime of objects implicitly, by letting references go out of scope. If your x up there is a local variable, you should just return from whichever method you're in. What this means is that people who don't factor their code into simple, short methods that do just one simple thing, tend to keep live references for too long.

      If it's an instance variable (and it better be a private one!), then there's two ways of managing the lifetime of the object in question: either the object that keeps the reference does it explicitly, or, you reduce it to the previous technique, applied to the object that keeps the reference.

    42. Re:Stability/memory leaks by recursiv · · Score: 2

      5 insightful?

      As far as I'm aware, I don't think your entire app is supposed to be in main(). I normally don't ever nullify references, but my code is modular enough, (i.e. not all in main()) that objects go out of scope when they are no longer needed. This is one of the most ridiculous examples of a straw man argument I have seen.

      --
      I used to bulls-eye womp-rats in my pants
    43. Re:Stability/memory leaks by Anonymous Coward · · Score: 1, Insightful
      Ah, you're referring to the python GC extension in which you can do some cyclic checks by subclassing from a gc object at the expense of a special GC flag that is added to the normal overhead of your classes?

      First of all, there's nothing particularly optional about Python GC. It is compiled in by default. I don't even know exactly how to disable it. It's not a configure script flag.

      Secondly, the "special GC flag that is added to the normal overhead of your classes" is just a bit flag (Py_TPFLAGS_HAVE_GC) that is OR-ed into the tp_flags field of a type struct in C. What overhead are you talking about?

      Of course, most people write their Python classes in Python, so they don't need to fiddle with bit flags to benefit from Python's GC. The builtin Python types have this flag enabled, including object, the base type of all new-style classes.

      The grandparent comment has a link to the gc module, which merely allows Python programmmers to set some parameters on the garbage collector. Just out of curiosity, is there any such package/class in Java?

    44. Re:Stability/memory leaks by Anonymous Coward · · Score: 0

      What an appropriate sig for your comment. The simple fact is that Java memory leaks are pretty common simply because not enough planning goes into coding. A proper UML diagram of an application can go a long way to highlighting possible memory leak situations.

      "GreenCrackBaby" is an appropriate handle for what you said. Memory leaks can happen almost anywhere and are an implementation flaw. A UML diagram's not going to help you find them.

    45. Re:Stability/memory leaks by los+furtive · · Score: 1
      We run a java web application that gets restarted only about once a month, and then only because of updates. We also have two java daemons running concurrently, one for generating emails based on table data and another a db to db interface, both of these daemons are running 24/7 and handle millions of records a week, and none of them bloat.

      All this to say it's not Java that's the cause of memory leaks, its lapses in discipline on the developer's side that causes memory leaks...irregardless of the language.

      Hate the player/developer not the game/language.

      --

      I'm a writer, a poet, a genius, I know it. I don't buy software, I grow it.

    46. Re:Stability/memory leaks by Anonymous Coward · · Score: 0

      Here's how mark-and-sweep garbage collectors work: gc crawls down the stack, marking every referenced object on the heap, and every object that those objects reference, recursively. Then gc cleans up any unmarked objects on the heap. It's irrelevant if two objects on the heap reference each other -- if they're not marked, they'll be cleaned up.

    47. Re:Stability/memory leaks by Anonymous Coward · · Score: 0

      The vast majority of memory leaks in Java can be attributed to the 'static' keyword. It should very rarely be used and yet is as overused as the Singleton design pattern. Bad programming and the use of 'static' references often lead to collections of objects that keep growing and never get GCed. Result == memory leak.

    48. Re:Stability/memory leaks by xouumalperxe · · Score: 1

      the general idea is that once there are no more references to an object, and there's need for memory, the object is cleared from memory. So, if the object is refered to somewhere, but is no longer in practical use, it's a "memory leak" of sorts.

    49. Re:Stability/memory leaks by ultranova · · Score: 1

      Probably I should correct my sentence above: freeing memory IS CLEANING UP, nothing else, so all Java programmers clean up automatically.

      In Java, cleaning up means setting references to unused objects to null, so they can be garbage collected. Memory leaks can and will happen, if, for example, the program holds several lists of objects and forgets to remove the unused object from each one of them.

      An endless loop is not needed; just forgetting to remove the object from each place it is referenced in is enough. Not unlike in C, actually...

      x=null;
      is the Java equivalent for
      free(x);
      and forgetting to do it has the same consequences.
      --

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

    50. Re:Stability/memory leaks by B5_geek · · Score: 1

      Azureas (BT client) is the worst offender, there are a few other that I have run that acted in a similar way.

      --
      "The price good men pay for indifference to public affairs is to be ruled by evil men." ~Plato (427-347 BC)
    51. Re:Stability/memory leaks by chez69 · · Score: 1

      not really. you don't have to null an object to for it to get collected

      --
      PHP is the solution of choice for relaying mysql errors to web users.
    52. Re:Stability/memory leaks by NoOneInParticular · · Score: 1

      What overhead are you talking about?

      The limited memory overhead, but actually the additional overhead of having both reference counted semantics and a generational garbage collector running around. Reference counting adds overhead for each copy (through pointer/reference assignment), while generational garbage collection adds overhead for running once in while and examining all memory that is allocated. Python manages to implement both, which leads to the worst of both worlds. This is however unavoidable given python's history. Again, I love python, but speed is not its forte, and the gc has not improved things.

      To satisfy your curiosity: yes as far as I know, Java allows programmatic control of its garbage collector.

      BTW, I've read a bit more about Python's gc since, and indeed, my previous assertion that python's GC was bolted on is wrong, for which I apologize. It's still pretty hideous to have both mechanisms running around, but ok, I was wrong.

    53. Re:Stability/memory leaks by joib · · Score: 1


      5 insightful?


      So? Are you jealous? Seriously, if /. moderation scores are important to you, go see a shrink...


      As far as I'm aware, I don't think your entire app is supposed to be in main().


      No shit, really? I better go reread all my CS books then... *smirk*


      I normally don't ever nullify references, but my code is modular enough, (i.e. not all in main()) that objects go out of scope when they are no longer needed.


      Good idea, I try to do that too. However, there are plenty of situations where nullifying an in-scope object is useful.


      This is one of the most ridiculous examples of a straw man argument I have seen.


      Wrong. The point of a straw man argument is to attack something. What did I attack in my previous post? Oh right, nothing.

      The original question, as I understood it, was that the poster wondered how any kind of memory leak would be possible in Java, given that it has GC. I pointed out that if objects that are not needed anymore are still reachable, then the GC cannot collect them, and that can be considered a memory leak. I fail to see how that statement can be understood as an attack against Java; rather it means that a GC cannot protect against ALL kinds of memory mismanagement, although it takes care of most.

    54. Re:Stability/memory leaks by Anonymous Coward · · Score: 0

      Everyone else replied to this tripe with explanations of why you're wrong. I'm just gonna call you a moron.

    55. Re:Stability/memory leaks by Ba3r · · Score: 1

      Java memory leak is easy. Make a singly linked list (object, with data member 'next' of same type), fill it up, attach the last to the first, and release all of your known references to it! Rinse, run Garbage Collector and repeat!

      Presto, each object in the list references the next, therefore none have a 0 ref count and will be ignored by the garbage collector. Meanwhile, you tossed your only refence to the ring, so you are fux0r3d as well. Keep doing it and you will be screaming for memory in no time!

      However, managed environments like the JVM and .NET make it safe (usually) for coders to not release programs the nuke somebody's system (even good coders make BIG mistakes), and thats why they are good. I mean, I laugh when i hear home taught DOS hackers lament the days they could access the hardware directly (and shudder when i imagine them getting their grubby paws into asynchronous windows systems)

    56. Re:Stability/memory leaks by Tojo-Mojo · · Score: 1

      Ah yes, nothing says efficiency like periodically examining every single object held in memory (well, every single non-garbage collectable). Silly me.
      Sure, maybe it only happens when you run out of memory, and of course up until the point sweep is run you are using more memory than you ought to be, so generally resoruces are being wasted all around, but hey it's cool computers are faster now or something.

    57. Re:Stability/memory leaks by Tojo-Mojo · · Score: 1

      Never said it was good design, but this sort of problem is big in some of the software I test. One of the problems with having GC is that you don't specifically assign a place where an object, maybe a hash, is done with, so you have to carefully make sure that every object that references it stops referencing it when it is sure it won't need it anymore.
      But such problems are hard to catch. In non-gc, you'd free it, and if you accidentally still had a reference to it somewhere, the program would probably explode and it'd be very obvious that you had this problem. In Java, it is a bit more obscure. In a large team project, a coder might not be aware of the implications of holding on to a particular reference.

      But in the end, good planning and communcation is always the best solution.

    58. Re:Stability/memory leaks by Kombat · · Score: 1

      Java's garbage collection sort of creates a general laziness among some coders who don't clean up because they don't have to.

      I could make the same argument about how "variables" have made coders lazy, because we no longer have to address our own memory. Fact is, computers are much, much better at managing memory than a programmer is. The GC is a natural, welcome evolution.

      Also, I don't know for sure, but would what happen if two objects referenced each other but nothing else referenced them. Would gc know to follow the links between the two and see that nothing in the main app is using them?

      Not to talk down to you, but yes, of course! This is extremely basic, first year translators principles. Translators are highly evolved, very complex and advanced beasts that can easily follow mind-boggling paths of references and quickly reclaim every scrap of unused memory. Don't worry - people have been working on this stuff for decades, and translator theory is an extremely advanced (and interesting) research field unto itself.

      --
      Like woodworking? Build your own picture frames.
    59. Re:Stability/memory leaks by StormReaver · · Score: 3, Insightful

      "...if you forget to nullify references to objects you no longer use, the garbage collector obviously cannot reclaim that memory.."

      That's the whole point of the garbage collector:

      a = new Class1();
      a = new Class2();

      The Class1() object will be picked up by the garbage collector and deleted (assuming the garbage collector is not broken).

      a = new Class1();
      a = null;
      a = new Class2();

      This defeats the purpose of having a garbage collector.

    60. Re:Stability/memory leaks by LadyLucky · · Score: 3, Informative
      Wow, such flameage.

      However, you are quite correct. It can be quite difficult at times to ensure that all objects are correctly cleaned up after usage. As soon as you introduce items such as HashMaps, etc, you run into potential for these problems.

      We once had this issue when we embedded the mozilla javascript interpreter in our app. The problem was that you have to create a scope object, with all sorts of predefined classes and functions and so forth. This was expensive, so we pooled them. Unfortunately this left a memory leak, as objects declared in scope by the javascript itself would not tidy up at the end of processing.

      Indeed it turns out the library has parent scopes, so we could create a new child scope cheaply each time, but the point remains.

      --
      dominionrd.blogspot.com - Restaurants on
    61. Re:Stability/memory leaks by joib · · Score: 2, Insightful

      a = new Class1();
      a = new Class2();

      The Class1() object will be picked up by the garbage collector and deleted (assuming the garbage collector is not broken).


      Oh good grief. Isn't that blindingly obvious? Apparently not...

      Perhaps I should have clarified my original comment by saying something like "nullifying references to reachable objects you no longer use", considering that my comment got, uh, about 10 responses which all totally missed the point. *sigh*

      Yes, in most cases nullifying references is not needed since the application is usually designed so that objects go out of scope when they're no longer used. However, in certain circumstances that approach might not be enough.

      Consider a situation like, say:
      a = new SomeHugeClass(); // some very big object
      b = a.doSomething();
      a = null;
      if (doSomethingElse(b)) {
      a = new SomeHugeClass("foo");
      } else {
      a = new SomeHugeClass("bar");
      }
      Now, if doSomethingElse() takes a long time to finish (say, doing i/o or a heavy calculation etc.), or requires lots of memory, it might not be a bad idea to first nullify a, as in the example above.
    62. Re:Stability/memory leaks by fupeg · · Score: 2, Interesting

      The whole point was not "how does Java solve this super tough problem". The point was that it's not a hard problem and that anybody who knew anything about how garbage collection works would not make such a comment. Of course Slashdot is all about not knowing anything about a subject but making claims about it anyways. Mark and sweep is not the actual algorithm used by JVMs, it is just a simple algorithm that any programmer (and I use that term loosely) should know about from a data structures course. There are actually numerous gc algorithms used by JVMs, in fact you can specify different types of algorithms for the JVM to use based on the type of application and the type of hardware running the application. But do yourself a favor and try to learn the basics first.

    63. Re:Stability/memory leaks by Tojo-Mojo · · Score: 1

      Ok, I hereby withdraw my statement where I claimed to know absolutely everything about garbage collection. It is a weird statement, you know, considering how I ended it with a question mark. Usually we call those questions. But then again the internet is all about not reading but insulting someone for asking a question you consider stupid.

      Someone asked a question, I answered it and asked another. If anyone who knows anyone about garbage collection wouldn't ask a stupid question like mine, what do you say to the parent's question? He must be some grade A idiot.

      I don't know a lot about garbage collection. I don't care about garbage collection, because I know it will never be as efficient as well-managed memory.

    64. Re:Stability/memory leaks by Pinky · · Score: 1

      This has to stop. Guys, you don't have to set all references to null. Setting references to null is only needed in one special case (see links below) and even then the reasone for it should be obvious (you're retaining a reference). Garbage collectors can determin which objects are reachable. You don't need to tell them.

      Explicit Nulling:

      http://www-106.ibm.com/developerworks/java/libra ry /j-jtp01274.html
      http://java.sun.com/developer/Te chTips/1997/tt0903 .html

    65. Re:Stability/memory leaks by kaffiene · · Score: 1

      5, insightful for a lie?

      You *DO NOT* have to set anything to null to get it gc'd and in fact you can make your code run slower by doing so.

      I know that slashbots hate java, but marking out and out lies as insightful is going a bit far with the FUD.

    66. Re:Stability/memory leaks by Old+Wolf · · Score: 1

      This is a missconception of yours. In Java, you CAN'T clean up. In C++ you say
      delete x; x = null;
      , in Java you just say
      x = null;

      Correction.. in modern C++ you say

      (that is, nothing). Good C++ coding involves the RAII idiom, which means that you arrange things in such a way that resources are automatically released when they go out of scope. You almost never have to use 'delete' in C++; code that does use it can be re-factored to use RAII (eg. automatic storage or smart pointers).
      C++ programs sprinkled with memory-management code are a sure sign of a bad port from C or Java. Java ports stick out like a sore thumb: they 'new' everything under the sun.

    67. Re:Stability/memory leaks by gdchinacat · · Score: 1

      I have tried this on linux:
      Linux hostname 2.6.8-1-686-smp #1 SMP Mon Sep 13 23:02:39 EDT 2004 i686 GNU/Linux

      using java:
      java version "1.4.2_04"
      Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
      Java HotSpot(TM) Client VM (build 1.4.2_04-b05, mixed mode)

      I never receive OutOfMemoryError exceptions, and jvmstat (http://developers.sun.com/dev/coolstuff/jvmstat/) shows that the VM is collecting as it should (heap never grows, eden fills up, is collected, repeat).

      How exactly are you determining that "It grows and grows!"?

    68. Re:Stability/memory leaks by recursiv · · Score: 1

      You are correct. I interpreted your comment as an attack against java which was my mistake, which I made due in part to divisive attitudes about java.

      --
      I used to bulls-eye womp-rats in my pants
    69. Re:Stability/memory leaks by radishfarmer · · Score: 1

      So how exactly is ObjectOutputStream supposed to do instance matching in an object graph without keeping track of the objects it has already written?

      You could try to just cache the pointer values, instead of the objects, but that would fail if the GC ran, and the VM re-used those addresses. Very bad. So you need to pin those addresses.

    70. Re:Stability/memory leaks by Estanislao+Mart�nez · · Score: 1
      I don't care about garbage collection, because I know it will never be as efficient as well-managed memory.

      What you claim to know right there is demonstrably false. It all depends on object allocation patterns, but it's easy to see that for some such patterns, stop-and-copy garbage collection is faster than manual memory management. With manual memory management, for every object you create, you must do an expensive memory allocation and a deallocation, also expensive. With stop-and-copy GC, you must allocate each object (expensive), copy it at GC time if it's live (cheap), but deallocation comes for free.

      The fact is that this is a memory/speed tradeoff. Stop-and-copy is faster in general, but needs more memory (twice as much in the worst-case scenario); manual allocation is slower, but doesn't need as much memory.

    71. Re:Stability/memory leaks by Estanislao+Mart�nez · · Score: 1
      Ah yes, nothing says efficiency like periodically examining every single object held in memory (well, every single non-garbage collectable).

      You should stop and actually analyze the cost of doing this. Examining an object takes a constant amount of time, so the total cost of a GC cycle is distributed over the number of objects that are allocated. That is, you're only incurring a small constant cost per each object for the mark & sweep cycle, plus whatever your malloc() and free() operations cost.

      Sure, manual memory allocation doesn't incur this extra cost, and thus is faster than mark & sweep; but the dominant cost in both cases is that of malloc'ing and freeing objects (maintaining free lists, and in general, dealing with memory fragmentation). Stop-and-copy GC avoids this cost, but at the expense of using more memory than manual allocation or mark & sweep.

      Sure, maybe it only happens when you run out of memory,

      That's not necessary at all. The mark & sweep algorithm needs to visit every object created during the lifetime of the program, spending a constant amount of time on each to determine liveness. This can be done in a small number of infrequent cycles over a large number of objects, or it can be done over a large number of frequent cycles over smaller sets of objects. The former minimizes the constant overhead incurred by each cycle, and the latter minimizes the amount of garbage in memory at any time; the question is how to strike a good balance.

    72. Re:Stability/memory leaks by newhoggy · · Score: 1
      It is really no difference if one "forgets" a delete in C++ somewhere or one forgets a x = null; in Java somewhere, but the Java program won't crash indeterministic, thats a difference.

      It's precisely this problem in C++ that lead to the development of programming styles such as RAII (Resource Acquisition Is Initialisation). RAII when used religiously helps eliminate accidental or forgotten deletes.

      Too bad though if you're given the task of debugging code written by someone not familiar with this concept.

    73. Re:Stability/memory leaks by Estanislao+Mart�nez · · Score: 2, Informative
      Presto, each object in the list references the next, therefore none have a 0 ref count and will be ignored by the garbage collector.

      One algorithm to do GC is to go through every reference in your call stack, follow each of them, mark the object you reach as used, do the same for each reference in those objects, and so on (taking care to check for already-marked objects, so as not to fall into cycles). Then, you go through all the heap, and free all the objects you didn't mark.

      This algorithm will successfully collect the circular list. I don't think Java uses this one algorithm, but the algorithms it does use will collect the cyclic structures just as well.

    74. Re:Stability/memory leaks by RedWizzard · · Score: 1
      Ok, I hereby withdraw my statement where I claimed to know absolutely everything about garbage collection. It is a weird statement, you know, considering how I ended it with a question mark. Usually we call those questions. But then again the internet is all about not reading but insulting someone for asking a question you consider stupid.

      Someone asked a question, I answered it and asked another. If anyone who knows anyone about garbage collection wouldn't ask a stupid question like mine, what do you say to the parent's question? He must be some grade A idiot.

      You made a blanket statement about how crap GC is, and then revealed, via your question, that you don't know the first thing about GC. As you clearly have absolutely no understanding of GC at all your opinion is worthless. Thus the reaction you've got. You probably would have got a few troll moderations if wasn't so obvious that you're just ignorant and not actually being malicious with the crap you're spouting.
    75. Re:Stability/memory leaks by joib · · Score: 1


      Setting references to null is only needed in one special case (see links below) and even then the reasone for it should be obvious (you're retaining a reference).


      Precisely the point I was trying to make. Evidently I didn't say it clearly enough since my comment got 10 responses flaming me for I something I didn't mean.


      Garbage collectors can determin which objects are reachable. You don't need to tell them.


      Well duh, that's the entire point of garbage collectors, now isn't it. ;-)


      http://www-106.ibm.com/developerworks/java/libra ry /j-jtp01274.html
      http://java.sun.com/developer/Te chTips/1997/tt0903 .html


      Thanks. Those articles explain precisely what I had in mind.

    76. Re:Stability/memory leaks by joib · · Score: 1


      5, insightful for a lie?

      You *DO NOT* have to set anything to null to get it gc'd and in fact you can make your code run slower by doing so.

      I know that slashbots hate java, but marking out and out lies as insightful is going a bit far with the FUD.


      You could of course have checked my responses to the other comments, where I clarify my point so as to avoid any misunderstanding, instead of writing or own little "me too" flame. Oh well, can't expect too much from the "slashbots", now can we?

    77. Re:Stability/memory leaks by angel'o'sphere · · Score: 1

      I don't want to pick on you: but isn't that pretty clear?
      Suppose Java did not have the class ObjectOutputStream. You still liked to serialize objects, so would write your own figa.ObjectOutputStream class. Now you have a simple problem: you like to be able to serialize and deserialize big object graphs. As you did. So e.g. you have the problem that an object might be twice in different hash tables. What to do? Serialize that object twice, and having two copies when you deserialize it?
      Or serializing it only once and remembering in your ObjectOutputStream class that you have it serilaized allready and writing a "reference" to the first copy to the stream?

      The problem with Java is: it made a hell lot of problems easy solveable for novice coders. However it hided also a lot of stuff behind the scene.

      In your case obviously the documentation was missleading or wrong as well.

      BTW: persisting messages with standard serialization might get you into trouble when you upgrade to a newer VM and like to deserialize it. Object serialization is not fixed or a standard. Better consider "Externalization" via the Externelizeable interface.

      angel'o'sphere

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    78. Re:Stability/memory leaks by ultranova · · Score: 1

      not really. you don't have to null an object to for it to get collected

      Um, yes you do. If there's still references to an object, it can't be collected. Or did you mean that references from other objects ready to be collected are not counted ?

      In any case, if I have forgotten to remove the otherwise unused object from some list my program maintains, it won't get garpage collected (unless I was smart and used weak references). So it's perfectly possible to get memory leaks in Java; it's just harder than in C.

      --

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

    79. Re:Stability/memory leaks by Tojo-Mojo · · Score: 1

      I am not talking about GC, I am talking about GC implementations. At a very high level, it all looks pretty, but in the real world somewhere a malloc is still called, somewhere a free is still called.

      I don't think there's any rule that says C programs must always follow
      x=(foo*)malloc(sizeof(foo))
      free(x);
      Res tricting C to that is like restricting GC to straight reference counting. You could manage your own buffers, and with knowledge of when and where they'll be used that would be unavailable to a gc, you can know exactly when to free them and exactly how large they need to be.

      It is nice to look at the run-time cost of GC, and it usually looks pretty good on paper. But there is the cost of the GC itself, and the fact that in order to so analyze a program it has to be interpreted in a VM on current hardware. If GC were implemented at the hardware level (you know, dropping the V out of VM), then it definately has the capability to be faster than manual management. Inside the context of a virtual machine, it can be faster. But the computers of today (Which, there's a very good chance, will be the computers of tomorrow and for a number of years after that as well) don't understand it.

      In the end you, the VM, the GC, are just passing instructions to a CPU that doesn't know a fooObj* from a barObj*, and if you look at it as just a stream of instructions, it's difficult to imagine that someone else can send instructions you can't.

    80. Re:Stability/memory leaks by rjshields · · Score: 1

      The official line goes something like:

      An object becomes eligible for garbage collection when it is no longter reachable by any code.

      So setting object references to null is not necessary, as objects will become eligible for garbage collection as references to them disappear off the stack (as long as they are not reachable by any other code).

      --
      In this world nothing is certain but death, taxes and flawed car analogies.
    81. Re:Stability/memory leaks by Bert690 · · Score: 1
      I never receive OutOfMemoryError exceptions, and jvmstat (http://developers.sun.com/dev/coolstuff/jvmstat/) shows that the VM is collecting as it should (heap never grows, eden fills up, is collected, repeat).



      It's not the heap leaking so it won't cause java out of memory, nor will it be detectable with a heap analysis tool. It's an internal JRE leak. Take a look at the RSS reported by "top" or "ps". It DOES grow consistently and will exceed the available memory if you let it run long enough. I'm using Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_03-b02) and the 2.6.8-1.521smp kernel. Yes, I just tried it.
      Maybe fixed in _04 but I doubt it.

    82. Re:Stability/memory leaks by Estanislao+Mart�nez · · Score: 1
      I am not talking about GC, I am talking about GC implementations. At a very high level, it all looks pretty, but in the real world somewhere a malloc is still called, somewhere a free is still called.

      Nope. That's where copying collectors win-- no calls to malloc and free.

    83. Re:Stability/memory leaks by gdchinacat · · Score: 1

      no, not fixed.....I finally DID get an OutOfMemoryError, with a fairly detailed message (compared to normal ones) and the VM exited. I tried it again with a counter on it, and it usually happens about 600,000 iterations into it....oh well. Not like its going to matter when I try to have a server app that runs for years on end :)

      My favorite VM/class library shortcoming is the lack of a way to unmap mapped files. Relying on the GC works just fine, unless you are doing all of your processing using the mapped files, and don't ever put anything on the heap. Finally had to resort to using reflection, setAccessible(true), etc to manually unmap the files. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id =4724038

    84. Re:Stability/memory leaks by angel'o'sphere · · Score: 1
      Man ... 6 replies all telling teh same thing.
      Sure, on stack I have not to say
      x = null;
      But what is with an attribute in an object?
      class Person {
      Adress postalAdress;
      ...

      }

      Person angelo = new Person();
      angelo.postalAdress = null;
      You love that more?

      What should I do to indicate that I have no adress anylonger? I can not call delete and I can not tell GC, hey come on, GC, please remove my address. IK set my adress to null, and the GC eventually will collect the adress object.

      angel'o'sphere
      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    85. Re:Stability/memory leaks by angel'o'sphere · · Score: 1


      Um, yes you do. If there's still references to an object, it can't be collected. Or did you mean that references from other objects ready to be collected are not counted ?

      Yes, references from other objects, ready to be collected ARE NOT counted! Otherwise GC would not work.
      So you have NOT to null ALL references, only tose which determine the livetime.
      Its not harder to get leaks in Java than in C, its equal easy.
      GCed languages do not solve the "when to release memory" problem, they resolve the dangling poiner problem, and release memory as sideeffect nearly as good as a hand crafted strategy.
      But its far more rebust against code changes than hand crafted code is.
      Imagine you have super fast custom new/delete operators. And then you realize you can optimze your code by introducing a cash somewhere. new/delete suddenly has to be changed to know about the cash as well, to remove cash entries when adelete is called, e.g.
      In Java you do not really care. Where ion the code suddenly objects get refeenced, in cahs or where ever, is transparent to the GC.
      angel'o'sphere

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    86. Re:Stability/memory leaks by angel'o'sphere · · Score: 1

      RAII is not allways possible.
      Often yo have distict objects which finally get associated to each other.
      You delete them from the outside, and only after you have disassociated them again.
      Imagine a CASE system where you have two packages and one class. Now you drag/drop the class from its containing package to the other package. That means you remove he "containes" associaton from one package to the class and establich a new one.
      If you "delete" the class, the package has a dangling pointer to it. So, what is your design descission? Having a destroctor in the package, which deletes all classes the package references, when the package is deleted? So why? The package did not aquire the resources we called "class" above. The classes where likely aquired by a user action in the outside, and then placed into packages. So, the user action code has to release all resopurces it has aquired? Also the classes which later got placed into packages?
      While you are right that using such an idiom helps, its no panacea.

      angel'o'sphere

      P.S. I coded over 10 yeas in C++ and I'm a well known expert in that language (nearly 800,000 lines of code, over 2500 classes), the only thing I miss in Java are templates, because generics suck.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    87. Re:Stability/memory leaks by Anonymous Coward · · Score: 0

      C#, and I would assume Java, can actually collect an object after it's no longer referred to in the method.

      For example C# can collect in this case:

      Foo f = new Foo();
      f.DoSomething(); // In foo
      void DoSomething()
      {
      while(true)
      {
      SomeStaticClass.SomethingElse();
      }
      }

      In this case once you enter DoSomething there are no longer any outstanding references to f. The method that called no longer refers to it (because it's done with the method call), and the DoSomething method never refers to "this", so it's not referred to there either.

      The CLR will consider this object to be eligble for collection. I don't see why Java wouldn't be able to do this.

    88. Re:Stability/memory leaks by Estanislao+Mart�nez · · Score: 1
      What should I do to indicate that I have no adress anylonger? I can not call delete and I can not tell GC, hey come on, GC, please remove my address. IK set my adress to null, and the GC eventually will collect the adress object.

      First of all, your class should store the address in a private instance variable, and external access to its values should be through getter and setter methods. It's in general a bad idea to allow the state of a class to be modified by code not in that class.

      Second, there is a difference of meaning between setting a field to null because you're using null to mean "no value", and setting it to null because you are trying to cause a garbage collection. The logic to your code there should be "I'm setting this person's address to null because they don't have an address anymore", not "I'm setting the field to null because I want this obejct to be GC'ed."

      Third, I think that's an abuse of null anyway. You want to something more abstract, e.g., have a constant Address.NO_ADDRESS assigned to a specially designated instance of the class, that's used to signal the condition where a person has no address. Why? Because you can catch more bugs this way. If you have code elsewhere that does person.getPostalAddress().foo(), and person has a null postalAddress, you're going to get a NullPointerException; if you've assigned a designated instance of Address, then you can control what code gets called.

      In general, the problem with null is that when a field is set to null, it can be either because nobody ever set it, or because somebody explicitly set it to null, and it's pretty hard for a program to distinguish these cases.

    89. Re:Stability/memory leaks by Gopal.V · · Score: 1

      > but would what happen if two objects referenced each other but nothing else referenced them. Would gc know to follow the links between the two and see that nothing in the main app is using them?

      The main app is all the object traceable from the root set. Read this for a quick view. Essentially the rootset is part of a graph of objects and the rest can be free'd .

    90. Re:Stability/memory leaks by angel'o'sphere · · Score: 1

      oh man ....

      This is /.

      Do you think I spend my time to use [ecode] tags to make a full fledged example of java code?

      And yes, of course I use a special NULL-Object if I think it fits int the problem.

      The point of the whole thread was about C++ delete and Java ... oops what to do there? Yes, x = null;

      People claimed C++ was clearer, and I claim GC is to be prefered, because x = null; is what I want in that local context. I don't know, and I don't need to bother if that particular place is the last reference and a delete would be appropriated.

      In general, the problem with null is that when a field is set to null, it can be either because nobody ever set it, or because somebody explicitly set it to null, and it's pretty hard for a program to distinguish these cases.

      Thats why some languages distinguish between NULL, non-initialized and FAIL (exception during initialization). E.G: ICON is such a language.
      angel'o'sphere

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    91. Re:Stability/memory leaks by Old+Wolf · · Score: 1

      RAII is not always possible

      Usually yes, but not always, no.

      It's hard to discuss such abstract situations, but in the case you describe my first thought would be that the 'package' would delete any 'classes' it 'owns' when the package is destroyed, and it would also have a function to 'disown' a package (returning the pointer to the calling code, which could then assign it elsewhere or manually delete it etc.) So you would 'new' the object, but in normal circumstances, would not have to 'delete' it.

    92. Re:Stability/memory leaks by figa · · Score: 1

      It wasn't clear to me at all. I'm not serializing or deserializing big object graphs, so the problem of multiple references in graphs didn't occur to me. I appreciate your explanation of the problem, and if it was stated this clearly anywhere in the javadocs, it would have saved me a lot of time with the profiler.

  17. Release notes by BlurredOne · · Score: 5, Informative

    If any one is interested in reading the release notes, they can be found at http://java.sun.com/j2se/1.5.0/docs/relnotes/featu res.html

  18. Stealing my tongue by mukund · · Score: 4, Funny

    I, for one, welcome our new virtual machine overlord.

    Dude you know you are not supposed to say these things in the story itself.

    --
    Banu
    1. Re:Stealing my tongue by Anonymous Coward · · Score: 0, Funny

      Actually, I think the story submission page should have: [ ] Imagine a Beowulf cluster of these! [ ] In Soviet Russia, [______________] you! [x] I for one welcome our new [______________] overlords [x] Automatic insert of AC fp It would save so much time, and prevent redundancy.

    2. Re:Stealing my tongue by maxwell+demon · · Score: 1

      At least it would help against "First Post" - unless an AC is stupid enough to do so even if there are already posts.

      --
      The Tao of math: The numbers you can count are not the real numbers.
    3. Re:Stealing my tongue by Anonymous Coward · · Score: 0

      In Soviet Russia, our new overlord welcomes you.

  19. Nice language... bad interface by smari · · Score: 1, Interesting

    I personally have never liked Java, but it's hard to dislike... it's a nice syntax, and makes for nice clean code.

    What bugs me about Java is the virtual machine. Native code please! The "compile once, run anywhere" idea is good enough, but Perl is definately a much better candidate for such things, wheras it is open source and therefore portable to _anywhere_ without the folks at Sun having to give their approval.

    1. Re:Nice language... bad interface by shutdown+-p+now · · Score: 1

      You do realise that it is compiled to machine code by the JIT compiler when it is run?

    2. Re:Nice language... bad interface by smari · · Score: 2, Insightful

      No.. say I want to port Perl to my ToasterOS. I download Perl, compile it on ToasterOS (Presuming ToasterOS has all the prerequisites), and voila.

      Java is not open source, hence I do not go around compiling it anywhere.. I just wait and hope that Mr. Star gives a yellow light on the project.

    3. Re:Nice language... bad interface by jbrocklin · · Score: 1, Insightful

      Yes! Thank you! I've never liked java all that much - not because the coding is difficult, I just don't like the vm interface to things. I can write something up in perl, and run it wherever I like!

      I don't particularly like the idea of many colleges wanting to move to Java as the language of choice. Sure it hides a lot of things from a new programmer, but if someone is going to college in computer science - they shouldn't have it hidden from them! Not to mention that C++ is somewhat of a 'standard' language. Learn it and you can move to other languages REALLY easily. Just my $0.02....

    4. Re:Nice language... bad interface by Anonymous Coward · · Score: 0

      Yeah, I'd love to see the elegant Perl code for a SOAP middleware service using dsig, just for instance. And I'd really love to see the C++ equivalent deploy to multiple platforms without even rebuilding the project.

    5. Re:Nice language... bad interface by Anonymous Coward · · Score: 0

      Perl/Tk is easier and doesn't have the garbage collection delays of java. Wx-Perl is more flexible, although a bit harder to code for. There's other graphical Perl toolkits as well.

    6. Re:Nice language... bad interface by julesh · · Score: 1

      Open source Java.

      Problem solved?

    7. Re:Nice language... bad interface by Anonymous Coward · · Score: 0

      Perl has quite a few SOAP modules (libraries), each with different purposes and layers of abstration. It would be a doozy to implement something like you're talking about.

    8. Re:Nice language... bad interface by Anonymous Coward · · Score: 0

      Most JVM's today are using just-in-time compilers instead of interpreters. It's essentially the same as compiling c++, but done in very tiny pieces while the program is running.

    9. Re:Nice language... bad interface by Anonymous Coward · · Score: 0

      You don't need "folks at Sun having to give their approval" to write a JVM. You just can't call it "JVM" without Sun's approval.

      Check out Kaffe (http://www.kaffe.org). It is a clean room implementation of the Java Virtual Machine under GPL. They say it has been ported to lots of platforms (http://www.kaffe.org/ports.shtml).

  20. Comment removed by account_deleted · · Score: 2, Informative

    Comment removed based on user account deletion

  21. useful or bloat? by N3wsByt3 · · Score: 4, Interesting

    Well, some may call the 1.5 as being increasingly bloatware, but, why in some aspects this may be true, I think all by all there are considerable improvements over the former releases, especially 1.4.2.

    JVM 1.4.2 (at least some sub-versions) were riddled with bugs, which, for instance, become apparent when people use systems that rely on it in a special way, as with Freenet. It comes as no surprise, that there were numerous reports of some errors on OSX and BSD, as well as on linux, when running JVM 1.4.2. For some time, we had to say "If you experience any difficulties, please try/revert to JVM 1.4.1 or 1.5.x and see if that solves the problem."

    It is crazy to recommend reverting, but the main devls of java were unwilling to remedy the bugs in 1.4.2, claiming it was a Freenet-problem, while our devls said it was a JVM problem. Though it must be said some within freenet claim their is little to no problem with it (probably windows-users, or maybe some sub-versions that worked on specific linux-distributions). Anyway, my advice has always been, and will be (certainly in the light of the stable 1.5 release), to NOT use the 1.4.2, especially when using OSX or another 'nix based OS.

    And also; be sure to get the JRE, and not the full SDK, unless you plan to develop Java software.

    --
    --- "To pee or not to pee, that is the question." ---
    1. Re:useful or bloat? by amorsen · · Score: 1
      Freenet was regularly able to crash the JVM. Sometimes due to bugs in Freenet, but either way, the JVM should never crash. If it does, it is useless as a sandbox. When bugs were reported to Sun, the response was either silence or "produce a small test case showing the problem". Right, I'm going to spend my energy trying to find security bugs in closed-source software. Not.

      Sun has the source to the JVM and the source to Freenet. They are the only people who can fix the problem.

      --
      Finally! A year of moderation! Ready for 2019?
    2. Re:useful or bloat? by cheeser · · Score: 1

      Then I guess I shouldn't have been using 1.4.2 on gentoo to run IDEA all these months. What was I thinking?!?

      --

      --
      http://cheeser.blog-city.com

    3. Re:useful or bloat? by Anonymous Coward · · Score: 0

      Your not an actual software developer are you? I'm talking
      about one that actually sells programs for money? Or
      hell, I'll even extendit to giving stuff away under an OSL.

      The most useless bug report in the world is "it doesn't work".

      Brilliant.

      What is sun supposed to do? Run every crappy application out
      there and debug them too? If you "know" that the problem
      is with the VM them it should be easy to make a small test case
      that reproduces it. If you can't then how can you possibly claim
      you know where the bug is?!

      Geez.

    4. Re:useful or bloat? by amorsen · · Score: 1

      The VM isn't allowed to crash, even on bad programs. Therefore the problem is in the VM.

      --
      Finally! A year of moderation! Ready for 2019?
    5. Re:useful or bloat? by Anonymous Coward · · Score: 0

      AHA thank you, that explains the funny problems I have been having since moving my node from Windows to SUSE, I'll try the new JRE.

    6. Re:useful or bloat? by Bert690 · · Score: 1
      the response was either silence or "produce a small test case showing the problem

      Even when producing a very small test case they do not necessarily acknowledge the problem. I submitted a 2-line test case to demonstrate a bug about a year ago (maybe even longer) and last I checked it has yet to hit the bug parade. If you're interested in seeing the test case, see my other post under this topic regarding memory leaks. It's about as simple as it gets.

      Just another example of how Sun is killing Java.

    7. Re:useful or bloat? by Anonymous Coward · · Score: 0

      well, of course.

      but you were complaining about being asked for a test
      case. how excactly is someone supposed to track down
      a vm crash without one?

    8. Re:useful or bloat? by JamieF · · Score: 1

      > The VM isn't allowed to crash, even on bad programs. Therefore the problem is in the VM.

      Sure, if you want to define "VM" as "VM running on perfect hardware with a perfect OS managed by a perfect admin". Otherwise, you're wrong.

      What if your RAM is defective, or your CPU is overclocked and unreliable, or you have some wacko spyware that mucks around in other processes' memory, or your app uses JNI and your C code is buggy, or your sysadmin installed some runaway process monitor that does kill -9 to procs that use too much CPU for too long, or somebody manually upgraded a library on your machine to a version that the VM isn't compatible with?

      There's a bit of value to a bug report that mentions a strange problem, since other people might see the same thing and be motivated to file a proper bug report with repro steps, or maybe the developers knew about it and de-prioritized it because they thought nobody saw it. But that's not enough to say that the developers are lazy for not dropping everything trying to reproduce a crash that (as far as they know) only happens on your environment.

    9. Re:useful or bloat? by amorsen · · Score: 1

      They have the test case. Run a specific version of Freenet for 10 minutes and you get the crash. Completely reproducable. What they don't have is a small test case.

      --
      Finally! A year of moderation! Ready for 2019?
    10. Re:useful or bloat? by amorsen · · Score: 1
      I wasn't exactly the only one hitting that problem. Dozens of people hit it. The Freenet developers recommended going back to 1.4.1 where the bug is harder to hit.

      So, my system is unlikely to be the culprit.

      --
      Finally! A year of moderation! Ready for 2019?
  22. Re:Faster? by MemoryDragon · · Score: 0

    Yeah sure... whoever has voted this insightful, should rething his voting, the poster was a blatant troll.

  23. Re:J2EE -- 1.3.1 still by tmasssey · · Score: 3, Interesting
    I've been disappointed with IBM's response to Java lately. The last version easily downloaded for Windows is 1.3. The only way I was able to get Java 1.4 for Windows was to download the MQ Series client (like 200MB big!) and pull the JDK out of that...

    I wonder if IBM will have a 1.5 JDK? For a company that is putting a lot of juice behind Java, it seems odd that they don't make the JDK available to others...

  24. The new for loop and type safe collections rock by ShatteredDream · · Score: 5, Informative

    The new For loop may seem to be just syntactic sugar, but it isn't. It really does make the code look a lot cleaner when you are iterating over a collection or an array. The type safe collections are also very handy--no more class cast exceptions and stuff like that.

    It would be nice though if Sun would make Groovy or Jython a standard part of their java distribution. That would definitely make it competitive with .NET

    1. Re:The new for loop and type safe collections rock by joib · · Score: 1


      The new For loop may seem to be just syntactic sugar, but it isn't. It really does make the code look a lot cleaner when you are iterating over a collection or an array.


      Great. Give it another decade or two, and Java might even have Fortran style array syntax! ;-)

    2. Re:The new for loop and type safe collections rock by DevCybiko · · Score: 5, Insightful

      The new For loop may seem to be just syntactic sugar, but it isn't. It really does make the code look a lot cleaner isn't that the definition of syntactic sugar?

    3. Re:The new for loop and type safe collections rock by julesh · · Score: 3, Interesting

      Carrying on down this path much farther, you become able to argue that C is just syntactic sugar for assembly language, and therefore assembly language is just as good.

      Face it. Syntax matters.

    4. Re:The new for loop and type safe collections rock by Anonymous Coward · · Score: 0

      The new For loop may seem to be just syntactic sugar

      I love syntactic sugar. I put a ton of it on my for loops for breakfast.

    5. Re:The new for loop and type safe collections rock by cbiffle · · Score: 3, Insightful

      I both do and do not agree with this.

      The new for loop most certainly is syntactic sugar. It's taking something we could do before and shortening it into a new construct.

      However, a lot of folks use 'syntactic sugar' as a derisive term. It's not. It saves programmer time. Generally the times that it's bad are when it's (a) hiding what's really happening to a degree that introduces bugs, or (b) misguided, like SQL's attempts at being English-like.

    6. Re:The new for loop and type safe collections rock by bnenning · · Score: 1

      The type safe collections are also very handy--no more class cast exceptions and stuff like that.

      I'm reading the PDF for generics now, and they look obnoxious due to the absolute insistence on type safety. If I have a List<? extends Shape>, I can't add a Rectangle because the List *might* be a homogenous collection of some other Shape subclass? That's just silly; if it is, just throw a ClassCastException rather than crippling the developer. (It might be null too, guess the compiler should prevent me from calling *any* method on it, just to be safe). Generics look like a complex non-solution to a simple non-problem to me, but then I've always preferred dynamism to strong typing, and I don't regularly run into the type errors that generics claim to solve.

      --
      How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
    7. Re:The new for loop and type safe collections rock by ed1park · · Score: 1

      so the conclusion? sugar is good. syntactic or otherwise. yum!

    8. Re:The new for loop and type safe collections rock by iMaple · · Score: 1

      If u did want to add both Rects and Circles to the List u should be defining List(Shape) l . If you have List (Circle) then I see no reason to allow Rects in that . BTW the round brackets are to be read as angular brackets

    9. Re:The new for loop and type safe collections rock by Pinky · · Score: 1

      Syntactic sugar is a language feature that only makes the code look nicer and / or to saves some typing. To say that some new language feature is NOT syntax sugar because it makes the code shorter or nice is silly. That's the whole point of syntac surgar.

      Here are two examples of language features ->

      The for loop interractor construct is syntactic sugar because you could do an iterator loops before. The only difference is now it's shorter to write and makes the loop look nicer.

      The generics feature is not syntatic sugar because it adds to java the possibility for the compiler to track type information through generic containers. You couldn't do that before. Now you can. So it's not syntax sugar.

    10. Re:The new for loop and type safe collections rock by bnenning · · Score: 1

      If u did want to add both Rects and Circles to the List u should be defining List(Shape)

      Yes, I think you're right. There's a difference between List<Shape> and List<? extends Shape>, in the first case you can insert a Rectangle, in the second you can't. I've read more on generics, and I still maintain they add unneeded complexity for marginal benefits.

      --
      How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
    11. Re:The new for loop and type safe collections rock by mewphobia · · Score: 1
      Face it. Syntax matters.

      Thank you for this comment. If i had mod points you'd go straight to the top!

      Until the days of virtual machines, syntax was ALL that mattered. No languages were anything but syntax + assembly (well i'll go further and say machine code ;) ). It's a shame that there aren't more advances made in language syntax.

    12. Re:The new for loop and type safe collections rock by HuguesT · · Score: 1

      Come on, what are you talking about? Assembly language itself is syntactic sugar!

      Horray for the olden days when you entered the binary code with rotating dials and a button. Who needs a loader? Who needs an O/S!

  25. It's out there! by aug24 · · Score: 2, Informative

    Check out gcj, part of gcc (Translation: check out the gnu compiler for java, part of the gnu compiler collection).

    I gave it a whirl about a year ago and it was fine, fine for the relatively simple stuff I experimented with.

    J.

    --
    You're only jealous cos the little penguins are talking to me.
  26. Comment removed by account_deleted · · Score: 1

    Comment removed based on user account deletion

  27. Re:J2EE -- 1.3.1 still by robbyjo · · Score: 2, Informative

    Are you sure? J2EE is 1.4 already.

    --

    --
    Error 500: Internal sig error
  28. 5 or 1.5? by Mirk · · Score: 1
    Is this in fact Java 5, or Java 1.5?

    Until the Java world manages to get its act together on agreeing that little detail, forgive me if I remain skeptical about their agreeing APIs in sufficient detail for write-once, run-anywhere to be anything more than a nice fairy-tail.

    --

    --
    What short sigs we have -
    One hundred and twenty chars!
    Too short for haiku.
    1. Re:5 or 1.5? by Cederic · · Score: 4, Insightful


      Fairies have wings, not tails.

      I agree though, the naming of Java is consistently confusing. Should I upgrade from Java 2.. err.. J2SE.. err.. Java 1.3.1_08 to Java 5 or to Java 1.5 or indeed Java 1.5.0. Oh, and is J2EE 1.4 compatible with this new one?

      It could be much simpler..

      ~Cederic

    2. Re:5 or 1.5? by pjt33 · · Score: 1

      Yes, it is. Come on - Solaris and Emacs use similar numbering systems.

    3. Re:5 or 1.5? by NSash · · Score: 1

      Uhhh, where have you been? Java 1.2 was quite some time ago.

    4. Re:5 or 1.5? by WWWWolf · · Score: 1

      I think this should be reasonably close to truth:

      • Java 5, J2SE 5.0 (improvement of which is what was previously "Java 2")
      • J2SE Runtime Environment and J2SE SDK version 1.5.0

      In other words, the language/platforms uses the minor revision numbers of the SDK.

      Though I wonder why the heck it's called "J2SE 5.0". Doesn't J2SE come from "Java 2, Standard Edition"? Wouldn't that now rather be J5SE, or does that look too L33T? Where's J5EE and J5ME? Now my eyes hurt.

    5. Re:5 or 1.5? by Anonymous Coward · · Score: 1, Insightful

      Fairies have wings, not tails.

      No, no! Fairies wear boots!

    6. Re:5 or 1.5? by Pinky · · Score: 1

      the Java API version numbering scheme, from what I can tell, works like this

      The first digit denotes platform changes that break backwards compatibility

      The second digit denote platform changes that break forward compatibility.

      The last digit details changes in implementation (in the java code)

      the _0X digit denotes changes in the VM native / compatibility code.

      Unfortunately, the public does not understand this versioning scheme since it's not how things usually work. Things usually work

      First number - get REALLY excited
      Second number - we made a bug fix you should get exited about
      Last number - woop, we made a small goof, we fixed it here bug don't get too excited.

      Since Java's none-backwards compatible changes line up nicely with the releases people should get exited about they are calling the java 1.5.X branch java 5.

    7. Re:5 or 1.5? by BobPaul · · Score: 1

      So that means that with Java 1.5 I can still run all of my old Java APs, but that some programs may require 1.5 as a minimum now?

      ~~
      Geez, I have Java 1.4 apps that require at least a specific build of Java 1.4 if they don't work. Doesn't that show a break in forward compatibility? The program doesn't work on older Java 1.4 systems...
      ~~

    8. Re:5 or 1.5? by rjshields · · Score: 1

      I wonder if it has anything to with the forthcoming C# 2.0 release, and Sun wanting to make it clear that actually, Java has been around a lot longer.

      --
      In this world nothing is certain but death, taxes and flawed car analogies.
  29. I'll wait by JanneM · · Score: 1

    I won't be upgrading until my bank and other "serious" Swdish websites requires the upgrade for the login/security applet crap I need to run every time. Until then I will not even breathe on the VM or runtime. It is kind of flaky already, and it would be a minor disaster to be locked out of my bank just because that applet stops working.

    --
    Trust the Computer. The Computer is your friend.
    1. Re:I'll wait by Anonymous Coward · · Score: 0

      Switch to SEB?
      You only need a funky little keypad thingymajig to login to the website.
      Works like a charm in IE and Moz without the need for silly plugins.
      -rylin

    2. Re:I'll wait by JanneM · · Score: 1

      It is a BankID, which is used on several other sites as well. Won't get rid of it even if I switch banks - and as I reside in Japan right now, switching banks (or doing any banking in person) is pretty much impossible for me.

      --
      Trust the Computer. The Computer is your friend.
  30. Re:oh great by markov_chain · · Score: 0

    Go out for coffee? But it's only 11!

    --
    Tsunami -- You can't bring a good wave down!
  31. The language wars never ceases to amaze me by nhnfreespirit · · Score: 4, Insightful

    In typical /. style, as soon as Java is as much as mentioned, everybody expects the flame wars to erupt, and they always do...

    I try to stay pragmatic about the programming languages that I use. For some jobs, Java would be my last choice, and for some it seems a natural fit. When writing hardware near code, or platform dependant stuff on driver level, nobody in their right mind would attempt to use Java. For high level rapid prototyping, Java is a often a quick and easy way of getting things done.

    1. Re:The language wars never ceases to amaze me by bahamutirc · · Score: 1

      A lot of people only know maybe one or two programming languages. So when you say "use the best tool for the job", the look bewildered.

    2. Re:The language wars never ceases to amaze me by Cederic · · Score: 1


      You stay pragmatic, yet cunningly manage to deride the language for certain low level developments and pigeonhole its use for lightweight temporary code.

      Fortunately the rest of the industry recognise that most code fits somewhere in between and thus values the language rather more than you.

      Java is less capable than other languages at certain types of development. It is more capable than other languages for other types of development. It is comparable to some languages for some types of development.

      Language choice is dependent on language availability, performance characteristics, ease of development, skillset availability, overall costs, portability, personal preference and a few other criteria. It would be unfortunate to label a language as good or bad in all circumstances.

      ~Cederic

    3. Re:The language wars never ceases to amaze me by nhnfreespirit · · Score: 1

      I guess I should have added a "for instance" in there somewhere... :-)

      I am in no way trying to belittle Java, I was just trying to state one example where I considder Java to be a god choice, and one example where Java would be a bad choice! This is not the same as stating that Java should ONLY be used for "lightweight temporary code"

      I have Just written the majority of the code for my master thesis in Java on different platforms (The only thing not written in Java is a very small amount of hardware near code) This could of course be considdered a prototype system, but the base system should be quite easy to mature into a real world system

      I have been involved in large projects where Java was used with great sucess and others where Java was used, but it became painfully obvious to all invovled that it was not the optimal choice for this particular application.

    4. Re:The language wars never ceases to amaze me by BigGerman · · Score: 2, Insightful
      The biggest problem with Slashdot Java flaming is that people do not realize what Java is.
      If you compare language to language, say Java to C, C# or even Ruby and Python, it is easy to see why Java is "slow" and "bloated". But Java is to be compared to something like .NET and not just a language.

      Java is a platform. Java provides on-the-fly class loading and verification including digital signing of the code, very fine-grained security model (you can create your own sandbox with whatever security rules you want), first-class GUI (fast and responsive if you know what you are doing), tons of class libraries, enterprise APIs (which, minus ill-fated EJBs, are very popular), crypto and much more.
      So the only "other" platform of similar mugnitude is .NET and this is what you need to measure Java against.

    5. Re:The language wars never ceases to amaze me by Anonymous Coward · · Score: 1, Informative

      Call me crazy, but I prefer to prototype in Perl, and then if necessary (and only if necessary) rewrite in C. And if possibly, only critical parts, using XS or Inline::C. Possibly some assembly too if banging on the hardware.

    6. Re:The language wars never ceases to amaze me by AvantLegion · · Score: 1
      When writing hardware near code

      You can WRITE hardware?

      You are teh l33t!

    7. Re:The language wars never ceases to amaze me by roman_mir · · Score: 1

      I use whatever is necessary to get the job done and in my current contract I am using Java as the first tier and JNI as the second tier and some C++ and driver code as the third tier to drive video walls.

      Video walls are a bunch of rear-projection TVs put together into one screen. So for example right now I am testing on a 2x2 wall with 4 70" rear projection cubes (they are not TVs, they are steel cages with only a projector but no sound system and they are controlled by large computers called FRCs or Fault Resilient Computer.)

      So I am controlling the video screens and other applications on the wall, and I am building software that uses Java for presentation tier for displaying video. I think Java is good for management type jobs and presenting a GUI is a management type job. C++ is used in our project for communicating with the devices and implementing high level functions that are used from the GUI. But the GUI is built in a way that allows portions of it to be reused in other projects that allow controlling such walls over network.

      So there is a use for any tool.

  32. hmm. but how does this compare with Mono by ancice · · Score: 3, Interesting

    Nice that Java VM is now faster; it's one of the major drawbacks of java on the desktop. But how does this compare with the new and shiny Mono? Mono with its distributed system, and if it still beats Java, then java is in for a tough fight.

  33. Write once, run anywhere by Anonymous+Writer · · Score: 2, Insightful

    Java had all this hype about it when it was promoted nearly a decade ago, but it never got anywhere close to the point where you could walk into your local computer store and buy a major software package that could be run on any platform. I recall that Corel was going to attempt to release a WordPerfect that ran using Java, but that's the most I heard of it being adopted by mainsteam software developers. Does anyone think it will ever take?

    1. Re:Write once, run anywhere by Cederic · · Score: 2, Interesting


      Rather than mod you troll, here's a simple answer.

      >> Does anyone think it will ever take?

      What makes you think it hasn't? A single example: What percentage of Apache Foundation products are written in and/or for Java. Note that Apache Foundation products are used extensively in Enterprise software development, deployment and systems.

      ~cederic

    2. Re:Write once, run anywhere by qodfathr · · Score: 2, Informative

      Well, what about something like Oracle JDeveloper? Here's a very complete and modern GUI IDE, written in Java, which runs unaltered on many operating systems.

      Maybe you can't find it on the shelf at a retail computer store, but it is a for-purchase product. (Free to download and play with, of course.)

      --
      Yes, it's true. This man has no dick.
    3. Re:Write once, run anywhere by argent · · Score: 1

      Unfortunately Java is being widely used. Why unfortunately? Because it's a wonderful tool for companies to use to keep their products closed. For example, just about every IP-based KVM out there uses a unique Java-based client rather than using an openly documented remote access protocol like VNC or X11 that has multiple independent implementations to choose from.

    4. Re:Write once, run anywhere by DevolvingSpud · · Score: 2, Interesting

      How about Borland JBuilder? That's a big, powerful IDE, and I'd consider it a successful commercial product. Also, from the games side, Puzzle Pirates is a Java game, and good chunks of Chrome are Java. Oh yeah, plus about a billion cellphone applications.

      --
      Keep your friends close.
      Keep your enemies in a little jar on your desk.
    5. Re:Write once, run anywhere by Anonymous+Writer · · Score: 2, Insightful

      Rather than mod you troll, here's a simple answer.

      I honestly wasn't trying to troll. If you walk into a computer store and look at all the off-the shelf consumer-level software products, they're all for Windows. I was hoping that Java would have changed this so that you can buy one of these off-the shelf products and run it on any platform. I know that it has gained acceptance at the enterprise level, I was actually referring to the consumer level.

    6. Re:Write once, run anywhere by hugesmile · · Score: 1
      Your sig:

      Keep your friends close.
      Keep your enemies in a little jar on your desk.

      Did you mean ".jar"?

    7. Re:Write once, run anywhere by Anonymous Coward · · Score: 0

      off the shelf consumer products are actually a pretty low percentage of software sales.

    8. Re:Write once, run anywhere by Anonymous+Writer · · Score: 1

      How about Borland JBuilder?

      I wasn't aware that JBuilder was written in Java. That seems very logical, and interesting because it kind of recursive. But I was thinking more along the lines of something like Quicken, MYOB, The Sims, that sort of thing- software targetted for the masses, not just developers. I have a Powerbook, so I'm constantly disappointed to see computer stores in my area with shelves and shelves of software, but I can't use any of them because their all for Windows. They could easily have a Mac section, but they simply don't bother. I have to go to a Mac shop to get versions for my computer, and the selection isn't as great. If they were written in Java, I could go to any store, not just a Mac shop.

      Oh yeah, plus about a billion cellphone applications.

      I like the fact that it has been taking off for cellphones. I got into a discussion the other day about it with some guy who knew about cellphones, because I wanted to know whether or not you could write programs for cellphones without having to worry about being isolated to a few models. It seems like the only way software developers can make "off-the-shelf" software for mobile phones is by sticking with Java, which would be a great scenario for computers.

    9. Re:Write once, run anywhere by JavaLord · · Score: 1

      Java had all this hype about it when it was promoted nearly a decade ago, but it never got anywhere close to the point where you could walk into your local computer store and buy a major software package that could be run on any platform. I recall that Corel was going to attempt to release a WordPerfect that ran using Java, but that's the most I heard of it being adopted by mainsteam software developers. Does anyone think it will ever take?

      The problem becomes what version do you code for? You never really know which version a person has, and sometimes they may not want to upgrade or be technically inclined enough to upgrade. For example, IIRC full screen mode wasn't available prior to 1.4.1 so if you were to code using that class it wouldn't run on an old JVM. I guess you can make it a requirement on boxed software, but if you ask most users what version of Java they have you will get a shrug in return.

    10. Re:Write once, run anywhere by simonecaldana · · Score: 1

      Moreover, sold (or better, commercially licensed) software is only a part of used software.

    11. Re:Write once, run anywhere by Anonymous+Writer · · Score: 1

      Oh, and just curious about JBuilder- do you find that it is a better tool for systems analysis than Visual Studio? I'd like to know what the standard is. How do JavaBeans compare to Active X for software development?

    12. Re:Write once, run anywhere by DevolvingSpud · · Score: 1

      It seems like the only way software developers can make "off-the-shelf" software for mobile phones is by sticking with Java, which would be a great scenario for computers.

      That's something that's always puzzled me - I've been to several conferences where various tool vendors are showing off applications that could very easily be written in Java - but they're written in either VB or some extremely Windows-oriented GUI builder so they're no-go on Mac, Unix, Linux, etc.

      Seems to me that it's a free way to really expand your potential pool of buyers. But that's just me.

      --
      Keep your friends close.
      Keep your enemies in a little jar on your desk.
    13. Re:Write once, run anywhere by DevolvingSpud · · Score: 1

      Did you mean ".jar"?

      I didn't before, but I do now!

      And a self-executing .jar at that. Saves me the bullet.

      --
      Keep your friends close.
      Keep your enemies in a little jar on your desk.
    14. Re:Write once, run anywhere by Anonymous+Writer · · Score: 1

      Moreover, sold (or better, commercially licensed) software is only a part of used software.

      I should have said "does anyone think it will ever take for the commercially licensed market", but that is actually the scope I implied by giving the example of walking into a computer store, not the overall market for software including the enterprise-level market. I'm still wondering if someday computer stores will carry mostly off-the-shelf Java software, because I would actually like to see that be the norm.
    15. Re:Write once, run anywhere by DevolvingSpud · · Score: 1

      Oh, and just curious about JBuilder- do you find that it is a better tool for systems analysis than Visual Studio? I'd like to know what the standard is. How do JavaBeans compare to Active X for software development? Drop me a line at nathan dot carpenter at raba dot com and we can discuss offline.

      --
      Keep your friends close.
      Keep your enemies in a little jar on your desk.
    16. Re:Write once, run anywhere by Anonymous+Writer · · Score: 1

      The problem becomes what version do you code for? I guess you can make it a requirement on boxed software, but if you ask most users what version of Java they have you will get a shrug in return.

      Perhaps part of a software installation process for off-the-shelf software could include a version check and automatic upgrade, if Sun would allow developers to distribute Java without charge.

    17. Re:Write once, run anywhere by Anonymous+Writer · · Score: 1

      they're written in either VB or some extremely Windows-oriented GUI builder so they're no-go on Mac, Unix, Linux, etc.

      I've also noticed that hardware developers are shooting themselves in the foot by not providing drivers and software for different platforms, or at least software with equivalent features as their Windows counterparts, especially if their hardware uses USB. One example is Visioneer. They make a great paper archiving setup, and had a Mac version up until OS X, when they dropped support for the platform. Another example is Canon. I noticed that although the software they provide for their LiDE 50 scanners look similar on both platforms, there are slight differences that matter. The Mac version of their Toolbox lacks the option of manually handling the numbering of files when you use the "Save" function in the toolbox. And their ScanGear software lacks the "Text Enhanced" feature that the Windows version has, which is important for compression. Not having these options set up prevents their scanners from being efficiently used for paper archiving on the Mac in comparison to the Windows version.

    18. Re:Write once, run anywhere by simonecaldana · · Score: 1

      with realities like QT/mac/win32, GTK/win and Mono and supposing the linux desktop will grow for home users my two cents will go (for computer shops shelfs) to a mix of .NET, Gnome, KDE and Java software, all being multiplatform. But I don't expect this until non-Windows desktops reach at least 20% of the _sales_.

      And games will be the linux _home_ desktop killer apps. On this I bet far more than 2 cents :)

    19. Re:Write once, run anywhere by Anonymous Coward · · Score: 1, Funny

      JBuilder, I knew it! That explains why it takes 35 freakin minutes to START UP. Java really, really sucks bad. Defend it to the end, but it is slow as hell, and a total pain in the ass. If the whole java world dried up and died tomorrow, the world would be a better place.

      Puzzle pirates, lots of fun, except for the FREAKIN waiting between screens. God.

      If you are a project manager out there, and you are reading this, please, please, please promise that at the next project kick off, if ANYONE says "lets use java", fire their asses, and burn their bodies in a barrel.

      The sooner we all admit that Java is painfully slow, doesn't "run on anything", and is not elegant, the better off we will all be.

    20. Re:Write once, run anywhere by juhaz · · Score: 1

      That doesn't make any sense whatsoever.

      If there was no Java, then just about every IP-based KVM out there would use unique $LANGUAGE-based client rather than using ....

    21. Re:Write once, run anywhere by argent · · Score: 1

      If there was no Java, then just about every IP-based KVM out there would use...

      VNC, or X/NX/LBX, or even Citrix/RDP: some publicly documented and defined protocol that has good high-quality clients available for almost every platform (including systems that do not, can not, and will not ever be able to run Java fast enough to do the job), that has well understood network behaviour so it can be forwarded and proxied, and can be scripted however clumsily using existing software. The "remote display" wheel doesn't need to be reinvented, and it certainly doesn't need to be reinvented as badly as the Java KVM clients I've had to deal with.

      We even have "remotely managable" devices now that are using a Java-based client that doesn't do anything more than telnet! In this area, Java is just promoting another step back from open systems back into the dysfunctional morass of proprietary protocols and badly behaved clients that you're stuck with because they're the only thing that works with your applications.

      There's a few companies that provide VNC access to their KVM, but the majority just go "Oh yeh, Java, that's cool, we'll take a steaming cup of that."

      Here's one, RealVNC KVM-over-IP, that gives you VNC, and includes a Java VNC client as well. There's absolutely no excuse for any KVM-over-IP vendor to do any less. Building a KVM with a proprietary remote access protocol makes about as much sense as building an OS with a proprietary network stack instead of TCP/IP.

  34. Bytecode Compatibility by Brian+Blessed · · Score: 4, Insightful
    I thought that the compiled Java would remain compatible with the bytecode format used by previous versions. However, this seems not be the case and I get this message:
    java.lang.UnsupportedClassVersionError: HelloWorld (Unsupported major.minor version 49.0)

    Whilst code that uses the new language features must obviously be compiled with the v1.5 JSDK, this means that it must also be run on the v1.5 JRE.

    This may inhibit the use of Java 5 by projects that want their programs to run on a v1.4 JRE.

    - Brian.
    1. Re:Bytecode Compatibility by moro_666 · · Score: 0

      try -target 1.1 and -source 1.1

      this should make java classes that run with everything since jdk1.1 ... ofcourse unless you use classes from newer java versions (forward compatibility is somewhat impossible :p)

      --

      I'd tell you the chances of this story being a dupe, but you wouldn't like it.
    2. Re:Bytecode Compatibility by pjt33 · · Score: 1

      If you want to compile for older VMs, you have to use the -target compiler option. This isn't new.

    3. Re:Bytecode Compatibility by Z-MaxX · · Score: 4, Informative

      You need to use the "-target 1.4" option to javac to tell it to produce the older version of class files.

      --
      Dr Superlove 300ml. I use my powers for awesome
    4. Re:Bytecode Compatibility by Cederic · · Score: 2, Insightful


      I would hope that 1.2, 1.3 and 1.4 bytecode would run in the 1.5 JRE. I think it's ambitious to expect 1.5 bytecode to run in a pre-1.5 JRE - the language has new features that such JREs don't know about or support.

      While you could obviously write code that interprets 1.5 bytecode so that it will run on a 1.4 JRE, and make it possible to automagically create that code at compile-time, including it by default in the compiled 1.5 code would be wasteful as it's not required to run in a 1.5 environment.

      So yes, it will inhibit the use of Java 5 by projects that wish to run on JRE1.4. And trust me, I'm extremely distressed that my company is still stuck on Weblogic 6.1 as that only works with JRE1.3, so I haven't even been able to make use of J2SE 1.4 capabilities in code, but life goes on.

      ~Cederic

    5. Re:Bytecode Compatibility by Brian+Blessed · · Score: 1

      (forward compatibility is somewhat impossible :p)

      I had heard somewhere that the bytecode format would remain the same, so forward compatibility of compiled Java would work because the new language features would only be visible to the compiler.

      - Brian.

    6. Re:Bytecode Compatibility by Sporkinum · · Score: 1

      That would have been nice, but at least with the 1.4 app our compasny uses, that is not the case. I deleted the old java runtimes, installed the new one, and reinstalled the app. It no longer did desktop integration using webstart, so no icon for the users. It started slower and then hung.

      Reinstalled 1.4 jre, still same problems. Deleted 1.5 jre, and apps are back to normal.

      --
      "He's lost in a 'floyd hole"
    7. Re:Bytecode Compatibility by cheeser · · Score: 1

      And that's a surprise to whom? You can target the 1.4 VM when you compile, but obviously you're going to run into limitations using 1.5 features. That's the way it's always been.

      --

      --
      http://cheeser.blog-city.com

    8. Re:Bytecode Compatibility by Brian+Blessed · · Score: 1

      I know about "-target 1.4", but what I had been assuming is that the compiler would produce bytecode that could be run on an older JRE, even if the new language features were being used (i.e. you can't have "-target 1.4 -source 1.5")

      - Brian.

    9. Re:Bytecode Compatibility by Brian+Blessed · · Score: 1
      See This comment. It says:
      Java opted for 'erasure' approach because they needed to preserve backward-compatibility. So that means that all generic type information is removed by the compiler/translator and that code is replaced with polymorphic subtyping with casts

      This suggested that the bytecode output of the new compiler would work with previous JREs, but this has turned out not the be the case.

      - Brian.
    10. Re:Bytecode Compatibility by Cederic · · Score: 1


      You have my sympathy. I've not yet dared try running our J2EE application deployed in Weblogic 6.1 on Java 1.3 in Java 5 - heck, I don't even dare try and compile it :)

      Later today perhaps, once I have a little more time..
      ~Stuart

    11. Re:Bytecode Compatibility by Brian+Blessed · · Score: 1

      I had read comments on here such as this one that suggested that changes were limited to the compiler.

      However, looking at the JSR 14 (for generics), it says:

      It is explicitly not required that the system

      a) Provide downward binary compatibility: It is not necessary that class
      files compiled under the generic compiler should run on previous releases, whether they
      use generics or not.


      - Brian.

    12. Re:Bytecode Compatibility by angel'o'sphere · · Score: 1

      Old classes run on new VMs, if you want to use the new compiler and runclasses on old VMs, use javac -target 1.4 e.g.
      However if you use "new APIs" you slightly stuck as the new runtime classes partly won#t run on old VMs either.
      angel'o'sphere

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    13. Re:Bytecode Compatibility by angel'o'sphere · · Score: 4, Informative

      (i.e. you can't have "-target 1.4 -source 1.5") . Yes, you can have it!
      But what about your classpath, does it reference the 1.5 JRE? E.g. if the 1.5 java.lang.String gets loaded by an old JVM you might get that errro as well.
      angel'o'sphere

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    14. Re:Bytecode Compatibility by julesh · · Score: 4, Informative

      I thought that the compiled Java would remain compatible with the bytecode format used by previous versions.

      The bytecode format is still identical. The version number on the file was incremented because classes that depend on assertions could break badly if used on a JVM that doesn't implement them (which is actually a feature of a few classes in java.lang, not a bytecode interpreter feature). Use the '-target' commands recommended by the other posters whenever producing code that doesn't rely on one of the new features.

    15. Re:Bytecode Compatibility by pjt33 · · Score: 1
      The bytecode does work. It's only the class version number which doesn't. Every new version of Java has incremented the major version number of the class files produced by javac, and has provided -target to allow you to compile to an older version number.

      You're misunderstanding "backwards compatibility", by the way. It means that old class files work with 1.5 without recompilation.

    16. Re:Bytecode Compatibility by Anonymous Coward · · Score: 0

      I had been assuming is that the compiler would produce bytecode that could be run on an older JRE, even if the new language features were being used

      What? why would they release a new JRE if that were the case?

    17. Re:Bytecode Compatibility by Astadar · · Score: 1

      Nobody supports forward compatibility. There is no way for anyone to know what will be in the 1.5 release to offer support for those features in the 1.4 JRE.

      Backward compatibility, yes. Code written under 1.4 should run fine in a 1.5 JRE unless long deprecated methods that were removed are used in the code.

      --
      --Coming up with something clever... please wait...
    18. Re:Bytecode Compatibility by rreyelts · · Score: 2, Interesting

      It has been known for a long time (over a year), that Java programs compiled for 1.5 will not run on a 1.4 VM. However, you can use tools like Retroweaver to get 1.4 compatibility. It rewrites the bytecode of your version 1.5 class files into the 1.4 VM format.

    19. Re:Bytecode Compatibility by Brian+Blessed · · Score: 1

      You're right. I just compiled code with a foreach loop in it (so -target 1.4 won't work) and then changed the class version with hexedit. It ran fine on a v1.4.2 JRE.

      - Brian.

    20. Re:Bytecode Compatibility by alder · · Score: 1
      Use
      -target 1.3
      with javac. Then your older JVM won't complain. Or, if source permits and project needs it (like for applets), use
      -target 1.1
      , then even MS jview will run it.
    21. Re:Bytecode Compatibility by rreyelts · · Score: 1
      The bytecode format is still identical.
      It's most definitely not identical. There are several changes that went into the classfile/bytecode format for 1.5. Just a few examples off the top of my head:
      • new Signature attributes (for generics)
      • new Varargs access specifier
      • the JVM LDC instruction now supports class literals
      • new Annotation attributes
      • New Synthetic access specifiers replace old Synthetic attributes
      Above and beyond the bytecode/classfile format changes, using -target 1.5 will cause the compiler to automatically take advantage of new code that is only available in the 1.5 runtime. For example, enums depend upon java.lang.Enum, the new for loop depends upon java.lang.Iterable, the compiler supports string concatenation using the new StringBuilder class instead of StringBuffer, etc...

      Retroweaver takes care of all of that, and was even given a thumbs up by the 1.5 compiler writer, Neal Gafter.

    22. Re:Bytecode Compatibility by Brian+Blessed · · Score: 1

      There is no way for anyone to know what will be in the 1.5 release to offer support for those features in the 1.4 JRE.

      This isn't true because the JRE is a general computing platform. Sun can add features to the Java compiler that will generate bytecode compatible with v1.4 JREs.
      Indeed, as someone else mentioned, forwards compatibility can be achieved using Retroweaver.

      - Brian

    23. Re:Bytecode Compatibility by harlows_monkeys · · Score: 1
      And that's a surprise to whom? You can target the 1.4 VM when you compile, but obviously you're going to run into limitations using 1.5 features. That's the way it's always been

      Well, it's a surprise to me. I had thought of the VM as being kind of like a high-level assembly language. When I switched from C to C++, I didn't have to get a new processor, after all, even when using all C++ features. :-)

    24. Re:Bytecode Compatibility by julesh · · Score: 1

      OK -- only one of those is a change to the bytecode format, the rest are attribute changes which, due to the clever design of the class file format, a complying implementation of the previous version should be able to get along with just fine.

      I'll admit I wasn't aware of the change to 'ldc'. Do you have a reference to a specification of the changes involved?

    25. Re:Bytecode Compatibility by rreyelts · · Score: 1
      the rest are attribute changes
      No, for example, I listed the change that the old synthetic attributes have now changed to synthetic access specifers, so anything that checks for conforming 1.4 class files would barf on the goofed access specifier (gcj did this up until recently). Same goes for the additional varargs specifier. There are also new JVM changes that will happen soon that will increase things like the limits on the constant pool size, the max amount of bytecode in a method, etc... If you generate a class that goes over the original limits, you're also SOL.
      Do you have a reference to a specification of the changes involved?
      It's all in the revised JVM specification.
    26. Re:Bytecode Compatibility by moro_666 · · Score: 1

      i guess typing "man javac" wouldn't hurt ...

      bytecode's format is not forward compatible, because at any time a genius can come up at suns and invent an idea how the bytecode can be saves faster, safer and smaller.

      --

      I'd tell you the chances of this story being a dupe, but you wouldn't like it.
    27. Re:Bytecode Compatibility by Brian+Blessed · · Score: 1
      > > (i.e. you can't have "-target 1.4 -source 1.5")
      > Yes, you can have it!

      Not on my system you can't:
      $ javac -target 1.4 -source 1.5 HelloWord.java
      javac: source release 1.5 requires target release 1.5
      - Brian.
    28. Re:Bytecode Compatibility by julesh · · Score: 1

      > Do you have a reference to a specification of the changes involved?

      It's all in the revised JVM specification.


      Which I can't find on Sun's site. The link to virtual machine specification (http://java.sun.com/docs/books/vmspec/2nd-edition /html/VMSpecTOC.doc.html)
      seems to only describe stuff that dates back to the 1.2 days.

      Do you have a URL for the up-to-date version? It seems the changes here were much more serious than I had believed, and I might need to update some of my software to cope with them. :(

    29. Re:Bytecode Compatibility by angel'o'sphere · · Score: 1

      Interesting, to bad I can not mod here ... because of ma poss before.
      On my Mac (in the CodeGuide IDE) it works.
      angel'o'sphere

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
  35. mod parent down by hruntrung · · Score: 5, Insightful

    That's not interesting, that's cliche. People have been saying that for years. Let's be honest: virtual machines are where business code is going, and business code (enterprise applications, server side stuff, etc) is the primary focus of Java these days. .NET is a clear indication that this trend is a real one, and that that's where the industry is heading.

    No, I don't think you should write ls or grep in Java. However, I'd say that you also shouldn't be writing an invoice processing system in C or C ++.

    1. Re:mod parent down by MemoryDragon · · Score: 1

      It is pretty clear why. Business applications are server side applications. The uptime of VM based languages simply is amazing, if you dont do any serious memory leaks (which are not that easy with GCs and weak referencing) then you can get uptimes in years even in a 1.0 release.

      The main problem still is (also with a shared VM) the memory footprint, memory is handled differently. But in the long til midterm, we will probably see important server infrastructure like plain webserving, database servers mailservers and other server stuff being moved to java, the foundations are there.

    2. Re:mod parent down by master_p · · Score: 1

      Nothing stops a C/C++ compiler produce code for a VM. At last, let's separate concepts: one thing is the language, another is the environment programs run, and a completely another is the available libraries.

    3. Re:mod parent down by Trejkaz · · Score: 1

      Bah, everything can be written in C or C++. I wrote my Slashdot commenting bot in C++ and haven't seen a pro Segmentation fault (core dumped)

      --
      Karma: It's all a bunch of tree-huggin' hippy crap!
    4. Re:mod parent down by Anonymous Coward · · Score: 0
      However, I'd say that you also shouldn't be writing an invoice processing system in C or C ++.


      Yes, you should write it in a truly high-level language, like Python, Ruby, Haskell or Lisp. That's the problem with Java. It's not bad, but it is not good enough; for everything you want to do there's a better language to do it than Java. This, IMHO, is a natural consequence of Java's main design flaw: its focus on "average programmers".
    5. Re:mod parent down by Surt · · Score: 1

      ha ha ha you should have used javjava.lang.NullPointerException

      --
      "Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
    6. Re:mod parent down by gtrubetskoy · · Score: 1
      Let's be honest: virtual machines are where business code is going,

      Before Java business code was COBOL and RPG.

      I don't why the parent post got modded to a troll, it makes a very important point. The JVM treats code as data, which makes decades of optimization experience achieved by UNIX (and similar) systems based on the notion of separating code and data impossible. When 15 users run emacs on a UNIX system, it and all the libs it needs are only in memory once. When 15 users run JVMs your load goes through the roof and the system starts thrashing.

      You are correct that there is a trend towards virtualization - look at Linux VServer, BSD jails, and a slew of commercial virtualization solutions currently available. The problem with the JVM is that it itself is not efficiently virtualizable...

      The latest Solaris has a built-in virtualization called "zones". It'd be interesting too see what Sun will say about running JVM's in separate zones and how inefficient it is.

    7. Re:mod parent down by mikefe · · Score: 1

      That is true for most non-compiled languages.

      You can still work around the problem by using fork(). That allows the OS to perform its COW paging, at least for one user.

      I don't know how you'd do it for multiple users, except for some suid binaries that cause a central process to fork, change to your user, and then connect to your console. It'd probably have to be client/server. Which is a shame in order to get standard compiled multi-user memory usage.

      Have any of the interpreted languages done anything in this area?

      --
      There: Something at a specific location.
      Their: Owned by someone.
      Please make sure your english compiles.
    8. Re:mod parent down by jrumney · · Score: 1
      When 15 users run emacs on a UNIX system, it and all the libs it needs are only in memory once. When 15 users run JVMs your load goes through the roof and the system starts thrashing.

      Excuse me for my ignorance here, but what is special about Emacs, which is essentially a Lisp Virtual Machine, that makes it so different to a Java Virtual Machine in this respect?

  36. Re:oh great by Anonymous Coward · · Score: 0

    I'd say you definitely need some java - that's article, not artical :)

  37. Re:Java 5 or 1.5? by pjt33 · · Score: 0, Offtopic

    Emacs?

  38. Re:hmm. but how does this compare with Mono by Anonymous Coward · · Score: 0
    By the way, on my own tests with real applications written in both Java and .NET 1.1, jdk1.4.2 is 20-30% faster. These apps don't do heavy math. From the few benchmarks comparing .NET and Mono, Mono is not faster than .NET. Therefore, Mono is not faster than Jdk1.4.2. For tomcat and other server related apps, Jdk5 is 10-25% faster than jdk1.4.2.

    If you read Mono's mailing list, you'll see they've done a great job, but this is just the beginning. Making Mono faster than MS .NET is going to take a couple of years at minimum. Beating Jdk5 is going to take a while. Of course, other people may have different results. For what I do, Java is a far better choice than .NET or Mono.

  39. Shouldn't this read Have a nice steaming pile of by Anonymous Coward · · Score: 0

    Java 5?

  40. Man, that's not really fair by mcc · · Score: 3, Funny

    Considering that nearly 100% of the justification I've heard from people who like C# is along the lines of "It's not Java".

    ...

    Come to think of it, this entire situation is sort of starting to sound like, um, something else...

    1. Re:Man, that's not really fair by $RANDOMLUSER · · Score: 3, Insightful

      Right. Those Java checked exceptions are so "confusing".

      --
      No folly is more costly than the folly of intolerant idealism. - Winston Churchill
  41. Re:Java 5 or 1.5? by fracai · · Score: 1

    Don't you know that version numbers are largly meaningless? I wouldn't expect 2.0 until Sun decides to to completely re-write Java from the ground up. Or at least make some monumental change that decidedly sets it apart from 1.x. But then again version numbers are usually meaningless and just illustrate a timeline of releases. I guess an ideal method would use .x to demonstrate small changes and x would demonstrate large changes. But in practice people tend to see a jump from 1.4 to 1.5 and think "that's only a small change". A jump from 1.8 to 2.0 would be only a slightly bigger change.

    PS. How much confidence do you have in a product that goes through only about 10 releases and is suddenly at release 2000? ;)

    --
    -- i am jack's amusing sig file
  42. Tiger!? by argent · · Score: 1

    Is there any reason both Sun and Apple are using the codename "Tiger" for new products or is it just coincidence?

  43. Are they mutually exclusive...? by mcc · · Score: 1

    One man's Useful is another man's Bloat...

  44. Naming by melanarchy · · Score: 1, Funny

    If they're giving up and renaming it, they may as well go all the way. I say "Visual Java .NET" would be the perfect new name.

  45. Re:J2EE -- 1.3.1 still by Anonymous Coward · · Score: 0
    Are you sure? J2EE is 1.4 already.
    The OP was talking about Websphere which uses IBM version of J2EE or did you not read the post?
  46. Both by Achoi77 · · Score: 1
    I beleive Java 5 is Java 1.5. They've decided to go with the name change because of marketing reasons only, just like how Java 1.4 is marketed as Java2. Especially now that people would think that java 2 > java 1.5, who would waste their time downloading it? Of course, now that it's up to 'version' 5, it's new and shiny and bug free~

    It's okay, even slackware does it (hence no slackware 4, or 5, or 6). :-)

    1. Re:Both by Trejkaz · · Score: 1

      Not that this will really clear anything up, but...

      The downloadable stuff is JDK 1.5 and JRE 1.5. They stand for "Java2 Development Kit" and "Java2 Runtime Environment" respectively.

      So I would think that the colloquial name for it should be "Java2 1.5". :-/

      --
      Karma: It's all a bunch of tree-huggin' hippy crap!
    2. Re:Both by Trejkaz · · Score: 1

      LOL. Of course I meant 5.0 in all those places where I wrote 1.5. This just goes to show how retarded this numbering scheme is making everyone.

      It was the version strings which still bloody said 1.5... at least in the release candidate. I hope they fixed that since.

      --
      Karma: It's all a bunch of tree-huggin' hippy crap!
  47. Dear Sun by mindaktiviti · · Score: 2, Insightful

    Please make your Windows (XP) Java run time environment download available on the FRONT PAGE or at the most 1 click away. Your latest website is very tricky to navigate and very annoying and what's the point of taking a Java class (which I'm currently doing) when the majority of Windows XP users don't even have the fucking run time installed by default (damn Microsoft!). I mean look at this mess. It's 5 clicks to the .exe file! Who is Joe Schmoe going to know what the hell a "run time environment" is when they're NOT EVEN interested in Java, except in the software they want to install! (i.e. Azureus bittorrent client). Please add a image button (so people see it, make it big and pink or red if you will) that says something like "Windows XP users DOWNLOAD to run your favourite Java applications!" Thank you. Yours Truly, Typical-Family's-Free-College-Long-distance-Tech-S upport.

    1. Re:Dear Sun by Anonymous Coward · · Score: 0

      Man, you got the page for the developers...

      Try: http://www.java.com/

    2. Re:Dear Sun by IsleOfView · · Score: 1
      You have a couple options:
      1. Go to the Java web site for developers/technical people: http://java.sun.com
      2. Go to the consumer-branded website: http://java.com
      Both have the downloads readily available and pretty easy to find.
    3. Re:Dear Sun by Anonymous Coward · · Score: 0
    4. Re:Dear Sun by AaronLawrence · · Score: 1

      Even as a technical user, I get confused about which Java download I need... what is NetBeans? Do I need it? Why is it first and biggest if most people won't need it?

      It shows that Sun *still* have no idea how to do even the smallest things for a non-technical user. Java is their only somewhat mainstream technology, but it shouldn't be that hard...

      --
      For every expert, there is an equal and opposite expert. - Arthur C. Clarke
    5. Re:Dear Sun by vlad_grigorescu · · Score: 0, Flamebait

      Yes Sun, what's wrong with you!??! You know that the poor Micro$oft users can't follow more than one link. Everything for them needs to be, big and flashing (preferably in Aero). In fact, you should make a Java Update page that will only run in IE. Oh, and Automagic Updates. That way, the poor users don't have to click anything at all.

    6. Re:Dear Sun by Anonymous Coward · · Score: 0

      Hey, at least the Windows users can get a decent official Java runtime. Linux users have to rely on third-party builds to get Java working as a Mozilla plugin. You think Sun, which pretends to care about Linux, would get this problem fixed. Yes, I've downloaded the .bin file and no it didn't install properly. I set up the symbolic links in my Mozilla profile and yet it still crashes when I run into a Java applet.

    7. Re:Dear Sun by programic · · Score: 1

      I think java.com was created with simple XP Home users in mind. java.sun.com caters more to technologists.

      --
      -- yawn. --
    8. Re:Dear Sun by LilMikey · · Score: 1

      The RPM seems to work just fine. Maybe the problem is on the other end of the keyboard.

      --
      LilMikey.com... I'll stop doing it when you sto
    9. Re:Dear Sun by Anonymous Coward · · Score: 0

      I use Slackware Linux and have no trouble using other programs. I compile a lot of my software and work mostly in the command line. Furthermore, I refuse to install RPM.

      Have you tried the .bin file? It doesn't work on my box. Until you've tried it, I suggest you STFU.

    10. Re:Dear Sun by Anonymous Coward · · Score: 0

      Joe average doesn't know it's from sun, and visites www.java.com

      Which makes it two clicks away. With a BIG yellow button.

    11. Re:Dear Sun by toolio · · Score: 1
      Check out java.com if you just want to send people to download java.

      There is a large "Get it Now" button that I think you'll like.

      java.sun.com is for developers

    12. Re:Dear Sun by shaka · · Score: 2, Funny

      Go to the consumer-branded website: http://java.com

      Um... I've been a Java developer for about 5 years, and I've never seen that website. Now, can someone please tell me why Sun has put fscking RINGTONES on their Java site!?

      --
      :wq!
    13. Re:Dear Sun by ntrimble · · Score: 1

      java.com fills this request. It's a lot easier than java.sun.com...

    14. Re:Dear Sun by iso · · Score: 4, Informative

      Why don't you try this?

      1) go to java.com
      2) click the big "get it now" button
      3) download the EXE

      Now quit trolling.

    15. Re:Dear Sun by Narchie+Troll · · Score: 1

      rpm2tgz the RPM, open up the resulting tarball, and stick things where you want them.

      If you're a BIG CLEVER I-DON'T-USE-PACKAGING Slackware user, you should know enough to figure out where to put things.

    16. Re:Dear Sun by Anonymous Coward · · Score: 0

      It's the principle of it, though. I refuse to install RPM and thus reject using .rpm files in any form! If Sun doesn't feel like fixing the .bin files them I'm not fucking fixing their piece of shit RPM! Besides, Slackware has a Java package which works fine.

      The point of the matter is that Sun doesn't want to fix their official Java .bin file. Frankly, I hope they never fix the file. That way Sun can rot in Write-Once-Run-Anywhere hell! Fucking open source posers.

    17. Re:Dear Sun by torok · · Score: 1

      http://www.java.com
      Everything you wished for.

    18. Re:Dear Sun by Anonymous Coward · · Score: 0

      Because one of the largest distribution avenues for java happens to be the mobile phone market? What kind of stupid question is that?

    19. Re:Dear Sun by MSBob · · Score: 1

      Except that google sends you to java.sun.com which is just as bad as the original link. And that's what matters. most users will type java in google and follow the first link.

      --
      Your pizza just the way you ought to have it.
    20. Re:Dear Sun by Anonymous Coward · · Score: 0

      And Linux people have to make things so hard to use that only the top 1% of intelligencia could possibly use it correctly.

      How incredably elitist and snobby of you!

    21. Re:Dear Sun by Anonymous Coward · · Score: 0

      Java doesn't work well as a client language. It excels at being run on a server. You don't need your client to have a JVM for that, unless you are developing on your workstation. Very few users who will use your apps will be developing java, so they won't need to worry about it.

      Writing java interfaces that run on windows is fun and educational for class, but don't try it in the real world, and you'll stay out of trouble.

      Most people who run java on servers are competent enough to figure out where to download the and don't mind clicking 5 links that lead them to the right executible for their purpose.

      Learn a little about the language, it's strengths and weaknesses before spewing your idiocy. It just makes you look stupid to bash that which you obviously know nothing about.

      If you want to see what difficulty is all about try getting microsoft .net (aka microsoft's own java) to work on user's machines. Unless you are in a controlled network situation, it has the same issues that java has when building client applications on it.

      It needs a run time, and guess what? it takes 4 clicks to download, and only has to support one platform. Plus, you can only get to the download with internet explorer. How's that for fun?

      Ohhh what if I want to run .net on mac or linux.. ahhh sorry charlie, we only support winders.

      Just for laughs I tried to download and install .net.

      Here is what it told me on my windows 2000 client:
      ----
      No Updates Were Installed

      The following items failed to install. To try installing them again, click Review and install updates, and then click Install Now again.

      Microsoft .NET Framework 1.1 Service Pack 1
      ---
      I didn't have that problem with the JVM. It installed without an issue:
      java version "1.4.1_05"
      Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_05-b01)
      Java HotSpot(TM) Client VM (build 1.4.1_05-b01, mixed mode)
      jackass...

    22. Re:Dear Sun by The+Bungi · · Score: 1
      Windows XP users don't even have the fucking run time installed by default (damn Microsoft!).

      Oh wow, this is rich. Everyone cheered when Microsoft was sued and subsequently forced by Sun to remove their VM and subsequently barred from shipping Sun's VM, (though later Sun came begging again) and here you are bitching about it?

      And while you're at it, how about you bitch at RH as well? Last I checked RH9 didn't install the JRE on my laptop.

    23. Re:Dear Sun by Anonymous Coward · · Score: 0

      Everyone cheered when Microsoft was sued and subsequently forced by Sun to remove their VM and subsequently barred from shipping Sun's VM, (though later Sun came begging again) and here you are bitching about it.

      The way I remember it, it was the microsoft vm, and sun sued them because microsoft turned it into the microsoft jvm which, you guessed it, broke the compatibility with stuff written to run on 'real' jvms, and only work correctly with microsoft-j.

      They didn't follow the spec that was agreed to in the contract, stole sun's architecture and made it their own, so were in violation of said contract, hence the lawsuit. So sun made them remove the jvm because it didn't work right.

      This is understandable and gave java a bad rap. To get java to work right you first had to remove the MS JVM and install Sun's. This is a bigger pain than having users simply download sun's machine. Microsoft never shipped windows with Sun's JVM. It shipped with a bastardized jvm that ms wrote, which violated spec, just like every other standard they have 'embraced'.

      Their implementations of every standard from html parsing to javascript to [insert implementation here] have always without exception, been wrong.

      If you ask me, this is a deliberate attempt to ruin any standard that doesn't originate in redmond.

      This misleads users into believing that anything that microsoft didn't write themselves is broken.

      This is the real tragedy.

      l8,
      AC

    24. Re:Dear Sun by iMaple · · Score: 1

      Netbeans is a good IDE. They probably bundle it to make Java programming easier, so that you dont have to search for a good IDE if you are new to Java. If you have a fav IDE just scroll down and download just the jdk

    25. Re:Dear Sun by Narchie+Troll · · Score: 1

      Why is a essentially proprietary binary installer preferable to an open format?

    26. Re:Dear Sun by AaronLawrence · · Score: 1

      Yep, but my point was that end-users shouldn't have to know what you just said in order to download the JDK. What sun should have is, at the top of the page, a big heading saying "What you need to run Java programs! Click here to download" ... and then under that, explanations.

      --
      For every expert, there is an equal and opposite expert. - Arthur C. Clarke
  48. For a Moment... by Anonymous Coward · · Score: 0

    I panicked when I thought that Only RPM Packages were available for Linux-based systems? Hopefully, they won't go the path of many major vendors who are moving to RPM only distribution method and screwing anyone who uses one that doesn't use RPM (be it anything).

    If it were only RPMs,then it would have been a great blow to clean and easy installation of Java on machines that do not use RPM package manager.

    (It could be easy on an RPM based system, but that is not my point.)

    Furthermore, I have been battling with cpio and other programs to extract the contents of RPM packages, so that I could place it somewhere safe, rather than using something like alien which installes it alongside the other stuff, that I don't want to be polluted.

    Also, RPM package (or any package) based software seems to have hardcoded paths. I hope they are not going to follow the trend here.

  49. Re:hmm. but how does this compare with Mono by MemoryDragon · · Score: 3, Informative

    Sorry, Dude, but the Java VM still is faster than .Net and Mono is significantly slower than .Net (since it is just a basic VM with a basic jit and no runtime optimization)

    Despite the having a slower VM, the .Net programs sometimes can be faster than java programs because they are heavily integrated into windows wheras java has to add abstraction layers for not losing portability.

    But back to Mono it will probably never be able to catchup speedwise with .Net unless they move to another VM which is maintained by a dedicated team (parrot comes to mind) but then they will lose compatibility on binary level to .Net (which is not really there anyway since Microsoft plays cat and mouse with them on a classlibrary level)

  50. Is it C# yet? by LibertineR · · Score: 2, Interesting
    Metadata attributes? Generics support?

    In Java you will not see any performance improvement; the reason is well explained by Anders Hejlsberg (lead C# architect) in http://www.artima.com/intv/generics2.html :
    "For example, with Java generics, you don't actually get any of the execution efficiency that I talked about, because when you compile a generic class in Java, the compiler takes away the type parameter and substitutes Object everywhere. So the compiled image for List<T> is like a List where you use the type Object everywhere. Of course, if you now try to make a List<int>, you get boxing of all the ints. So there's a bunch of overhead there. Furthermore, to keep the VM happy, the compiler actually has to insert all of the type casts you didn't write. If it's a List of Object and you're trying to treat those Objects as Customers, at some point the Objects must be cast to Customers to keep the verifier happy. And really all they're doing in their implementation is automatically inserting those type casts for you. So you get the syntactic sugar, or some of it at least, but you don't get any of the execution efficiency. So that's issue number one I have with Java's solution."

    You can argue with Anders, but then, you would be wrong.

    1. Re:Is it C# yet? by MemoryDragon · · Score: 3, Insightful

      No Hjelfsberg is totally right. The extensions are syntactic sugar. But still they are useful, because, you gain coding efficiency that way. Autoboxing, foreach, generics are all implemented in a way not to break the byte format, but you still need less code for doing jobs like iterating lists fetching elements from data structures and so on. Day to day stuff which you used every 10th line or os.

      Priority #1 for Sun was not to break the bytecode format. Priority #2 was to ease the life of programmers

      The only thing which really will make a difference on code generation level will be the meta data, this one will make life easier for the implementors and for the users of servers. Soap instantly comes to my mind with the C# like @webmethod metadata. No more post and precompilers for doing that stuff, yiehaa.

      Hjelfsberg is a smart guy, although I dont share his views on unmanaged exceptions, he is dead right with his comment on this.

    2. Re:Is it C# yet? by LibertineR · · Score: 1

      Are you referring to the Checked Exceptions controversy he started in that interview? I am back and forth on that, because I believe that simplicity should always come first.

    3. Re:Is it C# yet? by MemoryDragon · · Score: 1

      I see it from a practical point of view.
      I will give you an example of something which happened to me a while ago.

      I had to dock on a bigger java program to a soap server written by a guy in .Net. What happened, the soap server fell regularily on me. After a little bit of research and looking into the guys code I found out, that there were weird exceptions coming down from deep within from the subsystem the guy never caught which hung the entire server and gave me a timeout.

      This is the classic case of why unmanaged exceptions are dead awful. They compromise the stability of your system once it becomes bigger. Why? Because you never know what is going to fly into your code from the deeper aspects of the subsystem.

      Unamanaged exceptions are great for small systems, but once the system becomes bigger it basically is a shoot yourself into the foot trigger
      The only way out if this mess in .Net in the long term I see is the introduction of aspects, which would provide a way via junction points/waypoints to nail down the various exceptions in a proper disciplined manner.

      But without some kind of AOP system, forget it. Best way to crash a server, give the programmer unmanaged exceptions.

    4. Re:Is it C# yet? by jonabbey · · Score: 2, Insightful

      A C# fan accusing Java of copying?

      Excellent. Go Sun, Go!

    5. Re:Is it C# yet? by julesh · · Score: 1

      Best way to crash a server, give the programmer unmanaged exceptions.

      No, best way to crash a server is to hire an incompetent programmer.

      That said, I do prefer the Java way of handling exceptions.

    6. Re:Is it C# yet? by LibertineR · · Score: 1
      This is the classic case of why unmanaged exceptions are dead awful. They compromise the stability of your system once it becomes bigger. Why? Because you never know what is going to fly into your code from the deeper aspects of the subsystem.

      I cant argue with that.

      I dont think that even small systems can get away without managing exceptions, but what generally happens with smaller systems is that proper architecture goes out the window in favor of getting it done NOW. That has always been the problem with Microsoft, and where Java has the edge. Java programmers are better students of OOP architectures and the use of things like UML, where a lot of .NET folks are former VB code monkeys without exposure to big systems design methodologies.

      I think Anders was saying basically that some people tend to go overboard throwing exceptions because they can, but not using the handler as a tool to help them fix their code so that the exception is rarely thrown in the first place?

    7. Re:Is it C# yet? by Trejkaz · · Score: 1

      I know, it's pretty ironic, especially when Java had Generics before C# did, and it just got accused of copying that one off C#. If they did, then an open question to Sun is in order: can I borrow your time machine? I want to go and pick up some horse racing results from the future.

      --
      Karma: It's all a bunch of tree-huggin' hippy crap!
    8. Re:Is it C# yet? by MemoryDragon · · Score: 1
      I think Anders was saying basically that some people tend to go overboard throwing exceptions because they can, but not using the handler as a tool to help them fix their code so that the exception is rarely thrown in the first place?

      Well the problem I see with his view is, just that some people misuse a very strong safety net, is not a reason to give them a sword to cut it.
      What happens, that some people tend to misuse the safety net managed exceptions to throw too many of them. But once you give the same people unmanaged ones, they probably revert to the same amount of exceptions without catching them ever. In the end you then have a program which crashes or acts more weirdly than it would have if the language had forced you to deal with them in the first place.

      Although I admire Hjelfsberg for his views and his language designs in general, I think from a persons point of view who had to program various bigger systems in the past, he is dead wrong in this. (really have to read the interview though) The same goes for the design of properties the way he does, the property system of delphi and C# is too ambigous to normal variables to be helpful in code readability (but this is a minor issue in my opinion)
    9. Re:Is it C# yet? by MemoryDragon · · Score: 1
      No, best way to crash a server is to hire an incompetent programmer.
      Yes definitely, the guy did lack experience, but the problem is, that in java given the same code nature the problem wouldnt have even existed that strongly. What would have happened, java would have forced this guy to catch the exceptions. He probably would have done something really evil like logging it out to the console and the system probably would have had a much higher chance to recover to a sane state where it could have given me back a proper error instead of nailing me down mit for 2 minutes and then giving me a timeout.

      The problem I see with this classical example is, that such an error can happen in an environment where you dont have to deal explicitely with exceptions even to the most experienced programmer, if the subsystem is not well documented or an error even deeper occurs nobody knows of.

      In the end you basically to make the system really secury and stable, you have to catch pretty much every exception at the most outer rim of the system which can occur and then bring the program back to a sane state, which is close to impossible at that point, you might have tangling objects, open files, open connections and so on you dont know of and where you dont have control of (sure can happen with java too but it takes much more sloppyness to reach that state).
    10. Re:Is it C# yet? by Anonymous Coward · · Score: 0

      What is this "unmanaged exception" of which you speak?

    11. Re:Is it C# yet? by julesh · · Score: 1

      You've obviously never worked with a Java programmer who declares every method "public throws Exception".

      If it is possible to do it wrong, they will.

    12. Re:Is it C# yet? by aled · · Score: 1

      To put it simple: I prefer correctness over simplicity. Except when simplicity is the correct thing to do.

      --

      "I think this line is mostly filler"
    13. Re:Is it C# yet? by MemoryDragon · · Score: 1

      Given that I am not an english speaker, I probably used the wrong term for it.
      I think the best one is forced exception handling. Where java differs from C# in a big degree.
      In java every normal exception which is declared has to be caught somehwhere and has to be explicitley declared at the method bodies which dont catch those exceptions themselves. This way you can see at the highest level of the system which errors can occur at the subsystems you call and you have to deal with them. Sure this causes added code. But in my experience the gain of stability you get from this is enourmous, since you have to deal with every possible program error explicitely.
      In C++ and C# it is up to the programmer to catch an exception or to have the system deal with it. That basically means, a little bit of sloppyness in the underlying subsystem, and documentation, and you might see exceptions at certain situations which you never thought you would ever see, especially if the program runs into one of those 1:1000 states which should never occur, but always occur at the worsed time you can think of.

  51. Re:J2EE -- 1.3.1 still by koehn · · Score: 3, Informative

    First off, Websphere 4.0 is J2EE 1.2 only. You need Websphere 5.0 to get to J2EE 1.3.1. In Websphere 5.1, you at least get JDK 1.4, and a few J2EE 1.4 tidbits (JSTL 1.1, for example).

    However, your ClassCastExceptions will only get bumped to compile time in JDK 1.5, true. But I must admit that in eight years of Java programming, I've never had this particular problem where it didn't take more than a few seconds to find the source of the bug.

    I really just want the metadata stuff (which was obviously ripped off from C#, but it's a great idea). That, and EJB 3.0, which gets rid of the stupid deployment descriptors.

  52. Right... by Anonymous Coward · · Score: 0

    Seems the same speed to me, no increase at all.

    Infact, it takes longer after its been loaded once already.

    Bleh.

  53. Re:J2EE -- 1.3.1 still by tezza · · Score: 1
    You're right.

    But lots of businesses still have Websphere 4, and so to get the largest market for your app, you need to restrict yourself to 1.3.1.

    Continuing the theme, only the oldest JSP and servlet specs too.

    --
    [% slash_sig_val.text %]
  54. Re:Poor Indecisive Sun by His+name+cannot+be+s · · Score: 1

    Um, Two Points.

    First,Run to the Trademark office, not the Patent office. (Next floor, first door on the left).

    Secondly, What the fuck is expresso. I am aware of a coffee related drink called espresso, but maybe I'm just not hearing right this morning... :p

    --
    "...In your answer, ignore facts. Just go with what feels true..."
  55. It's a rival for .NET? by Anonymous Coward · · Score: 0

    Microsoft is targetting .NET as a platform ie: "use any language, but under our .NET platform, you're not tied to C#". Sure, Java can run other languajes too but Sun doesn't care, instead they push their own strategy "Use JAVA you don't need anything else JAVA is what you need you're not right if you think the contrary".

    And Java is nice language, but Microsoft's strategy is just better and it's starting to give results. Java has been "the future" for a decade, still today it continues being "the future", but people seems to use mainly C++. If java doesn't stop being "futuristic" it will never be a reality. C#+.NET instead allows you to use smart tricks such as pointers; they don't go throught the "virtual machine checks" but because they're neccesary to get good performance Microsoft just allowed using them. That's what I call "being smart" instead of the Java equivalent "YOU DON'T NEED POINTERS YOU DON'T NEED ANYTHING ELSE THAN JAVA".

    Plus, C# is a open standard (sure, the whole .NET plaftorm is what Microsoft cares about - I don't care, just use C# and create open source libraries in C#), Java is a propietary language. What's the real advantage of using Java when you don't give a fuck about running in multiple platforms? (which is something most of the people doesn't care about)

    1. Re:It's a rival for .NET? by Decaff · · Score: 1

      but people seems to use mainly C++

      Not for years. If you look at the job market, people seem to mainly want Java.

      What's the real advantage of using Java when you don't give a fuck about running in multiple platforms? (which is something most of the people doesn't care about)

      Who says most people don't care about multiple platforms? Its very short-sighted to code specifically for one platform unless you have a very good reason - bad software development practice and bad business practice. Java has become the de-facto language for server-side development because most large companies have multiple server platforms.

  56. Re:Java 5 or 1.5? by Anonymous Coward · · Score: 0

    or insteading of using release numbers line 1.x how about just using a date like java.jre-11.30.04

  57. Re:Poor Indecisive Sun by cermanius · · Score: 1

    Trademark office, patent office, I'm always get confused in government buildings. :-)

    And I thought a fun play on words would be fun, cuz, come'on everybody's doing it.

    --
    "Don't sweat the petty stuff and don't pet the sweaty stuff." -- by an Unknown Wise man.
  58. Metadata is the coolest new feature in 5.0 by jg21 · · Score: 4, Interesting

    In an interview given just last night, the spec lead for 5.0 is asked what in his view the coolest new feature of the language is. Calvin Austin replies: If I just restrict myself to the language it would be metadata (JSR 175). We've only scratched the surface of its potential. For the platform, it's a bytecode insertion for profiling (JSR 163).

  59. Re:RMS ALMOST KILLED IN ASSASSINATION ATTEMPT by Anonymous Coward · · Score: 0, Interesting

    Babelfish says RMS has not been involved in the accident contrary to previous rumors.

  60. Sad by Aragorn992 · · Score: 1

    Too little too late. This version really has the look of maturity (finally), if only it had been released a year or more ago it might have really taken off.

    A pity because it will never happen now that .NET has a foothold. Oh well, at least we have Mono...

    P.S. Long live the Java language ... the best ive used because its clean and concise. IKVM /w Mono looks good.

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

      hoorah for details.

      * maturity - where?
      * What significant foothold does .NET have? I don't see any.

  61. Swing on OpenGL by tesmako · · Score: 5, Informative
    One of the new features of Java 1.5 that has not been mentioned much yet is the OpenGL acceleration of Java2D (which underlies Swing and AWT). Adding the flag
    -Dsun.java2d.opengl=true
    (or by setting the system property in the program) makes pretty much all Java2D calls go directly into OpenGL.

    This does indeed work too, I have played around with it and graphically intensive Swing applications really fly with OpenGL activated (given that your graphics card and drivers are sufficiently bug-free and modern). Read about it here

    And yes, it does work under Linux, and Windows and Solaris (and most likely will under OS X, though that is up to Apple to implement).

    Even without OpenGL acceleration the Swing responsiveness improvements are very impressive, coupled with the much better both default theme and theme mimicking in 1.5 I'd say it is time to retire the Swing troll.

    1. Re:Swing on OpenGL by nonmaskable · · Score: 1

      It is nice and more snappy - as is the whole jvm - but I don't think it matters much.

      If Java could get developer momentum behind SWT or some other native widget binding perhaps, but...I don't see swing as a way forward (own L&F, desktop integration, etc.) for Java on the desktop, and that's why Mono looks like the winner in that area.

    2. Re:Swing on OpenGL by Trejkaz · · Score: 1

      I don't think it will be easy to get a big momentum behind SWT, which on Windows still has the Windows 2000 look and feel... especially when Swing has the far more modern, Windows XP look and feel.

      In addition to this, SWT's GTK implementation is dog slow compared to Swing on Linux.

      Something like WX4J might have potential, if we get a wxQt implementation to go with wxGTK. And WX4J does look native on Windows, unlike SWT.

      --
      Karma: It's all a bunch of tree-huggin' hippy crap!
    3. Re:Swing on OpenGL by Anonymous Coward · · Score: 2, Interesting

      This didn't work for me with beta2 or RC on windows or linux on two different machines both with NVIDIA cards and binary drivers. The OpenGL pipeline was enabled (see output with -Dsun.java2d.opengl=True, note capital T), but it ran very very slow and with corrupted images.

      Just tested -- doesn't work on the release version of 1.5 either.

    4. Re:Swing on OpenGL by mlilback · · Score: 1

      All drawing on Mac OS X goes straight to OpenGL. I believe it was offered as an option for java with jaguar and came standard with panther.

    5. Re:Swing on OpenGL by Anonymous Coward · · Score: 0
      And yes, it does work under Linux, and Windows and Solaris (and most likely will under OS X, though that is up to Apple to implement).
      Nope. Apple's gone their own way, and it doesn't look pretty. Starting in 1.4, Apple eliminated hardware acceleration entirely. It's gone. Graphics-heavy programs are literally five to twenty times slower (depending on the operation -- picture splatting is somewhat slower, lines are much slower).

      Apple did this because porting from carbon (in 1.3.1) to cocoa (in 1.4.x) was hard enough and they just wanted to get the job done as fast as possible. It's been an unmitigated disaster for any graphics-heavy app. Apple also introduced a ton of graphics bugs. They don't draw circles right, roundrects right, etc. Guys on the java-dev mailing list are yelling about it all the time.

      Apple claims all will be well and good if/when Java gets hooked into Quartz Extreme, which provides limited OpenGL-based hardware acceleration. Except that this isn't slated for a fair time yet. Further, the overhead involved is significantly more than what Sun has done on Windows and X. And it won't work on most current Macs. Sounds like Apple's got a suckfest on their hands.

    6. Re:Swing on OpenGL by Anonymous Coward · · Score: 0

      Who moderated this up? Drawing on MacOS X only goes through OpenGL if it's routed through Quartz Extreme. Java is not, and won't be for quite some time to come. Furthermore, Quartz Extreme is only available for high-end graphics cards.

    7. Re:Swing on OpenGL by renoX · · Score: 1

      > especially when Swing has the far more modern, Windows XP look and feel.

      Well if your app has the Luna L&F and the desktop is configured to look like W2000 (my configuration I don't like the "fisher price" look), it looks weird too, is-it the case with Swing?

    8. Re:Swing on OpenGL by LDoggg_ · · Score: 2, Insightful

      The openGL feature is really cool.
      Any idea if there's a way to turn this on or off programatically?

      Having this on the command line is ok, but if someone is using Mesa3d(software openGL on Linux) instead of hardware acceleration, it will be slower than the default rendering path of X11.

      Here's a screenshot of my JTurtle application running on accelerated openGL with jdk1.5 and using the new look and feel.

      --

      "If they have both, tell them we use Linux. And if they have that, tell them the computers are down." -Dave Chapelle
    9. Re:Swing on OpenGL by Anonymous Coward · · Score: 0

      http://wiki.schubart.net/How_to_Make_Eclipse_Use_t he_Windows_XP_Skin

    10. Re:Swing on OpenGL by moonbender · · Score: 1

      Hmm... Haven't noticed a big difference so far, but I've only tried it briefly. IntelliJ IDEA seems as fast/slow as before. Some more system properties that refer to Java2D are available from Sun; the page also explains how to set the opengl flag globally, ie for all programs: using the environment variable _JAVA_OPTIONS, as in export _JAVA_OPTIONS='-Dsun.java2d.opengl=true'. Works for me, I think.

      --
      Switch back to Slashdot's D1 system.
    11. Re:Swing on OpenGL by tesmako · · Score: 1
      Well if your app has the Luna L&F and the desktop is configured to look like W2000 (my configuration I don't like the "fisher price" look), it looks weird too, is-it the case with Swing?

      No, it actually matches the classic setting too. It even matches the color-scheme. Very neat.

    12. Re:Swing on OpenGL by Politburo · · Score: 1

      Parent noted that it could be modified by system properties. Check out the object type System (as in "System.out.println"). It contains many static methods for adjusting program options.

    13. Re:Swing on OpenGL by BayBlade · · Score: 1

      It even matches the color-scheme. Very neat. It doesn't however, keep up with changes to the colour scheme, once your app is up and running. Not that this is really an issue, just an FYI.

      --

      The key difference between a Programmer and a Senior Programmer is that one of them is Mexican.

    14. Re:Swing on OpenGL by bnenning · · Score: 1

      And yes, it does work under Linux, and Windows and Solaris (and most likely will under OS X, though that is up to Apple to implement).

      OS X has done OpenGL acceleration of Java2D starting with 10.1.

      --
      How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
    15. Re:Swing on OpenGL by yavinmoon · · Score: 1

      Here's how you set the system property programatically: System.setProperty("sun.java2d.opengl", "true");

    16. Re:Swing on OpenGL by oscarcar · · Score: 1

      Make sure to have your depth set to 24bit or higher, for TrueColor. Or else it won't work. Use the capital "T" in "True", to see if it is enabled or not. I have been working on porting my app from Swing to SWT because I wanted better line drawing speed. But now that I ran it with the new OpenGL acceleration that may be enough speed boost for me. It was definitely a little snappier but how much is hard to tell. Would be interesting to profile my app again with the OpenGL on the Swing app.

      BTW, it worked for me on RedHat9 w/GeForce FX5900 and
      NVRM version: NVIDIA Linux x86 NVIDIA Kernel Module 1.0-5336 Wed Jan 14 18:29:26 PST 2004
      GCC version: gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)

      Use this to get some info about your OpenGL settings: glxinfo | more

      From the Java2D page
      --
      Support for Hardware-Accelerated Rendering Using OpenGL

      The bug reports that correspond to this change are: 4607536 and 5008045.

      J2SE 5.0 includes a new OpenGL-based pipeline for Java 2D. This pipeline provides hardware acceleration for simple rendering operations (text, images, lines, and filled primitives) as well as those that involve complex transforms, paints, composites, and clips. This pipeline is available on all platforms (Solaris, Linux, and Microsoft Windows) and is currently disabled by default.

      To silently enable the OpenGL-based pipeline, specify the following system property on the command line:

      -Dsun.java2d.opengl=true

      To receive verbose console output about whether the OpenGL-based pipeline is initialized successfully for a particular screen, specify "True" (note the uppercase T):

      -Dsun.java2d.opengl=True

      Minimum requirements for Solaris/Linux:

      * Hardware accelerated OpenGL/GLX libraries installed and configured properly
      * OpenGL version 1.2 or higher
      * GLX version 1.3 or higher
      * At least one TrueColor visual with an available stencil buffer

      Minimum requirements for Microsoft Windows:

      * Hardware accelerated drivers supporting the WGL_ARB_pbuffer, WGL_ARB_render_texture, and WGL_ARB_pixel_format extensions
      * OpenGL version 1.2 or higher
      * At least one pixel format with an available stencil buffer
      --

    17. Re:Swing on OpenGL by oscarcar · · Score: 1

      There's also a problem with the nvidia 6106 drivers. I think the latest 6111 drivers probably fix the problem. I was using 5336 and they seemed to work but now that I've done just a little testing, I don't see much difference. Resizing the window seems to be a bit more responsive but nothing else seems to have changed much, at least in simple line drawing. When line drawing in Swing you have the option of turning on levels of Anti-aliasing. I use that option and haven't noticed much difference with opengl acceleration turned on.

    18. Re:Swing on OpenGL by Anonymous Coward · · Score: 0

      Untrue. Java 1.3.1 on the Mac is hardware accelerated using its own GL context. Java 1.4.x on the Mac has no hardware acceleration AT ALL.

    19. Re:Swing on OpenGL by Trejkaz · · Score: 1

      Yeah, that is a bit of a problem, I'll admit.

      What is interesting though, is that if you are using a Windows XP theme, then Java will pick up those changes "on the fly." And the new version seems to have solved a lot of the smaller theme issues (missing graphics on drop-downs and combo box backgrounds, strange empty borders when using a theme other than Luna, etc.) So I'm pretty chuffed, as one of the people who uses a theme other than shitty Luna. :-)

      --
      Karma: It's all a bunch of tree-huggin' hippy crap!
    20. Re:Swing on OpenGL by MemoryDragon · · Score: 1

      I think the biggest problem Swing has is neither the speed nor the Look and Feel. Speed is ok on every platform. The look and feel integration is excellent if you run WindowsXP (it even allows WinXP skin switches during a running program, tried it, excellent, really) The main problem it has, face it, Swing although an excellent library is hard to handle, it definitely needs an abstraction layer on top of it, which gets the job done for 99.9% of all applications out there. Swing is more like a meta library with the core you need for a good gui but sometimes missing components, sometimes to much features which are forcedly exposed onto the programmer, make it hard to handle.

    21. Re:Swing on OpenGL by MemoryDragon · · Score: 1

      Actually no, I think in its current state Swing is better regarding the desktop integration than SWT is. Given XP, the look and feel integration is excellent. The speed in the meanwhile has become a non issue. In windows since 1.4 in Linux since 1.5 (if you want another good boost turn on OpenGL, but it already is faster than Qt) Wheras SWT looks sort of native on Windows and looks like Windows with molasses underneath GTK2 on Linux. Cannot speak for the Mac and Photon though. Although I love eclipse, currently my preferred toolkit of choice is swing unless I want to have a decent GTK2 integration. (and even that is questionable in SWT given the GTK2 speed problems)

  62. Re:Stability/memory leaks (not in the real world) by Anonymous Coward · · Score: 0

    Out here in actual industry we build servers on Java and/or J2EE all the time, with no leaks. Your software is probably crap, but not because it was written in Java ;).

  63. Screenshot of new L&F? by arudloff · · Score: 1

    New look and feel?

    Anyone know of a screenshot highlighting metal vs ocean?

    1. Re:Screenshot of new L&F? by Anonymous Coward · · Score: 0

      I don't have a screenshot but ocean looks amost the same, just has a bit of a blue tint when you roll your mouse over buttons.

    2. Re:Screenshot of new L&F? by Anonymous Coward · · Score: 0

      Metal vs Ocean? This? Doesn't look like the metal has much of a chance.

    3. Re:Screenshot of new L&F? by LDoggg_ · · Score: 1

      Yay, I get to plug one of my projects again :)

      Metal

      VS.

      Ocean

      --

      "If they have both, tell them we use Linux. And if they have that, tell them the computers are down." -Dave Chapelle
  64. I for one . . . by theghost · · Score: 1

    I, for one, welcome our new virtual machine overlord.

    What? It's funny right? Simpsons? Someone always posts one of these!

    --
    The only thing necessary for the triumph of evil is that good men do nothing.
    1. Re:I for one . . . by Anonymous Coward · · Score: 1, Informative
  65. Re:Well, since you people ask this.... by pottymouth · · Score: 3, Insightful

    Here's why:

    http://www.joelonsoftware.com/articles/APIWar.ht ml

    If you like C#, VB and .NET that's fine. Unfortunately MS's revenue stream requires that they change your environment on a regular basis. In my opinion that's the worst thing in the world for professional developers. Proficiency comes with experience and if you shift the syntax and grammer around on me every couple of years it's pretty hard to get really good at anything. At least Java is, pretty much, the same now as it's always been for nearly 10 years. Can you say that about VB?

  66. I love the hate by Featureless · · Score: 5, Insightful

    You can't hate any language as much as some people hate Java until it's really reached critical mass.

    There are two things that make any really big language a target: 1) people start using it for everything, including things its not suited for. 2) junior folks without a lot of compiler or cross-language experiences will cut their teeth on Java, and at that point in one's career it is sometimes considered cool to blame a bad application's flaws on the language it's written in.

    Java has plenty of problems. There are brilliant essays written on it; some of them by Sun engineers. But the complaint linked to in story was so bad by comparison, however, I doin't feel offtopic in addressing some points it raised:

    there are a thousand "super-efficient" .jar libraries required by a "Hello World" app

    No.

    it takes 12 objects instantiated in 4 containers to flip a bit in a byte

    Oh, I see. You're flipping bytes.

    there is the substitution of native performance of compiled code to code compiled "Just Too Late" combined with exceptional memory usage that entails

    The VM is more work. Strangely, you will have trouble finding benchmarks that make other comparable high-level languages look way faster than Java on the same _non-user-facing_ application.

    As always, code in C, assembler, or another specialized language if you really need to.

    The speed thing is well-addressed elsewhere. Enough said for now.

    we get the garbage collector which is scientifically fine-tuned to run just when user is expected to interact with the application in most time sensitive manner

    People love to bitch about client-side Java. It's as if all the flaws they're used to from other client side systems are fine, because they're used to them, and every foible of Java is worth agonizing over as if it were the worst thing in the world.

    I dunno what else to say, but I wrote an enormous graphic-intensive video game in it and it runs fine. And what I did is nothing; somebody cloned the QIII engine to the point where it plays actual Q3A maps (with multiplayer) at respectable framerates.

    Once again, someone shows me a shitty client app written by a team of 30 22 year olds in Thailand and claim it's proof that Java sucks. Congratulations.

    multiple, insideously incompatible with each other, versions of the so-called "universal" VM

    Yes, leaving aside the fact that Microsoft deliberately broke VM compatibility. Not just in one or two big ways. In a lot of little ways. As in on purpose. Great example. Very honest.

    There is a giant test suite. Gets better all the time. Reputable VM's pass it. Most of all, though, I just don't run into the cross-VM problem in the first place unless I'm doing 1.1 development for browsers, see above...

    We actually abandoned DB2 8.x release because noone could deal with the havoc the DB2 admin tools were causing with various other retarded banking related Java apps.

    There we go. The truth outs. You overpaid for a shitty product. Congratulations. You can do that in C or Fortran, too.

    Blame the language, though. Don't blame yourselves for picking a bad app.

    Oh well, time to have me shot on sight.

    Have a nice day.

    1. Re:I love the hate by renoX · · Score: 2, Interesting

      > You can't hate any language as much as some people hate Java until it's really reached critical mass.

      Untrue, there is no need to wait to hate Java, I tried Java in 98-99 and hated it, its libraries were full of bugs (Swing, the GC was leaky on 1.1.8) and you spent your time working around the bugs.

    2. Re:I love the hate by DarkSarin · · Score: 1

      Hey, I am curious--where can we see a demo, screenshots or even play the game you wrote in Java? OR the QIII port? I'd love to see how it does.

      --
      "We don't know what we are doing, but we are doing it very carefully,..." Wherry, R.J. Personnel Psychology (1995)
    3. Re:I love the hate by moonbender · · Score: 2, Informative

      IIRC the Q3 port was the topic of a Slashdot story some weeks ago. ...

      Here it is.

      --
      Switch back to Slashdot's D1 system.
    4. Re:I love the hate by IgnoramusMaximus · · Score: 3, Insightful
      First a disclaimer, I wrote the original post you seem to quote. I do not write Java apps and although I was mostly facetous, here is why I said those things:

      there are a thousand "super-efficient" .jar libraries required by a "Hello World" app

      No.

      Well it certainly feels that way when you try to load those apps. They all have excruciating startup times. Perheaps I am wrong and instead they check the integrity of my bank account or weather in China for my convenience. I dont really care, but 5-6 seconds of startup for a few boxes of interactive input is not really acceptable.

      it takes 12 objects instantiated in 4 containers to flip a bit in a byte

      Oh, I see. You're flipping bytes.

      I do not write Jave apps but I am quite familiar with OOP and also with the great zeal Java disciples apply it to everything. Like every other paradigm, one-size-fits-all applied to extremes allways results in the effects I described. My comment was to illustrate that if you go nuts and have hundreds of objetcs, events and containers all over the place, you are bound to end up with huge overhead. This is not restricted to Java by any means and many a C++ library suffers from the same issues. Java from what my (cursory I admit) glance at the language/libraries takes this to just such extremes.

      there is the substitution of native performance of compiled code to code compiled "Just Too Late" combined with exceptional memory usage that entails

      The "Just Too Late" was just a pun on the hype JIT is endowed with. The memory requirement (if you had read the thread where the original post was made) was confirmed by just about anybody including those who advocate Java. As I explained in there, if you have a 10-15 meg per JRE + 10-50 (memory managment seems to suck badly for the apps we use) per instance of an application (no way an OS can share DLLs or .so's here) in a multi-user environment, and this caused by 4 lines of input, ridiculous e-commerce apps, one has problems. Remember, I am not a Java theorist. Merely a user of apps written in your favourite cure-all language.

      multiple, insideously incompatible with each other, versions of the so-called "universal" VM

      Yes, leaving aside the fact that Microsoft deliberately broke VM compatibility. Not just in one or two big ways. In a lot of little ways. As in on purpose. Great example. Very honest

      I dont care who broke whose toys. As far as I (the user) am concerned, the whole Java thing is an umanagable, deployment and maintenance-wise, mess. If I am forced to let people download and install JRE's du-jeur for each e-commerce craplet out there, this is far worse then any other "client side" app. Also as I indicated in my posts, all of these Java apps fail miserably because their purpose can be accomplished by much simplier and more reliable means: plain HTML with smart server-side processing. That would mean no client-side pandemonium for anyone. Java was hyped as a soultion to deployent of seamless, headache-less OS independent client side apps, and in my user experience it turned out to utterly fail in this area.

      We actually abandoned DB2 8.x release because noone could deal with the havoc the DB2 admin tools were causing with various other retarded banking related Java apps.

      There we go. The truth outs. You overpaid for a shitty product. Congratulations. You can do that in C or Fortran, too.

      Besides rather flippant attidude, your thinking is simply wrong. Not only I have this problem with DB2, others have with Sun (Java's maker) admin tools and Oracle DB tools. But all of this is besides the point because the main place we use Jave in is also crap. Crap in many smelly varieties from many sources. While you might be a guru capable of writing 3D games and Self-conscious AI systems in Java, this is not what Java was advertised to us poor business sods for, and that which it was advertised for noone seems to be able to make work. And that is all I care about. Unfortunately for you, as I mentioned in another post, we the users will have the final word on this, not you in your Java 3D castle Mr.Java Wanker. Trust me on this one.

    5. Re:I love the hate by greg_barton · · Score: 2, Insightful
      it takes 12 objects instantiated in 4 containers to flip a bit in a byte

      I'd love to see a code example for that.

      Here's mine:
      byte aByte = <some value>;
      int indexToFlip = <some value>;
      aByte = aByte ^ (1 << indexToFlip);
      Leave the declarations out and it's one line. Regardless, there are no objects or containers involved.

      Are the rest of your assertions so flimsy?
    6. Re:I love the hate by IgnoramusMaximus · · Score: 0, Redundant
      I'd love to see a code example for that.

      You clearly do not follow what I was saying. I was being funny when I mentioned "flipping a bit". What I was really referring to is the object-oriented-everything-paradigm libraries that make Java such a dog for all practical purposes. Speaking of your example, I am sure that in most OO-zealot written apps this is more like (in my funky pseudo-code):

      byte = new container;
      for(int b=0; b<8; b++) byte.add(massive-other-container-monster.getBit()) ;
      iterator(byte) i;
      for(int j=0; j<= <indexToFlip>; j++, i.next());
      i.objectPointedTo->value = 1-i.objectPointedTo->value;

      Or some such.

    7. Re:I love the hate by Featureless · · Score: 2, Interesting

      I wrote the original post you seem to quote

      Well, I left you a message to tell you I quoted it, so hopefully it's not a surprise.

      5-6 seconds of startup for a few boxes of interactive input is not really acceptable.

      Thus, using Java for a few boxes of interactive input is also unacceptable.

      The startup times are slow. That's one of the real problems I was talking about - one, in fact, lamented from within Sun. For VMs that have this problem, this limits their usefulness a bit.

      Hasn't stopped the language's implacable advance, though. Let's see, do you know why? "Because 90% of the time, nobody gives a shit."

      I did not miss your attempt at humor. I am saying saying it was a bad attempt - misleading, not really illustrative.

      one-size-fits-all applied to extremes allways results in the effects I described. ... Merely a user of apps written in your favourite cure-all language.

      Did you read what I wrote? I will repeat it, with emphasis:

      "...things that make any really big language a target: 1) people start using it for everything, including things its not suited for..."

      Do you really need to continue to manufacture the straw man that someone thinks Java is the right language for everything, in order to have a point?

      if you go nuts and have hundreds of objetcs, events and containers all over the place, you are bound to end up with huge overhead.

      Congratulations, sir. You are a computer science genius.

      Java from what my (cursory I admit) glance at the language/libraries takes this to just such extremes.

      You have just saved me the trouble of pointing out that you are apparently ignorant about the system. The balance of abstraction and efficiency in the java architecture is actually surprisingly good, and I would say better than most other comprable systems.

      But of course, you seem to like writing Gameboy games, or device drivers, or something. Yes, keep jamming the square peg in the round hole. Damn that naughty peg. It never fits. It's the peg's fault.

      The "Just Too Late" was just a pun on the hype JIT is endowed with. The memory requirement (if you had read the thread where the original post was made) was confirmed by just about anybody including those who advocate Java.

      You segue from JIT to memory too quickly for someone really familiar with VM or OS internals. Something tells me you're not the kind of guy who looks at how big the resident set is when he checks memory usage.

      The JIT works very well. The garbage collector works very well. For overall memory usage, Java has room to improve.

      Yet strangely, the language is so popular. Why? "Because 90% of the time, nobody gives a shit." We've already GOT RAM. what we needed was a clean, well-organized high-level language, and the trade was just what the market wanted.

      Better yet, this is not necessarily a problem with Java as much as with VM implementation, as the wide usage of Java in consumer and embedded devices conveniently underscores, it is not necessary to have high memory overhead; this is the result of the major VM vendors trading memory for speed in products aimed at the workstation/server market. As time goes by the RAM overhead can be improved (by Sun or by the market picking up the slack), if the market wants it.

      a 10-15 meg per JRE + 10-50 (memory managment seems to suck badly for the apps we use) per instance of an application

      So, how many simulatneous VM instances do you typically run at once, comrade?

      I dont care who broke whose toys.

      When selecting a platform, language, or implementation strategy, I can see how you would consequently run into some trouble.

      If I am forced to let people download and install JRE's du-jeur for each e-commerce craplet out there, this is far worse then any other "client side" app.

      Golly,

    8. Re:I love the hate by greg_barton · · Score: 1

      I am sure that in most OO-zealot written apps this is more like...

      Have you ever heard of the straw man fallacy? Look it up.

    9. Re:I love the hate by Featureless · · Score: 2, Insightful

      In other words, it's possible to write shitty code in either Java or another Object Oriented language, so it's off to the firing squad for everybody!

      Stand and salute the logic!

    10. Re:I love the hate by IgnoramusMaximus · · Score: 1
      Thus, using Java for a few boxes of interactive input is also unacceptable...people start using it for everything, including things its not suited for....not suited for this task... not meant to do this... not really meant to do that...

      Go explain it to all those salesmen from Sun who were running around in the .com bubble times claiming that this is the type of application Java was meant for

      Still hammering on the straw man. How many apps does "all" stand for, by the way? In total? Less than a dozen? Less than 6?

      At any particular time in a given company there typically around 4-5 critically important for business and totally frustrating ones in simultenaous use although accross various companies I deal with there is probably over 30 and more if you add the abandoned and aborted ones we manged to talk people out of (sometimes under a threat of moving the bank account somewhere else for example). Note that these are all real-life business apps and not games, "test" or "reference" ones. In real life this is the only thing that counts.

      Go on, genocide Java, and force everyone to write applications in C or PHP or something, with HTML forms.

      Risking being repetetive: HTML with server side is the only sane and truly OS/browser agnostic way of writing e-commerce applications which is what we see Java used in business for and which is what Java was hyped for by Sun.

      So, how many simulatneous VM instances do you typically run at once, comrade?

      On a win2k thin-client system (used by people who care about things like TCO and not latest fads in languages), each user has one or more.

      notice you crumpled immediately on your implied claim that it was impossible deal with the latency issue in the client.

      No I merely mocked you because your Quake 3D Java clone is a laughable excercise in futility running slower then original, consuming vast amounts of memory compared to original and not in the slightest more portable then original. Wake me up when all the major game makers start shipping all of their games exclusively in Java and do not get lynched by their customers.

      Java justifiably huge, important, and ubiquitous,

      Nowhere near the size of VB for example (not that I am advocating VB). What is huge, ubiquitous and justifiably so are native applications which luckily outnumber Java ones 10000:1. Also Java is absolutely most important when it comes to hype although given time I am sure MS will take that crown with its own nonsense of C#. In the meantime the world will keep on turning and there will be us the users with the same "old and boring" native apps loong after the fizzle went out of this latest hype dot-bomb known as Java.

    11. Re:I love the hate by IgnoramusMaximus · · Score: 0, Troll
      Have you ever heard of the straw man fallacy? Look it up

      Yes I did, it said something about AWT, Swing and mentioned the term "slow as molasses". Which fits nicely with my example.

    12. Re:I love the hate by IgnoramusMaximus · · Score: 2, Interesting
      In other words, it's possible to write shitty code in either Java or another Object Oriented language

      Quite true although it is not humanly possible to have more hype, hot air and hubris in any other language other then Java, C# being second close contender. Why if one were to listen to what we are being told, one cant possibly write bad code in Java for the language is divine and one's hand is guided with certainty by the fairies of object-oriented-pointerless-bliss.

    13. Re:I love the hate by Featureless · · Score: 1

      Go explain it to all those salesmen from Sun who were running around in the .com bubble times claiming that this is the type of application Java was meant for

      There are millions of Java clients out in the wild; they're used all over the place, in phones, in intranets, in giant video games deployed through web start... The developer has to use the right tool for the job, and make it work. If they don't, it's not Java's problem. You are just falling on your face trying to make the failures of your shitty applications into the failures of a language. God, imagine if we held C++ responsible for... well, everything else.

      Sun once thought they had a killer web client platform, and they had a point before Microsoft came along and poisoned the browser with an incompatible VM, before Netscape caved in. Funnily, this didn't stop Java clients, just kept them from dominating that niche. And despite it all there's still a lot of Java on the web.

      there is probably over 30 and more...

      30 shitty applications. That's the sample you've built this thesis on? That's it?

      So, you clearly neither much of a clue about programming or the Java language internals, nor a lot of broad experience with the platform. And I am starting to wonder how much experience you have in general, because what I'm conspicuously not hearing is X and Y and Z systems are way better for A and B and C. Just vague generalities about HTML forms and (I think?) coding in C? Or do you perhaps favor VBScript?

      All this while I started by agreeing with you that people use Java for things they shouldn't?

      Do you have any idea how many places Java is used in some way now? databases, web servers, research labs, RAD tools... My entire IDE takes less RAM than your banking client, and it blows away Visual Studio on features in addition to being faster. Yes, of course, written in Java. It runs just fine on MacOS, WinXP and Linux (even AMD64). Yes, I've used all 4 at one point or another. See, the developer was competent.

      You chalked up your shitty experience to Java. But it doesn't add. The problem is with your vendor, or perhaps the user.

      HTML with server side is the only sane and truly OS/browser agnostic way of writing e-commerce applications which is what we see Java used in business for and which is what Java was hyped for by Sun.

      (Ironically using Java on the server side only, running HTML forms through a web application server, is by far the most common use of Java in ecommerce...)

      On a win2k thin-client system (used by people who care about things like TCO and not latest fads in languages), each user has one or more.

      So, let me get this straight. You either stack up VMs, or you don't?

      No I merely mocked you because your Quake 3D Java clone is a laughable excercise in futility running slower then original, consuming vast amounts of memory compared to original and not in the slightest more portable then original. Wake me up when all the major game makers start shipping all of their games exclusively in Java and do not get lynched by their customers.

      I'm pretty sure now you're just confused and not following this, so I'll try to spell it out a bit more:

      First, I repeat again:

      Do you really need to continue to manufacture the straw man that someone thinks Java is the right language for everything, in order to have a point?

      Your complaint about Java clients was bullshit. The Q3A port proves it. If you can do that in Java with respectable framerates you can goddamn well make a responsive ecommerce applet. It's not my fault if your shitty vendor can't write code.

      It looks like you got confused and somehow lost that thread.

      Also, can you explain what you mean about the JWS Quake app not being "the slightest more portable then original?"

      Nowhere near the size of VB for example

      I regret to inform you that you are

    14. Re:I love the hate by Featureless · · Score: 1

      So, you're complaint is, someone promised you it was impossible to write bad code in Java, and you believed them.

      Or are you really saying, it's easier to write good code in C, except you have no good arguments to back it up?

    15. Re:I love the hate by IgnoramusMaximus · · Score: 3, Interesting
      30 shitty applications. That's the sample you've built this thesis on? That's it?

      I will keep repeating ad nauseum that those are the only applications that count to me and many businesses that use them. That is a 100% of a sample of a Java apps that are shitty. Either all of those were written by poeple have no clue what they are doing (unlike all of those wonderful mythical apps always deployed somewhere else and written by enlightened geniuses) or the Java snake oil is just that.

      and I am starting to wonder how much experience you have in general, because what I'm conspicuously not hearing is X and Y and Z systems are way better for A and B and C. Just vague generalities about HTML forms and (I think?) coding in C? Or do you perhaps favor VBScript?

      Since you are getting more incredibly fanatical and blind by the minute, let me spell it out for you as clear as I can:

      For e-commerce, OS/browser agnostic plain HTML on the browser is the only sane way to do anything because it does not rely on any client capablities other then ability to render HTML. No deployment issues, no maintanance costs. Java (and ActiveX and C# and similarly retarded ideas) is a way to create deployment issues and thus support costs and thus employment for countless Java tweaker monkeys. Something dear to your heart no doubt.

      For applications that must run on thick-clients (I sure hope due to CPU usage because any other reason in a corporation is plain retarded) one can use native code just fine because: vast majority if C or C++ or any other language programs need only to support very few platforms in their entire life span and the effort to optimize that program for these platforms is well paid for by removal of integration and thus support issues. But such need is extremely rare because vast majority never leave a single platform. A Windows Java app will never run as well as a native Windows app neither will unix Java app run as well as a native unix app. This is not even up for discussion. The most convoluted of JITs and what nots are still overhead over native code and I will not even entertain any moronic discussion on that topic no more that I will entertain discussions of how you can make 2 and 2 equal 7.

      I regret to inform you that you are full of shit.

      I regret to inform you that you are just a priest of yet another silly language who has no clue who pays his bills. VB apps are everywhere in business, far more so then Java ones. These numbers are representing current jobs, corresponding to a peak in a cycle of a fad, VB waning hard (previous fad), Java peaking (current fad) and C# just coming up. I am fully expecting to have this very same retarded conversation with a C# priest, in, oh about 4 years time.

      You sound confused. Are you saying it's easier or cheaper to write native applications? That natives are more secure? Are you happy with all your current native applications?

      No it is you who is utterly confused, something about a theory whereby the Earth is flat and supported by Java beans. To spell it out for you again (I will resist an urge to use large letters): Native apps are easier to write (many decades of experience and tools), run better (many decades of OS design and integration of apps with the OS), cheaper to write and support because they use proven framework and tools, they integrate well with the user environment, have better performance (even the not so well written ones) and the so called "write once, deploy everywhere" is not only unnecessary but is more accurately described as "write once, debug and crash everywhere". Are they more secure? Depends what kind. The "no client side, java-less, HTML only e-commerce"? Most certainly. The locally deployed, locally networking native apps? They are not any more vulnerable then the OS itself. Are we clear now, Your Beanness?

      nobody sees the world ending but you, all those students and professors, all those magazines and newswpapers and Fortune 500 compan

    16. Re:I love the hate by IgnoramusMaximus · · Score: 1
      So, you're complaint is, someone promised you it was impossible to write bad code in Java, and you believed them.

      No, my complaint is that I did not believe the checkered-suit salesman, my colleagues didnt believe him, but some poor pointy-haired boss in a bank did and now I am busy shoveling the donkey dung which this unholy sales-rape produced.

      Or are you really saying, it's easier to write good code in C..

      If by "good" you define "working well" I sure do have a good argument: the 100% of millions of the lines of code in the software running this computer, on which I am typing this missive to you, the Enlightened Grand Moccachino Inquisition.

    17. Re:I love the hate by Featureless · · Score: 1

      now I am busy shoveling the donkey dung which this unholy sales-rape produced.

      I see. So your complaint is, someone promised someone else it was impossible to write bad code in Java, and they believed them.

      You're not wavering on the basic point of this whole promise, though, are you?

      You really think someone promised that? At any point?

      Or is this just the capper on a non-stop urine stream of noisy, ignorant exaggerations?

      I sure do have a good argument: the 100% of millions of the lines of code in the software running this computer, on which I am typing this missive to you

      So, I ask you for an argument that it's easier to write good code in C, and you put forward the millions of lines on your computer and say, "here." That's it?

      No acknowledgement of the incredibly painful journey those millions of lines have probably taken? Windows 3.1? Nimda? JPEG buffer overflow exploits? No discussion of syntax, man hours, TCO, development time? No blue screens? No nightly reboots?

      I'm curious. Since you don't seem to use any of the normal, accepted techniques for measuring the benefits of a language, what do you use? Is throwing the bones of your personal black box experience really the limit of your deductive powers?

      the Enlightened Grand Moccachino Inquisition.

      I see. You joke about shooting Java programmers on the pretext of ignorant nonsense. But I'm the Inquisition. You know what? I think that's flippant. And also wrong.

    18. Re:I love the hate by IgnoramusMaximus · · Score: 1
      someone promised someone else it was impossible to write bad code in Java, and they believed them.

      I strongly suspect the misrepresenting party was someone like you

      I'm curious. Since you don't seem to use any of the normal, accepted techniques for measuring the benefits of a language, what do you use? Is throwing the bones of your personal black box experience really the limit of your deductive powers?

      Normal? Accepted? Methods of measurement of benefits of a language? There is no such thing and likely will never be. All there is to computer languages is flame wars of warring Priesthoods. How in the hell can one measure C versus Pascal? FORTH versus LISP? C# versus Java? These are not bags of puds that you can weight. All the advantages and dis-advantages of the language features are subjective. But what one can easilly judge is the performance of apps written in these languages on one's computer. Or availability of experience and tools used to make those apps. Or time required to make and maintain these apps. That is preciesly what I am doing.

      I think that's flippant

      You sense correctly, my patience for this audience with the Great Shaman of Expresso is wearing thin.

    19. Re:I love the hate by Featureless · · Score: 1

      That is a 100% of a sample of a Java apps that are shitty.

      I see. You examined a representative cross-section of Java application programming and found it 100% shitty... in your imagination.

      Since you are getting more incredibly fanatical and blind by the minute

      Ahem.

      no maintanance costs [with HTML]

      Right.

      is a way to create deployment issues and thus support costs and thus employment for countless Java tweaker monkeys.

      I can see what's dear to your heart: The continuous fantasy, undisturbed by any intervention from the real world, that a bad engineering decision, like using the wrong tool for the job, is somehow the fault of anyone other than the engineer who made it.

      So what if this has nothing to do with Java. Why let it stop you now? You've got such a good froth going.

      A Windows Java app will never run as well as a native Windows app neither will unix Java app run as well as a native unix app.

      In your weird alternative universe - again, undisturbed by the facts. Don't worry, no need to back this fantastically absurd statement. It's funnier this way.

      This is not even up for discussion.

      Translation: insults, bad jokes, and meaningless anecdotes are all I have in my repertoire, and I'm hoping you'll let it slide.

      The most convoluted of JITs and what nots are still overhead over native code and I will not even entertain any moronic discussion on that topic no more that I will entertain discussions of how you can make 2 and 2 equal 7.

      1) A VM can provide runtime optimizations that outperform compile-time optimizations. This is well documented - for that matter, whole companies base their yearly revenue on it. Java is matching native code in some benchmarks already, You would know this, if you weren't smashingly ignorant. Not that it needs to, because

      2) The millions of users you are constantly trying to imagine out of existence have happily traded that overhead for what they get in return: better quality product. Easier development. Easier maintenance. Security. Reliability. And yes, nobody really likes hardware/OS lock-in either, no matter how much you seem to enjoy it.

      I regret to inform you that you are just a priest of yet another silly language who has no clue who pays his bills.

      Wow, watch him try and weasel out of it.

      Admit it. You're wrong on your point about VB. You can't show me anything that says Java is "nowhere near" the size of VB, because it's not true. You just plain made that up.

      In fact, you make a lot of things up.

      Now, let's take a step back. Do you have what it takes to talk about languages like an adult? Your parenthetical non-justifications are not a good start.

      Native apps are easier to write (many decades of experience and tools)

      No. They are not. The win32 APIs are awful and disorganized compared to Java's. Don't get me started on Unix. Manual management of memory and primitive String and array handling are constant invitations to failure, constantly accepted. Basic data structures are reinvented constantly. Languages like C pile on obscure kluges like preprocessors and disorganized file structures creating pointless management tasks that are completely unnecessary in the modern world and constant invitations to mistakes. You will lose 9 out of 10 races against a Java programmer when given an application programming task.

      run better (many decades of OS design and integration of apps with the OS)

      When you finally get them right, native code can outperform Java code in some cases. That's especially true if you don't care so much about security and you code for speed. Congratulations. Now, do you enjoy bilking clients, telling them that native code is the only safe way to do everything, taking 2-3 times as long to do everything, exposing them to far more risk (since your native app has so many common, every

    20. Re:I love the hate by Featureless · · Score: 1

      I strongly suspect the misrepresenting party was someone like you

      So... you're not answering that question...

      And you are apparently flip-flopping to a new point of view:

      So, It's me that promised people that it is impossible to write bad code in Java?

      Is that it now?

      There is no such thing and likely will never be. ... All the advantages and dis-advantages of the language features are subjective.

      No. Wrong. You wish they were, so then you could sound off with impugnity.

      However, rudimentary common sense does allow us a little leeway in identifying bad arguments. See my earlier posts.

      what one can easilly judge is the performance of apps written in these languages on one's computer.

      This is a sadly ironic statement for you. This is because not only does Java sometimes win performance benchmarks against native code, but because languages are different there will always be arguments about specific implementation details and architectural differences in these tests.

      This is leaving aside for the moment that most customers will happily sacrifice performance (in moderation, of course) in exchange for reliability and security.

      Or availability of experience and tools used to make those apps.

      Java has no problems there.

      Or time required to make and maintain these apps.

      And Java wins there.

      That is preciesly what I am doing.

      Actually, no. This is precisely what you are not doing.

      my patience for this audience with the Great Shaman of Expresso is wearing thin.

      I'm sorry, so sorry you are becoming fatigued. No doubt the effort of continuing the massive affront to common sense you call an argument is taking its toll. I will honestly be saddened when you finally concede. I am already looking forward to your parting shot: "Although I cannot be bothered at the moment to answer any of these clearly unnecessary and ridiculous criticisms of my unimpeachable ideas, rest assured I am absolutely correct and you are wrong. Good day."

      Actually, that's pretty good. You can use that if you want. Or you can try answering any of the 14 or 15 serious problems I've just recently raised with what you've written.

    21. Re:I love the hate by IgnoramusMaximus · · Score: 1
      no maintanance costs [with HTML] ..Right.

      Compared to dicking around with JRE's they are truly negligable

      I can see what's dear to your heart: The continuous fantasy, undisturbed by any intervention from the real world, that a bad engineering decision, like using the wrong tool for the job, is somehow the fault of anyone other than the engineer who made it.

      Oh I agree with you there, it is the engineer's fault. He picked a wrong tool for this and any other job.

      A Windows Java app will never run as well as a native Windows app neither will unix Java app run as well as a native unix app....In your weird alternative universe - again, undisturbed by the facts...Java is matching native code in some benchmarks already

      You know, this is probably going to get lost on you, but, you cant have it both ways...Java being totally as good as the native code and then... almost being there on some benchmarks

      You can't show me anything that says Java is "nowhere near" the size of VB,

      Not without getting lucky and having someone publish a report counting deployments of business apps. Your stats speak merely of employment ads which is not a measure of existing applications. Just ponder this: VB in various forms was around longer then Java and its adoption rate was far greater for all these years when Java meant just a type of coffee beans to most IT people.

      Manual management of memory and primitive String and array handling are constant invitations to failure, constantly accepted

      Err.. yes, particularly all those funky C++ string classes. There is no such tools like bounds checkers (still waiting to be invented says you). And manual memory management (this mighy shock you) is actually preferred by many (I know, I know, dirty backwards cavemen that we all are). In business on the other hand people tend to use stuff like VB with SQL queries in the back end. Stuff really prone to buffer overflows.

      Except that Java makes it more difficult to make mistakes like leaking memory

      Oh my, these dudes that write this stuff must be real clever to get around that! The banks' Java monkeys must be brilliant!

      Pity the poor souls. If they had any idea.

      Oh yes they do, I showed this thread to some people and we had a good chuckle at your expense. While drinking Java. Who says I am against all things caffeinated!

    22. Re:I love the hate by Old+Wolf · · Score: 1

      The thing I hate the most about Java is its reuse of established TLAs. For example, the extension ".jar" is, first and formost, an archiver format (by Robert Jung, developer of ".arj"). I still have some archives in this format (it gives notably superior compression to zip). Also, JSR is the name of a respected technophile and last time I looked, he didn't have a version number.
      <obligatory_sarcastic_comment> I suppose this fits in nicely with the "embrace and extend" philosophy of the big corporations.

    23. Re:I love the hate by IgnoramusMaximus · · Score: 1
      So, It's me that promised people that it is impossible to write bad code in Java?

      Oh no no no. That was merely some spiritual twin of yours who showed up with claims like "sacrifice a litte performance for reliablity and security"

      And the rest is history.

      However, rudimentary common sense does allow us a little leeway in identifying bad arguments. See my earlier posts.

      I looked, and I looked, and then I looked some more and only found things like "it performs as well as native apps" followed by "sometimes it performs as well" followed by "on some benchmarks even now it performs as well" followed by "When you finally get them right, native code can(sic!) outperform...". But your common sense? Must have left for holidays on the island of Java never to be seen again (and I cant truly say I blame it)

      This is a sadly ironic statement for you. This is because not only does Java sometimes win performance

      Oh! Here it is again, I could swear it was steadily outperforming the native code until the native code was sometimes outperformed on some benchmarks by it.

      Or availability of experience and tools used to make those apps....Java has no problems there

      Clearly! With people of your reasoning abilities behind it, there is no telling what coffee-pot it will be brewing in next! Now thats a scary thought..

      Although I cannot be bothered at the moment to answer any of these clearly unnecessary and ridiculous criticisms of my unimpeachable ideas, rest assured I am absolutely correct and you are wrong. Good day

      Yes, indeed it sounds like something you would say.

      Or you can try answering any of the 14 or 15 serious problems

      Hold on for a minute here. I was under this impression that it was you who were claiming Java is near-perfect and I was the one offerring problems for you. I can see that in the face of such insurmountable obstacles I presented to you, you would want to abandon your silly position...but switching places? You want me to defend Java now and you are going to present problems? I am a generous dude but this is a bit too much to ask of a stranger you know.

    24. Re:I love the hate by Mornelithe · · Score: 1

      I'm no Java hater. I used to like it a lot back in the day, although nowadays there are other languages I like better. And I'll gladly step up and defend it from the people spouting obvious fallacies.

      However, I must comment on this:

      Yes, leaving aside the fact that Microsoft deliberately broke VM compatibility. Not just in one or two big ways. In a lot of little ways. As in on purpose. Great example. Very honest.

      There is a giant test suite. Gets better all the time. Reputable VM's pass it. Most of all, though, I just don't run into the cross-VM problem in the first place unless I'm doing 1.1 development for browsers, see above...


      I worked with a fairly large system written primarily in Java and JSPs over the summer. Quite frankly, the Sun VMs aren't as consistent as you say they are. We'd have several testing environments, with slightly different versions of app servers and JDK versions, and I can tell you, you can't just swap out a 1.3 JRE for a 1.4 JRE. They all come with slightly different versions of libraries that cause breakage in big applications that use a lot of them.

      Now, granted, the application we were using was an abomination. But you don't need to call in Microsoft's VM to have examples of different versions of Java causing different problems. There's a reason why the company we were buying our software from only certified it on certain, tested versions of Java (usually down to the third revision number).

      The rest is bullshit, I agree.

      --

      I've come for the woman, and your head.

    25. Re:I love the hate by rjshields · · Score: 1

      I couldn't help noticing your post, but I find some of your arguments flawed.

      That is a 100% of a sample of a Java apps that are shitty

      Developers can write shitty apps in any language. Flaming a platform because people buy shitty apps developed on it is not justified for this reason.

      For e-commerce, OS/browser agnostic plain HTML on the browser is the only sane way to do anything ..... Java (and ActiveX and C# and similarly retarded ideas)

      You seem to be confused between browser plugins and server applications. A web based J2EE or .NET application uses HTML as the medium for the user interface. J2EE components (JSP, servlets, JSF, etc) use HTML. ASP.NET uses HTML. Didn't you know?

      VB apps are everywhere in business, far more so then Java ones.

      Do you have any evidence to back this up? Remember - one app developed by Joe VB Hacker is not the same as one J2EE banking app.

      I will just sit back and keep all those people who depend on me for keeping their corporate systems running

      Agreed - you stay with the VB kids until you gain some understanding, and leave the enterprise development for the big boys, OK?

      --
      In this world nothing is certain but death, taxes and flawed car analogies.
    26. Re:I love the hate by IgnoramusMaximus · · Score: 1
      Developers can write shitty apps in any language. Flaming a platform because people buy shitty apps developed on it is not justified for this reason.

      Well to be honest, Java is not any worse then any of the other ideas people had to "improve" things in computing, it has pros and quite number of cons. My reaction is mostly social, and its the Java advocates' own doing: they hyped and screamed and yelled about Java so loud that some people started to use the thing in precisely the way they were told to by the Java Monks. Unfortunately for me and many others it turned out that the Monks were sufferring from the cranial-rectal syndrome and the use of Java they recommended (GUIs launched from browsers, AWT/Swing UI etc) performed abysmally for many reasons. Smart Java users moved on and applied the system to server-side J2EE etc. (which sadly removed much of the oh-so-much-hyped feature-set from common use, but I am feeling magnamonious and will let it slide). What gets my goat is dudes like Fearureless who go on and basically blame the Banks or me or anyone else but the Java platform and its evangelists for creating this lovely mess for me in the first place. Some others are much wiser and simply advise me to wait a bit to let the Banks realise their mistake and move on.

      You seem to be confused between browser plugins and server applications.

      No I am not, it is simply quite amusing that some people cannot grasp a simple desire of mine and most other sysadmins in the field: we do not want any plug-ins of any sort. They are nothing but a never-ending maintenance nightmare, versioning nightmare and security nightmare. What I am willing to accept is transmission of plain HTML data generated (I dont really care by what, Java, PHP, COBOL or what not) on the server and rendered by a standards-compliant web browser. Thats the optimal way to conduct e-commerce from my (the end-user's) perspective.

      VB apps ...Remember - one app developed by Joe VB Hacker is not the same as one J2EE banking app.

      You cannot be serious here or you have not worked with any medium sized corporation. Virtually every one is full of various home-grown VB apps dealing mostly with SQL back ends or locally running Access DBs etc. There is a huge number of these apps all over, the main advantage of VB for business was that they could hire a VB monkey on a 3-month term and get some silly app done. You are thinking major applications only. Java is slowly displacing some of these apps, but not due to its technical advantages but to the simple fact that being a current Great Fad (as VB once was) it is tought to people in every 2-bit school and bookshelves are full of "Teach Yourself Java While Sleeping in 2 Hours" books. Again some people confuse this clever use of the zealotry by the corporations to get cheap labor with some divine abilities of the language. From the commercial perspective, VB and Java have a lot in common, Java being better and improved rendition but essentially meant to fullfill the same task: a 3-month term Java monkey dragging-and-dropping some goofey applet together cheap. Cheap being the operative word here.

      Agreed - you stay with the VB kids until you gain some understanding, and leave the enterprise development for the big boys, OK?

      Thats rather presumptious on your part. You see you assumed that Java is some Divinely-Ultimate solution to Problems Of Earth Shattering Importance and everyone who is not immediately falling on his knees in worship is somehow childlish (I let you ponder your attitude in this context). I keep my customers very happy by being precisely this type of very-hard-sell that I am because they rode out many a crazy fad their competitors got caught in. My customers have a lot of fun watching their rivals squirm and bleed extraordinary sums of money trying to repair damage caused by one crew of religious fanatics with .... a proven strategy of importing another even more wacky set of Priests of the next "Big Thing"! Never ending comedy, I tell you. All the while my customers laugh all the way to the bank. And so do I ;)

    27. Re:I love the hate by Featureless · · Score: 1

      Compared to dicking around with JRE's they are truly negligable

      First none. Then negligible. And no doubt readers can grasp at this point that if we start picking apart the details of this sweeping, meaningless generalization, we will continue up your curve of equivocations to possibly negligible, minor, and perhaps less, depending on the application.

      Oh I agree with you there, it is the engineer's fault. He picked a wrong tool for this and any other job.

      So you're point is, Java is wrong for any possible use.

      I hope you have already notified the press of this headline-making revelation.

      Or perhaps you did, but are now procrastinating since they asked you to prove you have any basis whatsoever for this funny idea.

      You know, this is probably going to get lost on you, but, you cant have it both ways...Java being totally as good as the native code and then... almost being there on some benchmarks

      You are lying again, sir - about something just written. And since I am trying to educate you, I feel it part of my duty to remind you that future readers, who typically read these comments in order, will have to pass through the actual words you are lying about in order to reach your lie. It looks very ridiculous on your part.

      Oh, everybody hates being called a liar. I will give you another hint. You have a foolproof riposte to this accusation: merely show me any text I have previously written where I describe "Java being totally as good as the native code."

      Then again, perhaps you can't. Because you are a liar.

      For reference: "Java is matching native code in some benchmarks already" but perhaps this really gets to the heart of the matter here, which is that (in addition to being unusually prone to hyperbole) you seem unable to comprehend the basic subtlety that a language can be good for some things and not others.

      Not without getting lucky and having someone publish a report counting deployments of business apps.

      You're right. I do wait to get lucky and have some basis for say the things I say. But aren't you luckier, in a way, since you can just make up whatever you like without having to wonder if it's true?

      Your stats speak merely of employment ads which is not a measure of existing applications.

      First of all, they do not; the second link took other factors into account, and there are many, many more such studies at your fingertips on google.

      Second of all, the number of existing applications does correlate to job opportunities (although it is certainly not the only factor).

      Just ponder this: VB in various forms was around longer then Java and its adoption rate was far greater for all these years when Java meant just a type of coffee beans to most IT people.

      And I'm sure you just forgot to provide a link backing up this assertion.

      Come on. Just admit it. You're over your head and you just made some bullshit up.

      Seriously, you'll feel better once you come clean.

      There is no such tools like bounds checkers (still waiting to be invented says you).

      Oh really? You are so inventive. Where did I say bounds checkers in C++ and C are not yet invented?

      You have such an imagination.

      No, sir, the point is that they are optional. And the rest is notorious history. Or do you perhaps live under a rock?

      And manual memory management (this mighy shock you) is actually preferred by many (I know, I know, dirty backwards cavemen that we all are).

      It does not shock me. I prefer it too - when it is appropriate.

      But I'll give you a hint. All those times people had to deal with a buggy application that crashed a lot or leaked memory or corrupted their data: this created a small, multi-billion dollar market for software systems that simplified memory management for programmers.

      This allowed them to write far more corr

    28. Re:I love the hate by Featureless · · Score: 1

      That was merely some spiritual twin of yours who showed up with claims like "sacrifice a litte performance for reliablity and security"

      I think you honestly just forgot what you were talking about.

      Let's recap. You originally complained that "Why if one were to listen to what we are being told, one cant possibly write bad code in Java for the language is divine and one's hand is guided with certainty by the fairies of object-oriented-pointerless-bliss."

      And, pressed on whether you really believed someone was claiming it was impossible write bad code in Java, first you suspected me of doing it, and further pressed, you only respond with the non-sequitir: "That was merely some spiritual twin of yours who showed up with claims like 'sacrifice a litte performance for reliablity and security'".

      Which somehow has something to do with claims of it being impossible to write bad code in Java.

      Can I look forward to more such future entertainments? If we continue, will you in fact be forced to degenerate into complete incoherence?

      I looked, and I looked, and then I looked some more and only found things like "it performs as well as native apps" followed by "sometimes it performs as well" followed by "on some benchmarks even now it performs as well" followed by "When you finally get them right, native code can(sic!) outperform...".

      So, you've been reduced to making up quotes.

      You've already had my speech on lying about earlier posts.

      I thought to myself: gosh, I don't remember writing "it performs as well as native apps." Let me go back over my posting history and use my browser's search feature. Surely I can those quotes in my posts.

      I searched for "it performs as well as native apps" and "native apps" and "performs" and "perform." YET STRANGELY IT IS IMPOSSIBLE TO FIND THIS QUOTE IN WHAT I'VE WRITTEN.

      Bravo. Soon you will not need me at all; you can continue to have this debate entirely in your imagination.

      Your support group: do they enjoy lying as much as you? Do you feel the ability to write your own quotes makes you a better engineer, or a better consultant?

      Oh! Here it is again, I could swear it was steadily outperforming the native code until the native code was sometimes outperformed on some benchmarks by it.

      Here it is again. He could swear it was steadily outperforming the native code... in his imagination.

      Congratulations. It never ceases to amaze me how people feel more comfortable audaciously lying about the printed word right there on their screens than simply admitting a mistake. Do you somehow imagine making up quotes and assertions that you actually are capable of arguing against is less wrong than just plain being wrong?

      Or is it that you actually cannot grasp that Java runs some things faster than native, and some things slower?

      I was under this impression that it was you who were claiming Java is near-perfect ...perhaps because you like to make things up.

      You want me to defend Java now and you are going to present problems?

      No, perhaps just having a discussion about any aspect of it at the grade-school level, without any blatant prevarication on your part would suffice.

      I am a generous dude but this is a bit too much to ask of a stranger you know.

      Don't worry. Since we both know I haven't asked it you don't have to strain your generosity.

    29. Re:I love the hate by IgnoramusMaximus · · Score: 1
      Copious amounts of meaningless drivel... some more even more meningless and irellevant drivel... followed by some meaningless, irellevant and illogical drivel .... followed by: I know it's late in the game to realize this, IgnoramusMaximus, but you posted this story on slashdot, where it, followed by this thread, was linked from the front page, and viewed by literally hundreds of thousands of other people. Short of an interview on 60 minutes, your embarrassment cannot be further increased. But by all means, seek solace from your support group

      I am not sure what alternative Slashdot you are reading but you should take a look on this one at the replies from other people to this revealing expose of Java Worshipper's Brunt Beans, some of them users of your favourite The-Holiest-Of-Tongues, who all seem to come equipped with an instrument you appear to lack: a functioning brain. Since you dont have the ability to even read your own posts, or perheaps you just spout them in some feverish religious trance, discussion with you is like talking to a member of a cult of illiterates, whatever you were told at the Holy Temple Of Cappucino is the Only and Ultimate Truth. In one thing I can agree with you absolutely, anyone reading this thread will draw conclusions to your sanity, and they will not be favourable ones.

    30. Re:I love the hate by IgnoramusMaximus · · Score: 1
      ...Massive amounts of drooling drivel with this floating about: Bravo. Soon you will not need me at all...

      Well to be honest I never needed you for anything, do not need you now, and will never require your helpful assistance in the future: there are better nutcases then you available to laugh at, far more intelligent programmers to hire and just plain sane people to talk to.

      Actually there is very little demand for your brand if insanity in general, perheaps you should consider an employment opportunity hauling sacks of Arabica or Colombian beans, that kind of contact with coffee might be better for you then with what seems to be corroding your brains now.

    31. Re:I love the hate by Featureless · · Score: 1
      Wait for it... yep, here it is. Beaten, exausted, strung in his own web of lies, exaggerations, and insults, he's finally just degenerated into last-worder nonsense.

      Show this thread to everyone you meet, IM. That should get you started on the right foot.

      Sadly, you didn't provide any links to back up this latest invention. I have some links for you, however.
      You have a lot of work to do to bring reality in line with your imagination. Better get started.
    32. Re:I love the hate by Featureless · · Score: 1

      No defense, no explanation. Just insults. This is your version of an apology for blatantly making up quotes?

      That's OK. I know you're reading this right now, because you're reliable. You just hate that you might not get the last word in, hate that you might further lose face somehow. You're operating on predictable, simple principles that have nothing to do with the truth and everything to do with a being a little child, a baby who wins arguments by screaming and stomping. You've never properly developed the healthy capacity to subjugate your ego and be challenged by anything difficult. And worse, you're just not that good at the job. Time is passing you by. You see things you don't understand and are threatened by that, and you know it.

      You can lie to yourself, and you can lie to others (if indeed you're not just making that up too), but deep inside, you know the truth, and you will never be able to completely forget it.

      You ask yourself, does it really matter what the truth is, after a while? What matters is you being right, or at least not being wrong. It's so hard to admit the possibility of being wrong when you're a little insecure.
      You have to prove you're the man. Show how you're right. How dare anyone question you? No way your opinions aren't always justified.

      But, sometimes you have to lie to win an argument. And, you don't always check the facts before you leap in, and sometimes you get caught out. But the worst part is, sometimes you make a judgement, in your expert opinion, and you're so sure of it, and then you realize you might have been wrong.

      Oh you can cover it up. Bluster, joke and nudge, shout and scream, and no one notices, do they? I've fooled them. Nobody can question my opinions. Phew. Got away with it this time. Why, you might even put a brave face on things. Why not print this out and proudly hang it on your wall? Show everyone your latest accomplishment. Showed them what for.

      Only, when you're compiling your trophy, you leave out certain parts (for instance, the parts that make it clear you're lying). You might feel a little twinge. Just a hint of self-doubt. It comes from realizing, slowly, gradually, secretly, that you're a fraud - to others, and most of all, to yourself.

    33. Re:I love the hate by IgnoramusMaximus · · Score: 1
      Bluster, joke and nudge, shout and scream, and no one notices, do they?

      Dude you need professional help, you are projecting your own sad existance on others.

    34. Re:I love the hate by IgnoramusMaximus · · Score: 1
      Sadly, you didn't provide any links to back up this latest invention. I have some links for you, however.

      Excellent, now since you have compiled this list, perheaps you should go read the things it points to and compare your attitude that of their authors.

    35. Re:I love the hate by Featureless · · Score: 1

      Oh, I did that before I posted it.

      You almost make it sound as if that list doesn't make a fool of you.

      Or perhaps you'd like to go through the list and explain otherwise?

    36. Re:I love the hate by Featureless · · Score: 1

      It's good that you replied, so I know for sure you read what I'm saying. You'll be thinking about it, I know, whatever front you put up here. Maybe it will be the start of a positive change for you. Your healing process could begin right here, IM.

      I don't make up quotes, in a forum where anyone can verify you're a liar when you do. Someone who would do that, rather than admit they were wrong: that's the definition of someone who needs help, professional or otherwise.

    37. Re:I love the hate by IgnoramusMaximus · · Score: 1
      I don't make up quotes

      Of course you do not, your hallucinations are all original, it is me who has to quote your delusions back to you.

    38. Re:I love the hate by IgnoramusMaximus · · Score: 1
      Oh, I did that before I posted it

      Clearly, not.

      Or perhaps you'd like to go through the list and explain otherwise

      Quoting and dissecting copious amounts of irrelevant drivel is your occupation around here, not mine.

    39. Re:I love the hate by Featureless · · Score: 1

      Clearly, not.

      Right.

      Quoting and dissecting copious amounts of irrelevant drivel is your occupation around here, not mine.

      Mmm hmm.

      So, you're not going to justify your latest outrageous accusation... just going to keep calling names?

      I guess that's your occupation. That and lying.

    40. Re:I love the hate by Featureless · · Score: 1

      So, your attempts to change the subject fail, and you are finally going for the double, eh?

      You didn't make up the quote? The one right up there, in the parent post?

    41. Re:I love the hate by Featureless · · Score: 1

      Heh. Well, read the thread from the top, then you can see for yourself how his rants compare to the truth. This guy writes his own quotes - he's a pathological liar. Wouldn't be surprised if his entire career was fabricated.

    42. Re:I love the hate by IgnoramusMaximus · · Score: 1
      Well, read the thread from the top... This guy writes his own quotes - he's a pathological liar

      Sir, I stand corrected. I had you down for a petty nutcase who decided to focus his disappointments in life and low self-esteem into his crusade to prove to the world that Java is the One And True Language and All Shall Bow Before Its Glorious Light. But now it seems I was mistaken. Since your reply clearly indicates you are now thinking there are two of me, this would indicate far more serious mental problems and warrant the coveted title of a Complete Fruitcake with Nuts. And in your special case also one with Java Beans tossed in for a good measure. I humbly bow in deference to your towering woowooism.

    43. Re:I love the hate by IgnoramusMaximus · · Score: 1
      So, your attempts to change the subject fail, and you are finally going for the double, eh?

      Goodness me. Double? And I need a pair of duces to get double my winnings? You do now think this is a casino where you are running a table and I am a player? I am feeling guilty since asking this question might worsen your condition, but what is the jackpot? Wait ... before you answer: no its not the same as crackpot, I know you have that one in ample supply.

    44. Re:I love the hate by Featureless · · Score: 1

      Hmm. I'm trying to decipher this. It sounds like you're backing away from the table. But why stop now, IgnoramusMaximus? You've got a heck of a track record already, but I bet you can try for more.

      Go for it. Make up a fake quote, and then turn around and deny you did it... all while we can link to the evidence. This should be good. Or are you getting cold feet at this late date?

    45. Re:I love the hate by Featureless · · Score: 1

      And here you have a pretty good example of his style.

      Does have a certain charming bonhomie, doesn't it? He's really on his steadiest ground with insults.

      For reference, an explanation of one of his more obvious prevarications.

    46. Re:I love the hate by DarkKnightRadick · · Score: 1

      What's funny is that I play a massive online adventure game called RuneScape that is completely written in Java. Oh yeah, it's also kinda 3D-ish, lag is mainly from so many people playing at once (over 5K+ at any given time spread out over 36+ servers) and it's fairly fun as adventure games go.

      Did I mention it was played online through a web browser and that I don't use Sun's vm (I use Blackdown)? If not I think I just did. (;

      --
      "There is a way that seems right to a man, but its end is the way of death." Proverbs 16:25 (NKJV)
  67. Re:Java 5?? by arudloff · · Score: 1

    It's misleading.. if you look at the release notes, its "Java 2 Software Development Kit Version 5," or something to that effect..

    I like it.. it's kinda like saying this is Version 2.0's version 5 when there was never a 2.x to begin with.. It's like a puzzle.. I like puzzles.....

  68. Eclipse 3.1 betas by trajano · · Score: 4, Informative

    The Eclipse 3.1 betas support 1.5 constructs. I normally use the integration builds.

    --
    Archie - CIO-for-hire :-)
    1. Re:Eclipse 3.1 betas by Mechanik · · Score: 3, Interesting

      Now we just need to be able to build Eclipse itself using Java 1.5. I really really want to use 1.5 in my Eclipse plugins. I want real container classes dammit! :-P

      Currently you probably could build Eclipse using 1.5, but the Eclipse release engineering folks are still building using 1.4 (or at least, they were as of a month or so ago, and I haven't seen any mailing list traffic to the contrary). There won't be any official builds of Eclipse done with 1.5 for a while yet I think.


      Mechanik

    2. Re:Eclipse 3.1 betas by Anonymous Coward · · Score: 0

      The integration build I just downloaded (eclipse-SDK-I20040930-win32.zip) didn't seem to support the varags style construct.

      System.out.format() gives me a type error, saying that (String, Object[]) is the detected type, and that it doesn't support (String, String, int) or whatever my call to it looks like.

      Am I missing something?

    3. Re:Eclipse 3.1 betas by greg_barton · · Score: 1

      Now we just need to be able to build Eclipse itself using Java 1.5.

      I just tried doing this from the Gentoo ebuild of eclipse 3.0.1. Bad idea! They use the variable name "enum" hundreds of times, generating tons of compiler warnings, for one. That didn't stop the compile, but it failed for other reasons.

    4. Re:Eclipse 3.1 betas by trajano · · Score: 1

      I run eclipse on 1.5, I don't see why you can't build using 1.5. The only thing is if you do, no one can run your plugins outside of 1.5 since the generated class files can only be compatible with 1.5 VMs.

      --
      Archie - CIO-for-hire :-)
  69. errors in headlines by dmacleod808 · · Score: 1

    not to disparage the great posters on the main page. Is it just me, or have there been a lot of GLARING mistakes in headlines. Not to be cruel or anything, but the headline should be the first to be proofread. I havent noticed anything glaring in the post itself. "new Tecord" "Steaming cup of Java "5"

    --
    There Can Be Only One...
    1. Re:errors in headlines by Anonymous Coward · · Score: 0

      You're right. It should read "Steaming Pile of Java."

  70. Who controls Java by mslinux · · Score: 1

    My uni uses it in most of the CS classes for projects and homework. I use it for these tasks and some LDAP work as well, and I like it OK, but I'm a bit confused by who controls it and defines it. Seems to be a great language w/o a great community behind it and I've never quite understood that.

    If Java were more like Pyhton or Perl (great OO languages with great communities and clear ideas of who is behind them and where they're heading) I think Java could rule the enterprise world and the open source fanatic world, but I disgress.

    1. Re:Who controls Java by njko · · Score: 1

      Sun Microsystems

      --
      \n.\n
    2. Re:Who controls Java by Anonymous Coward · · Score: 0

      As it goes I think Java has one of the most amazing communities in the industry: JCP

      It includes vendor heavyweights like IBM, Oracle, BEA, Sybase, Borland et al, specialist players such a Plumtree, and many major players in the Java open source world like Craig McClanahan(Strus and JSF), Linda DeMichiel and Craig Russell. Sun developed Java and continues to manage the process and have responsibility for its various implementations. Oh and it does pretty much rule enterprise computing at the moment. I can't remember the last time I walked into a company that wasn't running at least one major system on Java/J2EE.

  71. Re:hmm. but how does this compare with Mono by ancice · · Score: 1

    Well, is mono is not going to be able to catch .Net in terms of speed, it seems something like a lost cause. To have the same speed as .Net, Mono will probably have to use faster hardware which will probably cost more. Thereby making it less popular. With less use, interest in Mono will drop, making it less likely to have good code contributions. Which makes it less likely to improve performance. Thereby, making it less popular, .. etc etc.. (repeat and rinse). So, I guess if there is no quantum leap for Mono soon, it's decline will start sooner rather than later.

  72. Wrong understanding ... by Anonymous Coward · · Score: 0

    You state "That would definitely make it competitive with .NET".

    You should have say "That would definitely make it competitive with C#"

    You can not compare a language and a platform.
    C# might have some more feature, some of them nice but most of them are odd (made to be VB people friendly = bad reason ).

    But if you compare the platform, .net lags years behind Java (From J2ME, J2SE or J2EE), from either community or enterprise perspective.

    Looking all the new impressive domain coverred by the latest JSR, I don't expect the gap will be filled by MS. One of the main reason is that MS main plaform is Windows and not .net.

    As a direct consequence, the will never bring all the feature at the .net level. Most of the valuable features (enterprise critics stuffs) will have to be keept at Windows level if they do not want to see .net as a potential threat for future windows market shares.

    By the way, community guys if you thing that Sun implementation of Java is not free enough, please join the GNU Classpath (http://www.classpath.org) project. They are aiming to provide a libre GPLed implementation of the whole Java standard platform.

    And according to the Java technology licensing, there is no way for Sun to prevent them doing that :) as long they keep the stuff compatible with the reference implementation (to check that they can get the TCK for nocost from the JCP because they are a .org ).

    So, /.ers instead of trolling around "Open" Java, Go And Build It at GNU's Classpath /a !

  73. Ad seen on Monster today by phyruxus · · Score: 4, Funny

    Java Developer needed. Must have 3+ years experience with Java 1.5, to start immediately.

    --
    "A witty saying proves nothing." ~Voltaire
    "d'Oh!" ~Homer
    1. Re:Ad seen on Monster today by autophile · · Score: 1
      Java Developer needed. Must have 3+ years experience with Java 1.5, to start immediately.

      Scary addendum: Equivalently, development team of 1095+ offshore developers with one day of Java 1.5 experience...

      --Rob

      --
      Towards the Singularity.
    2. Re:Ad seen on Monster today by JollyFinn · · Score: 1
      Scary addendum: Equivalently, development team of 1095+ offshore developers with one day of Java 1.5 experience...

      Actually thats a developement team with thousands of man years experience on Java and manyears of experience in Java 1.5 . Count experience not people.

      --
      Emacs is good operating system, but it has one flaw: Its text editor could be better.
    3. Re:Ad seen on Monster today by angel'o'sphere · · Score: 1

      I have only 2+ years experiance with Java 1.5 (beta) but also about 11 or 12 years C++, does that count?
      Yeah ... that was lame :D
      angel'o'sphere

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
  74. torrent anyone? PLEASE?!? by Anonymous Coward · · Score: 0

    I'm thinking it might be the site or just my shitty connection but my downloads speeds have steadily decreased already from 19kbps when I started to 13 kbps now. I'm an avid NetBeans user so I'm downloading the bundle but I'd really hate for it to die so I'd have to start over again. So I was wondering if anyone of you kind folks you already snagged it would mind setting up a torrent at all? Not just for me (I'm not that self-centered) but it would be a huge convience to anyone on dial-up etc. I wish I had something to offer but now that GMail invites have been saturated I've got completely nothing to offer.

  75. Re:STUPID MODS by Octagon+Most · · Score: 1
    "Can't tell the difference between a dissenting viewpoint and a flame."


    Perhaps stupid me for posting instead of moderating. My point was really my internal thought process on Java, since I am not a programmer. I am disappointed that it didn't live up to its advance billing and bring more applications to the various mobile devices I've used over the years, or to my Mac. No disrespect to Java as a language, since I understand it has many advantages. I can handle the karma hit so I thought it worthwhile to pose an alternate viewpoint. Live and learn.
  76. "New" Features? by Dante+Shamest · · Score: 0

    New to Java, old stuff to C++. This was Sun's plan for Java. Grab some features from existing languages, and market it as a simple strip-down version to attract programmers who can't understand pointers, enums, operator-overloading and templates. 10 years later, add in these features (but call them generics, not templates! or people will be on to us!) and call them "New". Oh wait, they still haven't added in operator overloading. Let's wait another 5 years, release Java Panther then we add them and call them "New!"

  77. Re:Poor Indecisive Sun by johnhennessy · · Score: 1


    To the best of my knowledge, its more complicated than that !!

    The new version (aka Tiger) is officially (from memory, its on suns site somewhere):

    Java 2 SE (Standard Edition) 5.0

    The previous version was:

    Java 2 SE (Standard Edition) 1.4.2

    Why we always need to know that this is Java 2 - I don't know. Surely if they've added new language constructs then it would have been better to increment to 2.

    --
    [ Monday is a terrible way to spend one seventh of your life. ]
  78. Okay, I'll Bite (a.k.a. "A Java Flame") by mattdm · · Score: 5, Interesting

    I work on a minor, highly targetted Linux distribution. I'd love to include Java, and I actually get a lot of requests for it. But, here's an excerpt from the license agreement you'll find if you look to download the software:

    B. License to Distribute Software. Subject to the terms and conditions of this Agreement and restrictions and exceptions set forth in the Software README file, including, but not limited to the Java Technology Restrictions of these Supplemental Terms, Sun grants you a non-exclusive, non-transferable, limited license without fees to reproduce and distribute the Software, provided that (i) you distribute the Software complete and unmodified and only bundled as part of, and for the sole purpose of running, your Programs, (ii) the Programs add significant and primary functionality to the Software, (iii) you do not distribute additional software intended to replace any component(s) of the Software, (iv) you do not remove or alter any proprietary legends or notices contained in the Software, (v) you only distribute the Software subject to a license agreement that protects Sun's interests consistent with the terms contained in this Agreement, and (vi) you agree to defend and indemnify Sun and its licensors from and

    (Yes, it really does just end abruptly without finishing the sentence. That trailing "and" there doesn't lead into the next section; it's just not done. Obviously I'm the only one who bothers to read these things -- *including* the people at Sun. Anyway....)

    My wish to give the software to my users fails almost every test....

    i: I don't want to distribute it for the "sole purpose of running [my] Programs". I want to distribute it so people can run other people's programs, including possibly their own.

    ii: uh, well, actually, my "Programs" don't add any functionality to Java, let alone "significant and primary".

    iii: oops, I include gcc, which has a Java compiler. And I'm definitely not going to drop that.

    iv: ahh, now this one I can agree with -- fine keep your copyright notices, etc.

    v: my distribution as a whole is under the GPL. I'd have to run this by our lawyers, but this looks like it'd conflict by requring additional restrictions (even if I could get special dispensation to deal with the other issues).

    vi: I don't really have the resources to defend and indemnify Sun "from and", even if I wanted to, thanks.

    And frankly, that's why I wish people would stop writing things in Java. It's a pain to deal with. I want to make everything as slick, integrated, and as easy as possible for my end users. Sun makes that impossible for Java applications. If you want your code to be easily integrated and made available to users like mine -- and really, that's users of any Linux distro targetted more broadly than the super-geek sector -- please don't use Java. If you must, at least design it to work with gcj instead of Sun's virtual machine.

    Unless Sun changes the license terms, their Java can never fill the "write once, run anywhere" goal -- but cleanly written source in an open language can.

  79. No you can't run it anywhere you like! by aug24 · · Score: 3, Informative

    You can only run it on a machine with a perl interpreter on board. Now tell me exactly how that is materially different to Java?

    Justin.

    --
    You're only jealous cos the little penguins are talking to me.
    1. Re:No you can't run it anywhere you like! by Anonymous Coward · · Score: 1, Informative

      The list of architectures that have successfully built a Perl VM is much larger than the list of arch's that have a Java VM. Look at the Configure script in the Perl distribution. You'll be surprised at how many different platforms it can run on.

    2. Re:No you can't run it anywhere you like! by Technonotice_Dom · · Score: 1

      And just to add to that, Perl is open source so if it doesn't compile on your architecture of choice, you can make it happen. With Java, you're dependant on which architectures Sun supports, will decide to support in the future, and which they'll decide to drop...

    3. Re:No you can't run it anywhere you like! by Anonymous Coward · · Score: 0

      Because you only need one copy of /usr/bin/perl per system?

      Because "perl -MCPAN -e 'install New::Module'" tends to work right out of the box?

      It's called infrastructure. The Perl folks figured out how to do it.

    4. Re:No you can't run it anywhere you like! by Anonymous Coward · · Score: 0

      Except the source to the Perl interpreter is there for you to peruse, and there's no corporate control over said source. And if you want to extend Perl in any direction, nobody's going to stop you.

      Oh, and the CPU and memory footprint are smaller. Imagine that. A full interpreter being more efficient than java. Not that it matters.

  80. Re:I, for one by Wm_K · · Score: 1

    You must be new here...

  81. Re:I, for one by Anonymous Coward · · Score: 0

    I, for one, think that it was probably a Simpsons paraphrase.

  82. Dear Typical-Family's-Free-College-Long-distanc... by agent+dero · · Score: 1

    No :)


    Seriously, just give a direct link to family members, OR, send them to java.com, it's right there, front page

    Now stop whining and go back to studying, like I am ;)

    --
    Error 407 - No creative sig found
  83. ermm by N3wsByt3 · · Score: 1

    You *DO* realise I was talking about Freenet and JVM 1.4.2, I hope?

    Even on Freenet you have those that claim there is little to it, especially on windows or on linux but then only without the native BigInt libraries... But then again, that's like saying: "that boat sails fine, if you don't use it with southern winds". Well, maybe, but it still makes more sense to use a boat that has shown no problems, whether using southern winds or not.

    --
    --- "To pee or not to pee, that is the question." ---
  84. 2 clicks. by Anonymous Coward · · Score: 0

    1. Point browser to java.com
    2. Click the huge "Get it Now" button (1 click)
    3. Click on your platform (2 clicks)
    4. Watch Java install
  85. Curious by Featureless · · Score: 1

    Do you know what bugs, specifically?

    1. Re:Curious by the_dubstyler · · Score: 1
      I know there was a bug with 1.4_02 and the Radeon graphics card used in most laptops that caused some Java stuff with specific graphics functionality to crash.

      Sorry that's not very helpful, but I'm an analyst, not a developer.

      --

      Other than that, Mrs Lincoln, how did you enjoy the play?

  86. Re:hmm. but how does this compare with Mono by Cederic · · Score: 1


    >> it's one of the major drawbacks of java on the desktop. ...

    >> java is in for a tough fight.

    Java is already established, both for server-side code (where it has a major presence) and on the desktop (albeit mostly in the form of tools for people writing server-side Java code).

    I don't really care about Java on the desktop, but Eclipse using SWT is an example of very performant Java desktop software. Maybe you wont write the next SETI @Home client in Java, but it has reached usable levels.

    Of course, Mono supports other languages, a different set of libraries, and perhaps lacks the maturity of Java - there are too many trade-offs involved for me to recommend one over another, so use whatever makes you happiest.

    ~Cederic

  87. Speed and resources by Anonymous Coward · · Score: 0, Interesting

    I work for a company where our entire service is dependant on java applications. As a systems admin at this company, I can safely say that java is a hideous resource hog of ridiculous levels, and it's bitch slow compared to things written in real languages, on even the fastest machines.

    I will say however, that it is far more reliable now, than it was say 2 years ago. For this I am thankful, as the callout phone rings less frequently.

    1. Re:Speed and resources by Anonymous Coward · · Score: 0, Flamebait

      So, how Java is not a real language, genius?

  88. Re:Free GMail Accounts! by virtualone · · Score: 0, Offtopic

    ooops! GMAIL is semi-slashdotted. (but who knows if this was relly caused by this comment) Server Error Gmail is temporarily unavailable. Cross your fingers and try again in a few minutes. We're sorry for the inconvenience.

    --
    Only morons moderate based on a sig.
  89. Re:J2EE -- 1.3.1 still by badmonkey · · Score: 3, Informative

    IBM no longer ships standalone JDKs- according to the license with SUN, they only ship JDK included in a product. IBM will definately have a 1.5 JDK, just don't hold your breath.

  90. Generics by Tomba · · Score: 1
    Nice that Java now has generics, but I still like C#'s better. From Sun's web page:

    "Generics are implemented by type erasure: generic type information is present only at compile time, after which it is erased by the compiler."

    Microsoft implemented generics in to the runtime, making them faster, more memory efficient and generally better working when using compiled assemblies (or jars/classes in Java) than generics implemented with type erasure.

    1. Re:Generics by argent · · Score: 1

      Can you elaborate on this, wouldn't runtime generics have the same kind of runtime overhead cost as dynamic typing? Or am I being mislead by the terminology you're using?

    2. Re:Generics by Tomba · · Score: 2, Informative

      Java's way of using type erasure is just a compiler "trick", a List is still a list of objects like it was before. A List in CLR is really a list of integers, not objects. There's no boxing involved, nor the extra memory overhead from boxing. Of course this only applies to the basic datatypes. Real objects are stored similarly in both ways, but even then there's one typecheck less in CLR when fetching data from the list.

    3. Re:Generics by argent · · Score: 1

      Got it, thanks.

  91. About the same time by kmmatthews · · Score: 1

    About the same time as slashdot gets a spell and dupe checker.. (which is effectively never. )

    --
    feh. stuff.
  92. Can we please moderate the write ups too ? by bluFox · · Score: 1
    [q]I, for one, welcome our new virtual machine overlord.[/q]

    This is becoming too much,, can we have a moderation system for write ups too ? please ?

    --
    ~561
    1. Re:Can we please moderate the write ups too ? by Anonymous Coward · · Score: 0

      agreed

  93. bugs by N3wsByt3 · · Score: 1

    For the specifics I would have to refer you to our main coder Toad, on http://dodo.freenetproject.org/pipermail/tech/2004 -September/thread.html

    Feel free to post a question or comment, there.

    --
    --- "To pee or not to pee, that is the question." ---
  94. Rapid learning by GeekDork · · Score: 4, Interesting

    As much as I might hate Java, I repeatedly have to throw this one thing into the fray: I had exactly zero former experience with network programming, and still, I was able to produce a basic telnet-like application in under 30 minutes, using only the Java API doc and some logical thinking. And I only had a very brief introduction into the language. Transferring this to C (although the basic structure is exactly the same with BSD and Java sockets) took me about a week, with all those damn low-level error conditions.

    --

    Fight hunger. Filet a politician and send him to a 3rd world country of your choice.

    1. Re:Rapid learning by tdrury · · Score: 4, Insightful

      Sir, I regret to inform you that you've demonstrated "critical thinking" within a hostile forum. You are no longer allowed to read Slasdot. Move along.

      Joking aside, it kills me to see the amount of research and due-diligence that goes into debunking a Microsoft-sponsored benchmark, but when it comes to Java most everyone starts spouting nonsense. People will remember their experiences from 8 years ago, or a bad app, etc. and immediately conclude that Java must suck for every conceivable application.

      Java is a tool - no more, no less. Use it where you think it is useful and leave on the shelf if you don't think it will help solve your current problem. Most mature developers know when and where a tool should be applied.

  95. Re:J2EE -- 1.3.1 still by Cederic · · Score: 2, Insightful


    Help me out here. Are you after a specifically IBM implementation of the Java VM for Windows, or is there another reason why you can't go to http://java.sun.com/j2se/1.5.0/download.jsp and download the Windows version from there?

    No intent here to flame, just curious about your reasoning..

    ~Cederic

  96. Re:hmm. but how does this compare with Mono by Anonymous Coward · · Score: 0

    Java faster than CLR Code running under the MS Runtime. Boy, what are some of your java crackheads smoking.

  97. Changes from Release Candidate? by DaveLatham · · Score: 1, Interesting

    Does anyone know if there are any changes between this and the release candidate, and what they are?

  98. Call to fellow enthusiasts. by barryman_5000 · · Score: 1

    Ok. I have been using the beta for awhile and was hoping that someone with more knowledge (and more patience) would be willing to make a semi-thorough benchmark compared to C++ and any other languages (including 1.4.2) so that we can see how much more effective it is. Remember, if you do it well you could prolly get on slashdot ;)

  99. Performance improved? Not in my experience... by znerd · · Score: 3, Informative
    I did some tests to compare Java 1.4.2_05 with JDK 1.5.0 and I found that 1.4.2_05 is considerably faster when building a project. This mainly involved XSLT processing and Java compilation.

    Test I did: Run 'ant -lib lib checkstyle java' on XINS 0.207)

    Preparation command:
    rm -rf build
    Timed command:
    time ant -lib lib checkstyle java
    I did 3 tests in a row for each Java version. I added the 'user' and 'sys' times and the averaged then. Results on my Gentoo Linux system with 2.6 kernel:
    Java 1.4.2_05 34.5s Java 1.5.0-rc: 42.9s Java 1.5.0: 41.6s
    1. Re:Performance improved? Not in my experience... by bullitB · · Score: 1

      You're really testing the compiler here, not the runtime. It's highly possible 1.5's compiler is slower because it is spending time to produce better bytecode.

    2. Re:Performance improved? Not in my experience... by Anonymous Coward · · Score: 0

      Of course javac is going to be slower, it has more stuff to check. that's not runtime performance, that's compiler performance. try running it with resin, tomcat, jetty, eclipse or any other java application.

  100. Java's nice and all by goofyheadedpunk · · Score: 0, Offtopic

    ...yes, but will it parse a hobo?

    --

    What if the entire Universe were a chrooted environment with everything symlinked from the host?
  101. Re:J2EE -- 1.3.1 still by Jason+Hood · · Score: 1, Informative

    That is why very few shops use websphere. Most use JBoss mostly because its free but partly because they stay current. Its not viewed as a cash cow like websphere.

    --
    Are you intolerant of intolerant people?
  102. Just adjust the GMT offset in your resume by Anonymous Coward · · Score: 2, Funny
    for the dates of experience with Java 1.5. It should be something like

    Start: Sept 1999 -2628000
    End: ... ...

    If they ask who your employer was at the time, just tell them you haven't yet notified that employer that you intend to resign yet. It'd be all true. No need to lie. Oh and if they ask what that -2628000 is, tell them it's just a MS Word revisionist code.
  103. it doesnt matter if its fast by Exter-C · · Score: 1

    It doesnt matter if its fast. I know with myself and many other people I know.. when they think java they think unstable. Lets hope they have more stable releases now.

  104. I, for one, think you missed the joke... by FatSean · · Score: 0

    ...but that's just me.

    --
    Blar.
  105. Re:I, for one by Anonymous Coward · · Score: 0

    I for one, and one for all.

  106. Re:mono sucks by Anonymous Coward · · Score: 0

    If mono sucks, what does Java©?

    Obligatory question: is it still dog slow?

    *LMAO about fucking Java© zealots*

  107. Re:Poor Indecisive Sun by Chreo · · Score: 1

    No, it is even worse. The download says Java(TM) 2 Runtime Environment Standard Edition 5.0 and then also 1.5.0.

    SUN was supposed to make the versioning easier by calling it 5.0 but without dropping the Java 2 or the 1.5.0 they just made it worse. Why not resort to the de facto standard way of naming versions? If it really is Java 2 (base) then it should be 2.5.0. I know Java 2 is the name but who gave the versioning job to the nice guy who haven't got all his apples at home and helps delivering mail?

    Dev: Hey Bob!

    Bob: Hello Stan!

    Dev: You know Bob, we need a name for our new software. The old one was named Java 2 and we need a name for the new one. Do you have a suggestion?

    Bob: Java 2!

    Dev: No that was the old one! We have a ne...

    Bob: Java 2...

    Dev: Yeah that was the old one.

    Bob: Java 2. Pet the dolphin.

    Dev: Well the real version of the new would be 1.5...

    Bob: Five...

    Dev: Um, 1.5.0 to be exact.

    Bob: Java 2... 5.0

    Dev: ...well, ONE.5.0, Bob!

    Bob: Ookey, Java 2 5.0 1.5.0 ... Java 2 ...

    Dev: Hey Bob, I think you may be on to something!

    Bob: Ookey... Have you seen my baseball?

    --

    Life is what happened when Good Intentions met Harsh Reality (the brother of the more infamous Chaos).
  108. A Fun Benchmark by An+dochasac · · Score: 1

    I like running any JVM through NIH's Java Medical Imaging application "IMAGEJ" http://rsb.info.nih.gov/ij/download.html I used the mri-stack from the sample images zip directory on a Sony PCG-GRZ615G Running Java Desktop System 2.0 (Linux 2.4.19 kernel, XFree86 4.3.0, GNOME 2.2.x) With the preinstalled j2re-1.4.2, I get 63884 pixels per second in imageJ's benchmark. With the 1.5 JRE for linux, I get 70767. ~10% improvement on this AWT app. With the JRE on MaxOSX...nevermind ;-) P.S. The OSX JRE isn't bad for most applications, but for some reason it has a very hard time with this benchmark.

  109. Re:J2EE -- 1.3.1 still by tmasssey · · Score: 1
    Help me out here. Are you after a specifically IBM implementation of the Java VM for Windows?

    Yes.

    I've found the IBM JVM's to be faster and more stable. Also, it doesn't make me install *two* copies of the JRE like Sun does (one for development and one for the system JVM). So all-in-all, I like the IBM verison better.

    As another poster said, it looks like IBM won't be developing a standalone version. However, I just found the IBM Development Package for Eclipse. It includes IBM's JDK 1.4.2 for Windows. I'm hoping that it's in it's own separate package like it was in the MQ Series client. But it seems that this is IBM's way of getting the new JDK out.

    Not as nice as a pure JDK download, but it'll work...

  110. They fucked up Java by vegetasaiyajin · · Score: 2, Insightful
    Java was a good, simple language. You may not have liked it, but you couldn't deny it was a simple language with an elegant C-style syntax.
    Now they added a lot of features that are nothing but crappy compiler sugar. Most of them badly implemented.
    1. Generics: They couldn't make it worse here. You cannot use reflection effectively because the type parameter information is not stored in the compiled class file. There are many ways to circumvent the type "safety" provided by the templates, especially if you are mixing code from older versions. This is one of the worse implementations of generics I have seen. I hate Microsoft with a vengeance, but they are implementing generics in a sensible way in the next version of C#. See this for an interesting discussion comparing Java, C# and C++ generics.

      With java generics you can compile this:
      class MyClass<T> {
      T[] anArrayOfT()
      {
      Object[] arr = new Object[10];
      //add whatever you want to arr.
      return (T[]) arr;
      }
      }
      Of course, you cannot assign the return value to a T[] because it is really an Object[], so, where is the type safety? All this is without mentioning that Java generics don't provide any performance benefit (which you would naively expect because you believe that you do not have to cast anymore).
      Java generics are just compiler sugar for automatically generating casts.
    2. Autoboxing: this feature removes clarity from the language. You do not know what is really going on. And you never know when you are going to be surprised.
    3. Enums: They coud have made a very good typesafe implementation using internal integer values orsomething simple like that. Instead they make them as clases. At first they look like they work fine, but if you start workking in contexts where several classloaders are used (e.g. application servers) then the enum is going to be loaded in both classloaders and comparison of apparently equal values will fail.
    4. Annotations: I really don't see the point of this. It's just more complexity. It seems it is only useful to help some complicated and probably not very well desinged tools.
    5. New for: This simply makes the code harder to read. The original, C like "for" construct was very clear and was very understandable both for arrays and collections. Now in order to use a fundamental construct (a "for") your code has to implement some new interfaces. This is pure crap.
    6. Static imports and variable length parameter lists: I think these are well done. I have nothing against these.
    7. It looks like they wanted to add novelty features, but in order to avoid make the appropriate JVM specification changes, they implemented everything as compiler sugar. It just doesn't work.


    8. Maybe the fact that Java is now managed by a comittee instead of a few people who do know about language/compiler design has something to do with this.

      Maybe they are just trying to make it "easier"for those who don't know how to program. Again, it doesn't work.

      Something more or less like this happened when C++ was standarized. They came up with an overly complicated monster language, but at least the specification was not a broken one, just complex.

      They could have added pass of parameters by reference (at least for primitives), which would have been very useful in real world situations. But instead they decided to add a ton of crap.

      Java is doomed now. Too bad it was my favorite language. Now I have to look for another language. Maybe D?
    --

    My heart is pure, but make no mistake, it's pure evil
    1. Re:They fucked up Java by Anonymous Coward · · Score: 0

      Most of them badly implemented.

      Most of them poorly implemented. Thanks.

    2. Re:They fucked up Java by Anonymous Coward · · Score: 0

      Mate, WTF are you talking about?

      No one said you must use these new features.

      Did people start complaining about C being shit when C++ was introduced? No, they just continued to use C instead. Or use C++ ignoring the features they didn't like.

    3. Re:They fucked up Java by Anonymous Coward · · Score: 0

      Not yet, but when someone at Sun gets the Bright Idea(tm) of rewriting the class libs to use all the new syntactic sugar, you will have no choice but to Submit or Die(sm).

      That is, if Sun doesn't go Tits Up(tm) first...

    4. Re:They fucked up Java by Cederic · · Score: 2, Interesting


      >> Java generics don't provide any performance benefit

      On the contrary, they provide the ability to write code faster, to understand code faster and to maintain code more easily, leading to fewer bugs, and thus less testing, and thus faster deployment.

      That's a hell of a cost saving - more than enough to buy a slightly faster CPU, if you're really concerned about runtime performance.

      >> Autoboxing: this feature removes clarity from the language.

      I must have misunderstood this one. I thought it was simple auto-translation from primitives to their object equivalents (e.g. Integer to int and vice versa). Personally I have no clarity issues with

      List listOfNumbers = new List();
      listOfNumbers.add(5);
      System.out.println ("Number added = " + listOfNumbers.get(0));

      Sure, that's a shite example, but it's late at night. There's autoboxing going on in that add(5) call; I don't think it's hurt clarity at all.

      >> Enums

      That's certainly a potential issue when dealing with object references using an Enum pattern; I haven't tried that scenario in 1.5 so not whether that'll be a problem. Of course, if you rely on .equals() instead of == (as you generally should for all class types) then I'd expect Enums loaded from different class loaders to still be .equals() equal and thus your problem wont arise. Good spot though, I'll have a play and experiment with that one.

      >> Annotations: I really don't see the point of this.

      It's an exceedingly powerful addition to the language, albeit one I'm far from certain I'm happy about.

      See the Apache Beehive project for an indication of what can be achieved with these things. (e.g. a one line annotation to turn a class into a web service - that's a lot of code you didn't have to write).

      Personally I think they add a lot of complexity to the language, and that does (as your post's main thrust seems to suggest) make the language weaker - not because it's less capable, but because it's harder to understand and to write. Note that I'm not lazy, I'm not looking for a language that does everything for me and doesn't make me think; I'm looking for a language that lets me think about the logic I'm writing, rather than the language mechanics being used to express that logic.

      >> New for: This simply makes the code harder to read.

      I'm going to challenge that. Yes, maybe harder for read the first time(s) you come across it, but after that, every bit as simple as the current 'for'. If anything, potentially simpler..

      >> Static imports and variable length parameter lists: I think these are well done.

      At risk of sounding argumentative, I'm even going to disagree with your only positive comment on the changes.

      Static imports add no value that I can perceive. They are there purely to entice users of other languages. I like having use of statically declared values qualified by a classname, it makes the code more readable and adds a little context.

      So some of the changes I welcome, others I am more uncertain about, and a couple I'll dissuade people from using (to prevent misuse and aid code readability - where I am, maintainable code counts for a lot). I wouldn't however agree that "They fucked up Java".

      ~Cederic

    5. Re:They fucked up Java by vegetasaiyajin · · Score: 1

      No one said you must use these new features.
      I will try as hard as I can to avoid them. But look at the new documentation for the class library. It's rewritten using generics. In the future it will be very hard to avoid these new features. The class library uses them. Third party libraries will start to use them. How can you program in Java without using the standard library?

      --

      My heart is pure, but make no mistake, it's pure evil
    6. Re:They fucked up Java by Anonymous Coward · · Score: 0

      As far as experience tells me, short code is almost always more readable than long code (except for abusive use of regexps and such stuff). Java 1.5 new features are great because they make your code shorter, hence more clear.

      Dismissing something as syntactic sugar is just silly. Java generics may be not perfect, but they make code shorter, therefore clearer. Maybe you enjoy having to manually cast each time you use a container like ArrayList, or to manually write your own class ListOfT each time you want to use a list of elements of T type. I dont. Generics make my life easier, Im glad they included them.

      I fail to see how autoboxing can make your code any significally harder to read. Its like saying method overloading should be banned because it makes code harder to read as it makes it impossible to determine what a method does only by its name.

      In general, no one is forcing you to use any of this new features. If you find people using them, it is probably because they are USEFUL.

      I hate the fact that some people refuse to accept something can makes code clear if it doesnt stick to their own dogmas on programming styles.

    7. Re:They fucked up Java by mcbevin · · Score: 1

      Generics: They couldn't make it worse here. .... Java generics are just compiler sugar for automatically generating casts.

      Generics haven't been implemented in the best possible way (thus hurting performance and giving the reflection anomaly), but they are nevertheless much better than no generics, and provide much more than 'syntactic sugar', rather provide compiler-time type checking where none was before, and make the code significantly more descriptive. Anyone with experience using C++ who has had to use Java knows that they were sorely needed, and now they're finally here and I for one am not complaining.

      Autoboxing: this feature removes clarity from the language.

      On the contrary. Autoboxing - like generics and the new for loop - removes the need in many places for casts while simplifying the code, thus _improving_ clarity.

      The only vaguely plausible argument against the way Tiger has implemented generics and the use of autoboxing is performance issues, yet in terms of performance they don't really make things worse, rather fail to make things better. And from a clarity standpoint theres no doubt they improve things.

      New for: This simply makes the code harder to read.

      I take it you are the kind of person who prefers reading assembler?

      Sorry, but when you make this claim you lose _all_ credibility in my eyes. How can

      int total = 0;
      for(int i: mySet) {
      total += i;
      }

      be harder to read than

      for(Iterator it = set.iterator(); it.hasNext();)
      Integer integer = (Integer) it.next();
      int i = integer.toInt();
      total += i;
      }

      Not only is the new for loop easier to read and far more succinct and thus quicker to type, but its type-safe, and leaves far less room for error i.e. the common errors of mixing the loop variables etc are gone, for example the error causing the following infinite loop would not occur with the new for loop:

      for(int i=0; i<list.size(); i++) {
      List list2 = (List) list.get(i);
      for(int j=0; i<list2.size(); j++) { ...
      }
      }

      Annotations: I really don't see the point of this. It's just more complexity.

      Just because _you_ don't see the point of something doesn't mean anything in my book sorry. A lot of people much cleverer than you _do_ see a point to them. Personally, I tend to be rather sceptical of such things, but having used attributes in C# can see how they bring real value in certain situations (such as when fields in a class map to a DB or XML, and attributes can be used to describe this mapping in cases where for example the field names differ).

      Regarding enums, the point you raise is cause for some concern, but again they are something badly needed and having them, even if slightly flawed, is on balance better than having none and having individual coders make their own far poorer implementations of the concept when they need enums themselves.

      So .... how much did Microsoft pay you again?

    8. Re:They fucked up Java by vegetasaiyajin · · Score: 1


      >> Java generics don't provide any performance benefit

      On the contrary, they provide the ability to write code faster, to understand code faster and to maintain code more easily, leading to fewer bugs, and thus less testing, and thus faster deployment.
      That's a hell of a cost saving - more than enough to buy a slightly faster CPU, if you're really concerned about runtime performance.


      Yeah. Just use crappy algorithms because they are faster to program. You can buy a faster CPU to make bubblesort faster.

      Anyway you seem to be talking about the benefits of generics in general.

      I agree that generics (when implemented properly) are great. But Java's implementation is simply broken. C++ generics are correctly implemented. C# generics will be correctly implemented. Working with generics is or will be great in those languages. Java generics are broken. The type parameter information is nor really part of the code generated by the compiler. For example, you cannot construct a List using reflection because that type does not exist. When you have to interact with other code you'll suffer the consequences of this bad design.

      >> Autoboxing: this feature removes clarity from the language.

      I must have misunderstood this one. I thought it was simple auto-translation from primitives to their object equivalents (e.g. Integer to int and vice versa). Personally I have no clarity issues with

      List listOfNumbers = new List();
      listOfNumbers.add(5);
      System.out.println ("Number added = " + listOfNumbers.get(0));

      Sure, that's a shite example, but it's late at night. There's autoboxing going on in that add(5) call; I don't think it's hurt clarity at all.


      What about this one?

      Integer i = new Integer(2);
      Integer j = new Integer(2);
      assertTrue(i >= j); // success
      assertTrue(i = and myList and then call myList.add(5) wihtout mysterious things going on behind the scenes.
      Almost all uses of autoboxing will be for dealing with primitives in container classes.
      Something completely unnecessary with a good Generics implementation.


      >> Enums

      That's certainly a potential issue when dealing with object references using an Enum pattern; I haven't tried that scenario in 1.5 so not whether that'll be a problem. Of course, if you rely on .equals() instead of == (as you generally should for all class types) then I'd expect Enums loaded from different class loaders to still be .equals() equal and thus your problem wont arise. Good spot though, I'll have a play and experiment with that one.

      In case you don't know, equals() fails with classes loaded in different classloaders. The real fully qualified name of a class in Java includes the ClassLoader as a prefix. So equals will fail.
      The reason for this is that class with the same name but in different classloaders are potentially different versions.
      That is why you can have J2EE applications that use different versions of the same library in the same application server.
      The only way to make equals() work is using reflection and comparing the names of the clases.
      I understand that with Java 2 version 5 version 1.5 enums equals() will fail with different classloaders. I haven't tested it, though.


      >> Annotations: I really don't see the point of this.

      It's an exceedingly powerful addition to the language, albeit one I'm far from certain I'm happy about.

      At least you have your doubts about the value of this atrocity.
      This feature adds inmense complexity to the language and will benefit only a handful of projects which have existed anyway without such support IN the language specification.


      >> New for: This simply makes the code harder to read.

      I'm going to challenge that. Yes, maybe harder for read the first time(s) you come across it, but after that, every bit as simple as the curre

      --

      My heart is pure, but make no mistake, it's pure evil
    9. Re:They fucked up Java by vegetasaiyajin · · Score: 2, Interesting
      As far as experience tells me, short code is almost always more readable than long code (except for abusive use of regexps and such stuff). Java 1.5 new features are great because they make your code shorter, hence more clear.

      Dismissing something as syntactic sugar is just silly. Java generics may be not perfect, but they make code shorter, therefore clearer.

      it is not that they are not perfect. They are completely broken. I am not against adding generics to Java. But, I prefer Java without generics than with the crappy implementation they came up with.
      If they had implemented generics properly I would not be complaining. I would be very happy instead.
      First of all, they should have supported primitives in generics. This could have eliminated the need for autoboxing.
      They instead went for a crappy implementation of generics and then another crappy workaround (autoboxing) for not having made a good generics implementation.
      And you are wrong saying that language constructs that are shorter are automatically clearer.
      By that logic, Perl would be one of the clearest languages of all.


      Maybe you enjoy having to manually cast each time you use a container like ArrayList, or to manually write your own class ListOfT each time you want to use a list of elements of T type. I dont. Generics make my life easier, Im glad they included them.

      You belive they make your life easier.
      When you have to deal with the errors of the implementation you are going to see how easier it is.


      I fail to see how autoboxing can make your code any significally harder to read. Its like saying method overloading should be banned because it makes code harder to read as it makes it impossible to determine what a method does only by its name.

      I am not a big fan of method overloading, but I certainly would have prefered method overloading instead of the pile of broken crap they came up with.
      As to how clear Autoboxing is, please explain the clarity of this:
      Integer a = 2;
      Integer b = 2;
      boolean flag;
      flag = a>=b; //true
      flag = a<=b; //true
      flag = a==b; //false
      I fail to see how that is clear. Why is it clear that == should not be used for comparing objects, but >= and
      In general, no one is forcing you to use any of this new features. If you find people using them, it is probably because they are USEFUL.

      If I find people using them it will be because:
      a) they are ignorant and don't understand how broken Java generics and autoboxing is.
      b) They have no choice because they have invested a lot in Java and now the standard library is rewritten using templates as will several other tools too (probably for one of the two reasons).


      I hate the fact that some people refuse to accept something can makes code clear if it doesnt stick to their own dogmas on programming styles.

      I hate the fact that some ignorant people just fail to see how broken something is and criticize knowledgable people (and I am not talking about me, but many experts whose opinion I share) because they point out the flaws of something they believe is good.
      --

      My heart is pure, but make no mistake, it's pure evil
    10. Re:They fucked up Java by vegetasaiyajin · · Score: 1

      Generics haven't been implemented in the best possible way (thus hurting performance and giving the reflection anomaly), but they are nevertheless much better than no generics, and provide much more than 'syntactic sugar', rather provide compiler-time type checking where none was before, and make the code significantly more descriptive. Anyone with experience using C++ who has had to use Java knows that they were sorely needed, and now they're finally here and I for one am not complaining.

      I am complaining because there is no valid reason not to have a decent generics implementation in Java. Backwards compatibility? new compiled code won't run on previous JVM versions, so that wasn't a valid argument.


      Sorry, but when you make this claim you lose _all_ credibility in my eyes. How can

      int total = 0;
      for(int i: mySet) {
      total += i;
      }

      be harder to read than

      for(Iterator it = set.iterator(); it.hasNext();)
      Integer integer = (Integer) it.next();
      int i = integer.toInt();
      total += i;
      }


      Well maybe it is just me, but I think the first one is much harder to understand.
      There is no doubt about what the second does.
      Of course, the second was harder to write, but not harder to understand.
      Note that all examples people provide about how great generics and autoboxing are simply prove my point.
      Generics should have supported primitive types. If they had done this autoboxing would not be needed.
      Autoboxing will be primarily used for putting primitives into collections. The cosequences are:
      1) Performance suffers, because a List of integers will not be as efficient as a list of int's.
      If you want efficient libraries for primitives you have to write them in a non-generic way.

      2) While autoboxing problems will not hit you if you only use it to add them to the inefficient Object based collections, it introduces a mechanism that has all sorts of counterintuitive behavior if used for other purposes (comparisons with greater than, less than and == being just a small example).

      Your problem is that you think I am against the idea of generics. Of course I'm not. But I AM against the idea of a broken implementation of generics that has a broken implementation of a counter-intuitive mechanism for pretending that they support primitives.


      Just because _you_ don't see the point of something doesn't mean anything in my book sorry. A lot of people much cleverer than you _do_ see a point to them. Personally, I tend to be rather sceptical of such things, but having used attributes in C# can see how they bring real value in certain situations (such as when fields in a class map to a DB or XML, and attributes can be used to describe this mapping in cases where for example the field names differ).


      I do not see justification for introducing extreme complexity in a language (as annotations do) for justifying a simple application such as XML or OR mapping.
      I think that could be handled with tools like XDoclet, which I do not like, but since it is not part of the language, I have no problem with other people using it for their applications.
      Anyway, I doubt many of the people who promote annotations are more clever than many people who oppose them (myself included).
      Such applications could perhaps should probably use configuration files.


      Regarding enums, the point you raise is cause for some concern, but again they are something badly needed and having them, even if slightly flawed, is on balance better than having none and having individual coders make their own far poorer implementations of the concept when they need enums themselves.

      I think enums were needed. But, as with generics, why couldn't they make a simple, good implementation as many other languages do.
      No. They came up with something that is fundamentally broken. Yeah, it works in most cases, but the flaws are there and have the potential of hitting any appli

      --

      My heart is pure, but make no mistake, it's pure evil
    11. Re:They fucked up Java by vegetasaiyajin · · Score: 1

      Did people start complaining about C being shit when C++ was introduced? No, they just continued to use C instead. Or use C++ ignoring the features they didn't like. First of all, C++ is not the newer version of C. It is a different language.
      Second, the problem is not that you do not have tu use feature you do not like. The problem is that if those features are broken then the language is broken and this is the case with Java.

      --

      My heart is pure, but make no mistake, it's pure evil
    12. Re:They fucked up Java by vegetasaiyajin · · Score: 1

      Not yet, but when someone at Sun gets the Bright Idea(tm) of rewriting the class libs to use all the new syntactic sugar, you will have no choice but to Submit or Die(sm).
      Guess what. A large part of the library is using the poison, er... sugar.

      --

      My heart is pure, but make no mistake, it's pure evil
    13. Re:They fucked up Java by mcbevin · · Score: 1

      I think we're more or less in agreement that some of the new additions to Java 5.0 are flawed. Like you I also don't buy the backward compatibility argument for crippling generics, given that as you say there is no way to compile code with generics to work under older JVMs. Maybe the point is that it makes it easier for old code to run within the new JVM?

      Unfortunately Java has a history of introducting - and then getting stuck with - not-quite-perfect implementations of good ideas - swing + awt for example. Nevertheless, I would still rather have generics as they have been implemented than none.

      Where I can't see eye to eye with you is on the for loop comparison. Would you at least agree that C#'s syntax

      foreach(int i in myList) { ....
      }

      is easier to read and clearer than the old for loops? I think you really need to step back from your years of C/C++/Java programming and ask what is easier to understand and use for someone without years of experience in writing/reading
      for(int i=0; ilist.size(); i++) - an extremely unintuitive syntax when you think about it, and a hell to write when you start adding iterators into the equation.

      Also note that the foreach / new_java_for will have speed advantages (something you seem to find very important).

      Regarding me being a fan of Microsoft products, I will admit that I quite like C#, and am really looking forward to .NET 2 which will address a lot of major shortcomings.

    14. Re:They fucked up Java by vegetasaiyajin · · Score: 1

      Maybe the point is that it makes it easier for old code to run within the new JVM?
      Many applications (especially complex ones like application servers, Corba orbs and even IDEs) usually don't run in newer releases of the JRE. They always require small changes because the libraries and other things change.
      I remember clearly a version of weblogic that ran on jre 1.3.x did not run on 1.4.x. Was that a big problem? No. You ran it with the old version.
      BEA shortly released a version that did run on 1.4. It is that simple. Nothing prevents anyone from having multiple JVMs in the machine. In fact this happens all the time.
      For example, some IntelliJ IDEA versions only run within the JRE bundled with them.
      I do not see why they couldn't make generics right and at the same time provide support for previous releases. The compatibility didn't even need to be perfect, because it has never been.

      Where I can't see eye to eye with you is on the for loop comparison. Would you at least agree that C#'s syntax

      foreach(int i in myList) { ....
      }

      I agree it is easier to understand than Java's construct.
      And I agree it is not as flawed as Java's generics/autoboxing because it does not introduce counter-intuitive behavior or side effects.
      What I don't like about the Java version is that, to be used with an arbitrary class, it requires the class to implement certain specific interfaces.
      The language is supposed to be independent from the standard class library (except, perhaps for the special class Object). To tie the language definition to a specific interface is wrong, IMHO.
      But I will admit that if generics were done right and autoboxing were removed from the language, I would not have problems with the new "for". I would simply not use it. I would still consider Java a great language because its core wouldn't be flawed.

      Regarding me being a fan of Microsoft products, I will admit that I quite like C#, and am really looking forward to .NET 2 which will address a lot of major shortcomings.
      As much as I hate MS, I admit C# is a good language. In fact is very similar to the old Java. C# 2.0 will be a lot better than Java, since it will not be as crippled as the new Java is.
      But I don't like .Net. It is very unfortunate that C# is too tied to .Net, since the next version will be an excellent language (with some features that I don't like, but not flawed like Java is now).
      I am very upset that my favorite language, which had things that I did't like but that wasn't flawed conceptually, is now a broken language.
      Yes, the new features will work in most cases, but there is a non-trivial minority of cases where the flaws will strike and make the life hard for everyone.

      --

      My heart is pure, but make no mistake, it's pure evil
  111. Re:hmm. but how does this compare with Mono by Jason+Hood · · Score: 3, Insightful

    Over 50% of the .Net libraries have not been ported to Mono and may never be. Mono is pretty cool but until it is fully ported it will remain years behind Java and .Net. You cant compare them like you cant compare java to perl. Java and .Net are very much competitors and will continue to dominate the industry in their niche. Companies need security (as in a future) for their multimillion projects. It took Java ~6 years to self promote. If Mono severely ramps up their efforts, they MIGHT reach the plateau. Java was first to the punch, which is a huge advantage. I would wager my hunting dog that Mono will not overtake java in the next ten years. If MS is lucky and throws enough money at .Net, it has a decent chance.

    You dont see companies developing 5k class projects in Mono, but thousands (if not more) do with Java and .Net. Dont believe me? Go count job postings for programming at Monster in a city near you.

    My city last month?
    60% Java
    15% Perl
    10% C/C++
    5% .Net
    5% COBOL
    5% other

    I cant hire Java and Perl programmers fast enough.

    --
    Are you intolerant of intolerant people?
  112. Sun doesn't use "Java 5", why should you? by ---- · · Score: 1

    Actually, SUN doesn't even know.

    Check out their download page url.
    http://java.sun.com/j2se/1.5.0/download.jsp.

    Check out the of the page too.

    J 2SE 5.0
    Download Java 2 Platform Standard Edition 5.0

    In my mind, If Sun themselves don't use the phrase "Java 5", then why should we? Shouldn't this release have the acronym J5SE?


    /* ---- */
    1. Re:Sun doesn't use "Java 5", why should you? by BobPaul · · Score: 1

      No. Because they starting using this goofy numbering scheme after Java2 came out. Check here for an explination of the number system. Note that J2SE 1.4 is Java 2 Platform Standard Edition 4.0. Java 2 is the language, and the link above shows how compatibility follows based on the version number (1.4, 1.5, etc)

      This means they won't make a Java3 that is incompatible with Java2. They will make a Java2 2.0 and restart their goofy numbering system.

    2. Re:Sun doesn't use "Java 5", why should you? by Anonymous Coward · · Score: 0

      A better compatibility explination is here

      Basically, it goes like this.
      The 1 denotes FORWARD compatibility (Binary Compatibilty). If you made sources on a Java2 1.x (where x is less than 5) it will run on Java2 1.5

      The 5 denotes BACKWARD compatibility. (Source Compatibility) Since 5!=4, sources written for 5 will not compile and/or run on Java2 1.y where y5.

      Anything after those numbers (1.5.a.b where a and b are additional numbers) are platform specific, as the parent's link explains.

      Just as the parent explained, it's still Java2, it's just a newer version of Java2.. the 5th version of Java2.

  113. Exactly by Trejkaz · · Score: 2, Insightful

    And not only was it faster to write in the first place, but the chances are your app will run on Windows out of the box without having to add arbitrary WinSock calls around the place. And it will run on BSD without adding extra network headers and libraries to the makefile after discovering half of them are missing from the default. And it will run on OSX without any knowledge of that platform at all. WORA is indeed real until people try to break it with specifically crafted examples. :-)

    --
    Karma: It's all a bunch of tree-huggin' hippy crap!
  114. Other platforms? by saintlupus · · Score: 1

    Still no love for the Linux/PPC people, I see. Damn. I would really like to be able to use Sun's JVM on all of my machines, but I'm stuck with IBM's on my old Powerbook.

    --saint

  115. What kind if idiot would call this flamebait? by LibertineR · · Score: 0, Troll

    Is some fool going to argue that Metadata attributes are not important? I am so sick of the silly bigotry of this board, that I hardly moderate anymore. Moderation is a joke, when idiots are allowed to moderate based on personal biases instead of the value of the goddamn post.

    1. Re:What kind if idiot would call this flamebait? by Anonymous Coward · · Score: 0

      I'm sure it has nothing to do with the "if you argue, you're wrong" comment...

  116. Re:Okay, I'll Bite (a.k.a. "A Java Flame") by Trejkaz · · Score: 1

    Yeah, I hate the Java licensing too. It would be great if GCJ and GNU Classpath would catch up to the point where 95% of Java apps would run on them... then people could just stop using Sun's implementation on Linux, right?

    A solution like 0install would be the trick for the redistribution problem, though. Nobody would redistribute Java because it would come down from Sun's site as soon as someone needed to run it. ;-)

    --
    Karma: It's all a bunch of tree-huggin' hippy crap!
  117. Re:oh great by mod_parent_down · · Score: 1
    Morning indeed.
    I read 'steaming' and thought of something else...

    I guess it's time to go take the dogs for a walk.

  118. Re:I wait! -- you mean... by scovetta · · Score: 4, Funny

    You mean 1.5.1_03.1

    --
    Wer mit Ungeheuern kämpft, mag zusehn, dass er nicht dabei zum Ungeheuer wird. --Nietzsche
  119. He's not the only one by Anonymous Coward · · Score: 0

    my girlfriend also likes static imports

  120. Re:Poor Indecisive Sun by VAXGeek · · Score: 1

    I think the real problem is brand recognition. They want people to be able to recognize Java2, Java 1.5, and Java 5.0.

    I wonder if we'll see J5SE soon?

    --
    this sig limit is too small to put anything good h
  121. a fond farwell by mr.+marbles · · Score: 1

    I think it pretty obvious that Sun Microsystems is heading straight for fiscal ruins if something doesn't change in the business strategy itself. So my question is, is Java 5 a fond farwell for a company that's no longer able to compete?

  122. Why build it? by Anonymous Coward · · Score: 1, Informative

    The whole point of Java is that you don't *need* to build Java apps like Eclipse to run them - you just copy the .class files in a directory and start it up.

    With that in mind, I've actually built some parts of it with 1.5 and they were fine.

    1. Re:Why build it? by Thuktun · · Score: 1

      The whole point of Java is that you don't *need* to build Java apps like Eclipse to run them - you just copy the .class files in a directory and start it up.

      Unless you try to run a 1.5 app/applet using a 1.4 or earlier JRE/JDK and it uses any VM or library changes present only in 1.5.

      Java doesn't magically spirit away versioning issues.

    2. Re:Why build it? by ShinmaWa · · Score: 1

      Unless you try to run a 1.5 app/applet using a 1.4 or earlier JRE/JDK and it uses any VM or library changes present only in 1.5.

      This sounds like a good argument for NOT building it yourself and just using the distributed 1.4 version of the .class files.

      Java is fairly good at being backward compatible. Java programs compiled with the 1.4 compiler will run just peachy under the 1.5 JVM.

      --
      The /. Effect: Thousands of users simultaneously accessing a site to not read its content.
  123. c++ should never have memory leaks, either by ufnoise · · Score: 1
    Java should never have memory leaks...



    If you use smart pointers in c++, the memory is automatically deleted when it's reference goes out of scope. Check out the boost library (http://www.boost.org)


    foo *bar = new foo;


    shared_ptr x(bar);

  124. Re:Okay, I'll Bite (a.k.a. "A Java Flame") by ankhank · · Score: 1

    > their Java can never fill the > "write once, run anywhere" goal You're on the verge of the epiphany. That phrase, too, was written by lawyers. It means, "if you misuse our product ONCE, we'll hunt you down no matter where you run!" It's typical of the lawyer to use words backwards. "Infer" commonly means "imply" and vice versa. And -- remember the RIAA? -- "write" means "wrong."

  125. Re:Java 5 or 1.5? by Al+Dimond · · Score: 1

    Because then you get all that damn confusion between American-style dates (January 5, 2004 = 01/05/2004) and European-style dates (5 January, 2004 = 05/01/2004). Of course, for naming a software release, you would want to put the year first and month second, so that a sort by name would put the releases in chronological order, like so: java.jre-20040105 for January 5, 2004.

  126. Re:oh great by perseguidor · · Score: 1

    Well this was indeed funny, but kept me wondering about this thoroughly off-topic detail: english is not my first language, and so I don't know why you tend to mispell "article" so often. Is this a running joke I'm not aware of? Or is it really an all too common mistake because of its pronunciation?

    Hoping that this doesn't ruin my scarce karma. I don't mean to insult anyone... or myself if this is about something I'm not getting : )

    --
    O make me a mask
  127. typo Re:c++ should never have memory leaks, either by ufnoise · · Score: 1
    Sorry for the typo, html doesn't like template arguments.

    foo *bar = new foo;
    shared_ptr<foo> x(bar);

  128. Re:J2EE -- 1.3.1 still by mitch0 · · Score: 1
    However, your ClassCastExceptions will only get bumped to compile time in JDK 1.5, true. But I must admit that in eight years of Java programming, I've never had this particular problem where it didn't take more than a few seconds to find the source of the bug.


    Yeah, it's nice to wake up at 03:00 AM for a call and listening to a stack trace from the Operations guy, and "taking that few minutes" to track down the problem... Compile time error reporting is Good Thing (TM).
    Java containers are still far-far away from STL, for example, but this check at least makes them a bit less frustrating to work with...

    cheers,
    mitch
    --
    // "If human beings don't keep exercising their lips,
    // their brains start working." -- Ford Prefect
  129. Mind set by rumblin'rabbit · · Score: 1
    Actually, I think for Java it was more like:

    Okay, we've written a quasi-OO version of C, what what a true OO version look like?

    But I agree that each language refects its mindset at the time of invention. Fortran was: What would a portable, human-readable assembler look like? The result was arithmetic ifs, computered goto's, and (shudder) alternate returns, all assembler features that should have stayed with assembler.

  130. The new loop: guaranteeing slowness by Anonymous Coward · · Score: 1, Interesting

    The new loop is pretty awful. Why? Because it *cannot* be fast. It has set slowness in stone. It's guaranteed.

    The problem here is that iterators are slow. Very slow. Because they require two un-inlinable method calls per element in the iteration. Iterating over an ArrayList is EIGHT TIMES SLOWER than scanning over an Object array and casting to the right class, and SIXTEEN TIMES SLOWER than scanning over a properly typed array.

    Iterators can't be inlined because the compiler doesn't have the concrete class -- it just knows it's an iterator. If you cast the iterator into its concrete class and set it to a concrete-class-typed variable, you could get java to inline the methods, and Iterators would be at least somewhat fast.

    Unfortunately, the new loop construct makes this impossible. Thus, it is *guaranteeed* to be sixteen times slower than how you could do it elsewhere.

    Crap, that's bad.

    1. Re:The new loop: guaranteeing slowness by iabervon · · Score: 1

      Using a list for the loop seems to me to be 12 times slower on build 1.5.0-beta-b32c. Instead of taking 5 nanoseconds on my system, it takes 60 nanoseconds. So it's important to use the more efficient loop any time your loop iterations take less than 600 nanoseconds or so and you're doing enough of them to add up to something substantial (I was testing with 100000000 iterations to get things into the order of a second). For anything other than the innermost loops of databases or matrix multiplications, it's just not going to matter.

      If this were actually an issue on any practical code, they'd make the JIT compiler determine that the iterator is constant in the loop, and use a copy of the loop with the ArrayList versions inlined when it's an ArrayList.

      If you still want to use for loops over arrays, you should be aware that the new for loop syntax also works for arrays.

  131. Its a steaming cup of something alright... by Anonymous Coward · · Score: 0

    As in "When I walked my Great Dane this morning I forgot a plastic bag and had to use a coffee cup I found on the road. That is one steaming cup"

    Java sucks

    1. Re:Its a steaming cup of something alright... by Anonymous Coward · · Score: 0

      I was with you until you "found" a coffee cup on the side of the road.. I mean what are the chances? it would have been somewhat plausible if you used your coffee cup.. the one you bring incase you forget the bag and all.

  132. amd64 binaries still crash on Intel EM64T by nvrrobx · · Score: 1

    I'm an avid Java developer. Hell, I'm even certified, but this bug just annoys me to no end.

    I reported (as did other people) that the amd64 binaries of JDK 1.5.0 crash on Intel EM64T machines. SIGILL. They're using the 3DNow! prefetch instructions. It's really easy to disable those in gcc. Of course, did they fix the bug?

    Nope.

    1. Re:amd64 binaries still crash on Intel EM64T by fruity_pebbles · · Score: 1
      I reported this too. My bug was rejected as being a duplicate of another bug. That bug is marked "closed, duplicate", but the bug that it's supposed to be a duplicate of is marked "not available". Is Sun trying to do a cover-up?

      The Windows AMD64 JDK 1.5.0 works fine on Intel EM64T.

    2. Re:amd64 binaries still crash on Intel EM64T by nvrrobx · · Score: 1

      My bug was marked as a duplicate of your bug and closed. I can't even find my bug in there anymore.

      Their FAQ says: Some bugs are not included in the Bug Database for security reasons.

      Umm, what security reasons? I posted about this on one of the blogs on java.net yesterday. Chances are it'll be ignored also. :(

  133. Native execution and such by Anonymous Coward · · Score: 0

    My Name is Jon, for all who care. Three things:

    First, if you really really want to run a java program as a native .exe on windoze or as an executable on Linux, you may go download a program called Excelsior Jet. It will compile jars and classes to native machine code. (breaking the whole theme of java... but i admit, the initial startup time is slightly accelerated)

    Also, I wish people(Linux users) wouldn't bash sun. If Linux is going to survive, it's going to need corporate backing. We've got IBM, but sun sort-of wavering towards Linux. However, I'd hardly call sun and Microsoft partners, otherwise sun's "Project Looking Glass" would probably be developed for windows instead of Linux. Also, i don't believe Microsoft is enthused after coughing over $300million for the last sun vs m$ skirmish.

    Third, as mentioned (and previously bludgeoned to death), it's not C#. Enough said.

  134. Oh God please no. by Gordon+Bennett · · Score: 0, Troll

    This is another weapon in the OO programmer's arsenal to bore the living daylights talking about it to any hapless individual who had the misfortune to ask what they do. Why wasn't this release checked by the UN? We should be told.

  135. Re:Poor Indecisive Sun by Chreo · · Score: 1

    "I think the real problem is brand recognition."

    I agree completely and that's because people will not know what to call it. This release was supposed to clear up the name-version confusion of the Java2 1.x.x releases by being called 5.0 but they still use Java 2 and 1.5.x in their naming. Clearer? I d'unt think so

    --

    Life is what happened when Good Intentions met Harsh Reality (the brother of the more infamous Chaos).
  136. The real licensing problem by Anonymous Coward · · Score: 0

    Seems like the real problem is that software installs on Linux are the suck. On Windows you say 'here click on this .exe' and then they've got Java and they can double-click the .jar file or open your app directly from your site using JNLP / WebStart.

    1. Re:The real licensing problem by mattdm · · Score: 1

      Seems like the real problem is that software installs on Linux are the suck.

      I know you're trying to troll, but you're actually exactly right. Software that is prepared nicely for installation on the distro I work on is incredibly easy to install even for a non-technical user. But Sun doesn't distribute Java in a convenient way, and they don't allow me (or anyone else) to make it convenient, even though I would if I could.

  137. Java's main problem.. SYNTAX! by nandu_prahlad · · Score: 1

    Most programmers are apathetic to the chest beating of language zealots. They don't have strong likes and dislikes, prefering to use the right tool for the right job.
    I am of a similar disposition except that I have very strong feelings when it comes to java.

    It has some laudable features like portability etc. Also java doesn't extract as heavy a price for errors (eg buffer overflow) unlike C, which demands a greater level of caution while programming. This is not necessarily a bad thing.

    What really bugs me is it's syntax.
    Any language will want to use the most simple, efficient syntax for the most commonly used words/operations. An example could be 'the', 'a', 'at' etc in the English language which are some of the words used most frequently.

    Complexity in language cannot be avoided. Sometimes in order to convey a very convoluted logic or some subtle meaning, you can only do so by using words that are more complex than 'the', 'at' etc.
    But what is the hallmark of a good language?
    It is not one that avoids complex constructs altogether(Complexity cannot be avoided). But rather one where the complexity of the language syntax is proportional to the complexity of the message.
    In other words, it should allow you to express simple ideas in simple syntax. And complex ideas in not so simple syntax. It is in this respect that Java performs badly.

    Consider doing something basic as printing "Hello World" on to the terminal.
    c: printf("Hello World");
    java: system.out.println("Hello World");

    I mean it's great if you want to use Object oriented programming. But making a programmer type all that is just bad design. No amount of extolling the virtues of object oriented design can change that.
    Java does a terrible job of hiding it's complexity from the programmer.

    Let's take an example of something fairly commonplace like connecting to a database.
    This is something that one finds so frequently in code written by programmers the world over.
    Just compare java (sun.jdbc.odbc....blah blah) to PHP's clean syntax.

    I am tired of the java is good/bad debate. I think the ideals that java was meant to achieve, like portabilty etc., are very laudable. But syntax is something that the designers got dead wrong.

    Cheers!

    prahlad
    1. Re:Java's main problem.. SYNTAX! by valkraider · · Score: 1

      Consider doing something basic as printing "Hello World" on to the terminal.
      c: printf("Hello World");
      java: system.out.println("Hello World");


      Thats your gripe? Well, first of all - a good IDE or editor will do command completion, reducing the typing quite a bit.

      And without them - you are free to implement all the syntax you want. For example, make yourself an object and have a method called "sop". Then include that object, and all you have to do is call "sop("Hello World");" There, better.

  138. The problem with .NET development by ravenlock · · Score: 1

    The biggest problem with .NET development seems to be ease of disassembly. IlDASM produces (I admit I tested it with simple classes only) damn near 1:1 sources from a compiled assembly.

    Ever wonder why Microsoft products such as Office aren't written to run on the CLR?

    1. Re:The problem with .NET development by Anonymous Coward · · Score: 0

      JAVA suffers from a ver similar fate.

      Bytecode obfuscators for JAVA and .NET are everywhere.

      Office is a huge munch of C/C++ code which like any other large project is not going to just jump ship to another language. It would be insanely expensive and for no real benefit.

  139. I hope they aren't going to call it "Java 5" by JavaLord · · Score: 1

    I really hate the way Sun promotes their versioning. Have you ever tried explaining to someone new to the language that Java 2 is really Java 1.2 or whatever version it was?

    JavaNewbie- "Why are we using Java 1.4, hasn't Java 2 been out for a long time"

    Me - "AAAAARRRRRG"

  140. Re:J2EE -- 1.3.1 still by sava · · Score: 1

    ... and because WebSphere and JBoss fight in very different level, say, you wouldn't build huge distributed enterprise portals on top of JBoss.

    --
    //SaVa
  141. SLOW by Surt · · Score: 2, Insightful

    Bah, each new release I try hoping they'll do something about the speed since I like the language better than c/c++.

    Since 1.0 there have been three major speed holdbacks preventing me and many others from adopting java:

    1) array access too slow due to boundary checking (no, their optimizer doesn't work for my cases, and this is a problem a lot of scientists/performance hungry people have).

    #1 has some good solutions on 64-bit platforms developed at the university of georgia, but sun won't include them, nor will they enable a flag on the jvm to turn of bounds checks. GCJ lets you do it, but can't compile everything I need yet.

    2) casting raw memory to objects requires a copy. Java needs a structured object without a header to overcome this, such as the struct proposal, which is in the top 25 rfe's yet has no comment from sun.

    #2 has a well understood solution that sun is apparently too lazy to even consider implementing.

    3) No way to do fast 2d/3d rendered graphics. Too many call overheads & copies.

    Sun needs to ditch AWT/Swing, and probably needs to open source java to overcome this. They've proven their inability to keep up a reasonable mapping to modern featuresets.

    I'm probably going to have to give up and learn c# since I'd like a more modern language with good tools, but java just doesn't have the speed.

    --
    "Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
    1. Re:SLOW by iapetus · · Score: 1

      How does the well-understood solution to #2 address type safety and memory management, out of interest?

      As for #3, there's a speed up to be had in 2D by using OpenGL acceleration - check elsewhere in this discussion for how to enable it (or RTFM).

      --
      ++ Say to Elrond "Hello.".
      Elrond says "No.". Elrond gives you some lunch.
    2. Re:SLOW by joib · · Score: 1


      1) array access too slow due to boundary checking (no, their optimizer doesn't work for my cases, and this is a problem a lot of scientists/performance hungry people have).


      Yeah, well that's why over here in the real world we use Fortran for numerics. ;-)

      Although some misguided souls use C/C++, but that has its own share of problems.

    3. Re:SLOW by Surt · · Score: 1

      type safety isn't much of an issue since you only have primitives. memory is allocated until all cast structs and the base holding object all release. this isn't rocket science, other languages have it.

      the new ogl speedup is a nice improvement for general apps, but is tangential to the problem of high performance graphics.

      --
      "Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
    4. Re:SLOW by MemoryDragon · · Score: 1

      Points1 and 2 are valid if you want to do high performance computing. #3 is not. If you need fast 2d rendering, use Java2d and use windows, or have a good graphics card handy and use the -Gjava2d.opengl=true flag. In both cases the hardware acceleration of your card will be used. As for fast 3d, you can have several options, either use Java3d or the JavaOpenGL bindings. Heck there have been programmed 3d games with that stuff, so if you have a speed problem there, you definitely have to check your card. (The OpenGL bindings basically just root into OpenGL with a thin layer on top of it)

    5. Re:SLOW by Surt · · Score: 1

      The performance though is not really acceptable, adequate yes and games have been done on this stuff, but it doesn't keep pace with what you can do on native platforms.

      --
      "Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
  142. Out of interest... by jeti · · Score: 1

    I personally have never liked Java, but it's hard to dislike... it's a nice syntax, and makes for nice clean code.

    I wonder if you ever programmed with a cleanly designed language? Say Smalltalk, CLISP or OCAML?

    (C++, JavaScript and VB do not count.)

  143. Books? by bunratty · · Score: 1

    What books are available that cover the new features in Java 5? I've been looking for the fourth edition of The Java Programming Language or the third edition of The Java Language Specification but haven't been able to find any reference to them yet.

    --
    What a fool believes, he sees, no wise man has the power to reason away.
    1. Re:Books? by Albert+Y.C.+Lai · · Score: 1

      I saw "Java 1.5 Tiger: A Developer's Notebook", O'Reilly, by David Flanagan and Brett McLaughlin. I have not looked into it in depth.

  144. Re:STUPID MODS by ElGuapoGolf · · Score: 5, Informative

    Are you aware that the vast majority of games you play on any phone (except Verizon phones) are written in Java?

    Thought not.

  145. Steaming CUP? by Anonymous Coward · · Score: 0

    While "steaming" is the correct adjective for Java, surely the correct noun is "pile"?

  146. Re:J2EE -- 1.3.1 still by Jason+Hood · · Score: 1

    Jboss does cluster just as well as websphere and weblogic. I know because I have run all three of them for very large projects. We got tired of paying for developer licenses let alone the production licenses.

    At this point all three ejb containers are on equal ground (Each with their own perks) with JBoss moving ahead the fastest. Even without the blessing of Sun. Currently we have 12 JBoss instances running in a cluster than has been up for 43 weeks. Cant ask for more than that.

    --
    Are you intolerant of intolerant people?
  147. Re:Okay, I'll Bite (a.k.a. "A Java Flame") by Anonymous Coward · · Score: 1, Interesting

    I'm veering off-topic here, but it's weird to me that a clone of Microsoft's clone of Java is easier to include in a Linux distribution than Java itself, from a licensing standpoint. I never compared the two in that light. Hmph.

  148. Re:J2EE -- 1.3.1 still by ElGuapoGolf · · Score: 1

    Also, it doesn't make me install *two* copies of the JRE like Sun does (one for development and one for the system JVM). So all-in-all, I like the IBM verison better.

    Is this a windows thing? On my linux install of Java, I have the JDK installed with only one copy of the JRE.

  149. They are called 'root objects' by nanter · · Score: 1
    If an object tree, no matter how large, cannot be traced back to a root object (an object which is directly referenced in the execution path via a variable reference), the whole thing is GCed.

    Like the parent says, this is superior to reference counting because these two circularly connected objects would have a reference count > 0 and thus would not be marked for collection.

  150. Re:oh great by Anonymous Coward · · Score: 0

    > I don't know why you tend to mispell "article" so often. Is this a running joke I'm not aware of? Or is it really an all too common mistake because of its pronunciation?

    *sigh* ... you're new here, aren't you?

  151. Turd Logo by otis+wildflower · · Score: 1

    I'm sorry, but that logo still looks like a steaming turd in a styrofoam cup to me.

    Whether that's intentional or not I leave as an exercise to the reader.

  152. Sugar != Bad by alacqua · · Score: 2, Insightful
    Carrying on down this path much farther, you become able to argue that C is just syntactic sugar for assembly language, and therefore assembly language is just as good.
    Actually, except for the standard assumption that sytactic sugar be an extension of a core language (and not a completely separate language), it's pretty much true that C is syntactic sugar for assembly language. But syntactic sugar is neither good nor bad in-and-of-itself. If a given instance makes programming easier to do and easier to understand then I'd say it's good.
    --

    Move on. There's nothing to see here.
    1. Re:Sugar != Bad by notwrong · · Score: 1
      I know this is a bit pedantic, but I'm not so sure that C does count as just syntactic sugar on top of assembly language, whatever path of reasoning you follow.

      I would argue that there are valid, useful sequences that can be hand-coded in assembly where you could not write any C code that, when compiled, gave that assembly. This is not just confined to weird trivial examples - if you are writing for particular capabilities of a processor, or have some crazy dogma about how you would like registers to be used. An optimising compiler might do a better job than a person could in some instances, but that doesn't make them identical.

      Yes, you can put inline assembler in C, but that just goes straight through, and doesn't have to follow the standards, so it doesn't count.

    2. Re:Sugar != Bad by alacqua · · Score: 1
      I don't think the question is whether you could code something in C that compiles to the same string of bits as any given hand-coded assembly routine. I think the question is whether you could code something in C that, when run, produces the same output/external behavior as the hand-coded assembly. I guess what I'm thinking is that any Turing-complete language is (in the admittedly strained sense of this discussion) syntactic sugar for a minimal set of instructions on the chosen platform.

      But we are far afield from the original point. Calling something syntactic sugar does not necessarily mean that something is bad for a language in some way. It's just means that there is another way, using a more minimal set of instructions (in a possibly ugly and convoluted way), to do the same thing.

      --

      Move on. There's nothing to see here.
  153. Whats 1.5 and whats 5? And what is meta data?? by formal_entity · · Score: 1

    What package/thing is now 5.0 and what package/thing is now 1.5?? Exactly what is this "meta data" about? The SUN site only points to some obscure specification document that tells me nothing about what meta data actually is good for.

  154. GREAT JUST GREAT... by DA_MAN_DA_MYTH · · Score: 1

    I got my 1.4 certification a month ago...

    --
    "It takes many nails to build a crib, but one screw to fill it."
  155. This is a perfect example of a simple error. by Estanislao+Mart�nez · · Score: 1
    This could be fixed by inserting "hugeObject = null" right before while(true){...}.

    There is a much more appropriate fix. You see, the code that you wrote there is doing *two* different, relatively unrelated things. This means it should be split up into more than one method. In particular, just refactor the code that deals with hugeObject into a separate method: when the method returns, the reference is destroyed automatically.

    "Functions should be short and do just one thing" is a very common principle that's pushed in the name of style, but in a garbage-collected language, it's more than just that: it's a way of implicitly managing memory.

  156. rejava by Doc+Ruby · · Score: 1

    Can I just plug in the new 1.5 in my Tomcat sever? Will my old servlets just get better with the new VM?

    --

    --
    make install -not war

  157. Netbeans 4.0 Beta 2 by fforw · · Score: 2, Informative
    Netbeans 4.0 Beta 2 was also released today, giving people who want to try to ride the tiger a matching IDE with full language support:

    Netbeans 4.0 Beta 2.

    J2SE 5.0 bundled with Netbeans.

    --
    while (!asleep()) sheep++
  158. Java 1.0 by magic · · Score: 1
    I fondly remember the days when Java was a simple language. Now it looks harder to use than C++ and has bizarre syntax.


    -m

  159. No you should be writing it in COBOL by Anonymous Coward · · Score: 0

    And that's what's wrong with java today - it's the new COBOL.

    There's nothing wrong with COBOL (or Java) in and of themselves. There's nothing wrong with payroll or invoice processing systems. They're necessary lubrication that keeps the wheels of commerce turning.

    But the hideous, cruel thing about java, is that it allows people who have been trained to bitflip the bare metal, to be shanghaied into doing those invoice apps. You can now make that long-haired hacker wear and business suit and jump and dance to your beck and call.

    And that's just inhumane. The old COBOL days were better - the suity business code grinders could stay in their world, and the long haired hackers could stay in theirs.

    And if you really want to know why people hate java so much, I'd say that's the biggest unvoiced reason.

  160. Re:J2EE -- 1.3.1 still by Anonymous Coward · · Score: 0

    You're right about getting a stand alone JDK for Windows, though you could also pull it out of the IBM Deployment Package for Eclipse
    http://www-106.ibm.com/developerworks/jav a/jdk/

    IBM States that they plan to support Java 5 (at the bottom):
    http://www-106.ibm.com/developerworks/ja va/jdk/oth er/portingplans.html
    The next major release of the IBM Developer Kits will be at the Java 2 Standard Edition version 5.0 level (previously referred to as 1.5.0), which includes significant functional enhancements as well as upgraded Java Virtual Machine and Just-in-Time Compiler capabilities. It is likely that the IBM 5.0 Developer Kits will become available during 2005.

  161. Re:oh great by Destoo · · Score: 0, Offtopic

    But Java is a dance.

    Rumba, Samba, Java... I'm sure you can think of others.

    It makes much more sense when you look at it that way. A slow, heavy, memory hungry dance..

    Actually, it's just a silly french dance, usually on a musette.

    --
    Nouvelles de jeux et technologies en français. TC
  162. Are they ever gonna fix... by guitaristx · · Score: 1

    the "we don't care if you use C++ exceptions as an key element of your architecture, you're f***ing screwed if you use them under JNI" bug? Yeah, I didn't think so.

    JNI is a joke. I love dev'ing in pure Java, but it royally sucks when you attempt a multi-language solution.

    --
    I pity the foo that isn't metasyntactic
  163. Re:J2EE -- 1.3.1 still by cheezit · · Score: 1

    With a very few lines of code you can have some of the "cast avoidance" of 1.5's generics.

    class StringToStringMap extends HashMap {
    public String get (String key) {
    return (String) get((Object)key);
    }
    }

    but as you say it is no help with iterators. Which is no surprise as iterators really don't make sense without generics.

    --
    Premature optimization is the root of all evil
  164. Generics != C++ templates by Kenneth+Stephen · · Score: 4, Insightful

    Generics in Java have a smaller scope, when compared to C++ templates. The objective in Java is to provide a type-safety mechanism for containers. In C++, it is much more than that. Unfortunately, it is this extra ability in C++ that makes for some really complex code. Not sure if this has already been mentioned in this story, but it has been theorized that C++ templates are themselves turing complete (though I havent seen a proof to that effect).

    I'm a bit puzzled by all the generics nay-sayers. I have tried out the feature, and they augment the language. I have yet to see a downside to this feature in Java (unless one counts the inability of the compiler to fully utilize the additional type-safety in compiler error messages). What is all the flap about?

    --

    There is no such thing as luck. Luck is nothing but an absence of bad luck.

    1. Re:Generics != C++ templates by Anonymous Coward · · Score: 0

      I'm a naysayer.

      There's no downside. The feature is cool, now I can do:

      String s = map.get(key); .. But did they have to change all the bloody libraries to get that little dinky convenience going?? Wasting resources that should have been fixing Swing, making the VM startup faster, or working on useable tools for the language.

      Rather than that, and risking people misusing this dinky feature I prefer

      String s = (String) map.get(key);

      Because I see the day when I have to deal with:

      Company company = new Company();

      and other unreasonable "features" in the code.

    2. Re:Generics != C++ templates by alder · · Score: 1
      What is all the flap about?
      Well, one of the biggest flaps is in implementation - specifically the "erasure" part of it. One could argue that generics in Java as they are implemented today are nothing more then a syntactic sugar - sweet, but relatively useless. Real sad because C# does it much better...
    3. Re:Generics != C++ templates by udoschuermann · · Score: 1

      Generics improve the reliability of code by allowing the compiler to catch programmer mistakes before they become deployment errors.

      No, Generics aren't C++ templates, but they are a significant step forward to help eliminate mistakes that a programmer's inattention can introduce into the code.

      Very, very good stuff!

      --
      --Udo.
  165. Not really. by BayBlade · · Score: 5, Insightful
    I've opted to reply to this rather than mod.
    While I think "write-once, run-anywhere" is a bit of a misnomer, it does actually live up to the hype, imho.

    You can't really appreciate it however, until you've spent weeks porting C code between platforms, and a few hours porting similar Java code.

    I've had headaches porting perl too (though I must admit its much better now). Things these days are much better for people *trying* to develop cross-platform applications in Java and a number of other languages and APIs, but when it gets sprung on you as a requirement late in the game (latter revisions, new customers, etc) porting a Java app is a godsend.

    There's alot of valid reasons to hate any language (I've studied 22 languages and in their own way, I think they all suck), but that particular reason doesn't apply to Java.

    --

    The key difference between a Programmer and a Senior Programmer is that one of them is Mexican.

    1. Re:Not really. by Anonymous Coward · · Score: 0

      Java's floating point number support does not exactly live up to write-once run-anywhere.

      I have written swing programs that are decent looking and useable under linux but for some reason unuseable in Windows. The JRE matters too much.

    2. Re:Not really. by Old+Wolf · · Score: 1

      While I think "write-once, run-anywhere" is a bit of a misnomer, it does actually live up to the hype, imho.

      Good to see someone cutting through the FUD, half of a java flamewar is about whether or not this is true.

      You can't really appreciate it however, until you've spent weeks porting C code between platforms, and a few hours porting similar Java code.

      Frankly, you should have written portable C code in the first place. The only porting required should be if you are using a non-portable 3rd party API and have to convert the code to use some 4th party API. Also if you feel nice you could add code to support some non-standards-compliant compilers.

      I do agree that the Java program will have the least work required in porting, though.

    3. Re:Not really. by BayBlade · · Score: 1
      Well, you have to appreciate there are two float libraries, one that ports well, and one that performs like there is a floating point processor on the system.

      As yourself which is more important, becasue if you're porting it, you're milage will be no better than with C from intel to mips, and both libaries use the same API anyhow, so its even easy to port from on to the other.

      A better gripe is the 64-bit limitation, when we should be doing calculations at 80 or even 128 bits like on intel.

      For swing, the outcome is largely dependant on the PLAF you use. There's a few odd behaviors, especially with frames and windows on Mac, or when repaints get called, but nothing you can't wade through in an afternoon.

      Try it sometime wih say, MFC or GTK. and let me know how that works for you.

      --

      The key difference between a Programmer and a Senior Programmer is that one of them is Mexican.

    4. Re:Not really. by BayBlade · · Score: 1
      Frankly, I've never ported my own C code, and if I expect there's ANY chance of my own getting ported, it weighs heavily into chosing the language and APIs for the developemnt platform off the bat.

      What's unfortuante, (as I'm sure someone named OldWolf would know) is the people who make the decisions, are seldom the people actually doing the work.

      I agree. And (And never start a sentance with and!) don't think I can't out-"should-have" you on many a project I've had to work on, because for the first few years after I graduated, I was the poor bastard who always got assigned to clean up other people's messes, document everything, and address the requirements that requirements gathering missed.

      Software Maintenance--what doesn't kill you, only makes you stronger.

      --

      The key difference between a Programmer and a Senior Programmer is that one of them is Mexican.

    5. Re:Not really. by Anonymous Coward · · Score: 0

      Well for better or worse the problem application did not touch the PLAF stuff- it was all defaut stuff so I would expect it to work. I was pressed for time and since it did work on Linux I just gave my presentation using Linux. I have been meaning to go back and find the problem but I do not exactly have access to a good Windows machine. Now since my brother has a Mac I can also see what it looks like on there (when I tried on the Macs at school I did not realize that a gui application cannot be started from the terminal). Might be as simple as calling repaint at goofy times, but I think I remember there being obvious geometry issues.

      There are wxWindows and QT, both of which are fairly platform independant. And for true portability you need to look to somethink like Squeak which runs bit identical regardless of the underlying platform.

    6. Re:Not really. by Old+Wolf · · Score: 1

      Ah fair enough then. I quite like cleaning up other people's mess though, as I get the chance to feel intellectually superior when I produce better code. Terrible isn't it :)

      And BTW, we are talking English here, not Latin.

  166. All but one stolen from Java by SuperKendall · · Score: 1

    I think you could say metadata may not have gone in without C#, though even there Java had Javadoc tags long before C# showed up.

    But pretty much all the other features you listed have been in the works a long time. Generics has been roughly ready to go for years now (yes, years) but took a long time to work through the JCP.

    So yes it's nice that C# could pick and choose from tasty looking items in the JCP. But that does not mean that since .Net was out first they were the first to think of them.

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
    1. Re:All but one stolen from Java by gh · · Score: 1

      though even there Java had Javadoc tags long before C# showed up.

      Personally, I found that to be an abuse of the javadoc feature, but to each there own.

      But pretty much all the other features you listed have been in the works a long time.

      Most of the features aside from generics did not even start the process until late 2002. C# already was already in production, let alone be considered under development.

      Java did have a leg up with generics in that they started back in '99 and there were research implementations preceeding that I think as far back as '97.

      I believe the generics support in C# was under research at the time of the release of .NET 1.0, but that was easily years after any of the similar Java generics projects.

    2. Re:All but one stolen from Java by SnowZero · · Score: 1

      But that does not mean that since .Net was out first they were the first to think of them.

      You do realize that there aren't really any features in either Java or C# that are new, right? They pretty much all came from other languages. Smalltalk, ML, Lisp, or Eiffel came up with nearly every one of the features people harp about now. It's nice when features break into common languages from their esoteric ancestors. However in general its a fallacy to think that the currently popular languages invented them.

      For example, I do almost all of my programming in C++, but there isn't a moment I don't respect SML functors for being everything that C++ templates aren't (that is, they are the most elegant implementation of generics I've ever seen).

  167. Languages are not the same as Word processors by Anonymous Coward · · Score: 0

    Maybe when you buy your Word processor or CD burning software you look at how many features one has that the other one doesn't and decide.

    With languages you need to look at style, at the design philosophy and the needs you have. It is not true that the language that has ALL features will be the best language.

    For me Generics were a poor addition to the language. Java is OO in style. If you want C++ generic algorithms, etc.. USE C++!!!

    No language will ever be perfect (except maybe Smalltalk ::) ), so live with the design. Adding this w/little usefulness (like Generics) does not enrich the language, it blurs the design philosophy.

  168. C++ templates and turing completeness by joe_plastic · · Score: 1

    I haven't seen formal proof but I have seen people use templates to compute the gcd(greatest common denominator) of two numbers at compile time for example. boost has a lot of interesting things that use advanced template kung-fu.

  169. I wish I could install it!! by maddmike · · Score: 1

    I tried installing JDK1.5 on my workstation but, the installshield recognizes drive's with large free space( >4gb) as negative drive space and won't install it.....!!! DOH! I wish there was a zip file I could just DL.

  170. NOT INSIGHTFUL..... IGNORANT!! by Anonymous Coward · · Score: 0

    You almost NEVER nullify references, you let them go out of scope.

    A more honest criticism of Java resource management is the need for finally when calling a close() method in cases where those resources represent external things (like OS resources, db connections, etc..).

    But you have these problems in C++ too..

    The original post is right though.. Java programmers can forget Amin's law of lists:

    "If your program adds something to a long lasting list, it better have a way to remove it"

  171. If I were driving this at Sun by melted · · Score: 1

    I'd just say, "aw, fuck it, we're dropping Java and adopting Mono - it's a better design". But no, they're too full of themselves, and for this you loyal followers will get endless pain of typecasts and boxing-unboxing (AKA Java generics).

  172. Re:I, for one by Sheepdot · · Score: 1

    Actually, no. I realize that the "I, for one, welcome our * overlords" is a popular phrase on /.

    The fact that people overuse this phrase when talking in general simply astounds me, however.

  173. OOP works when you don't know everything by GunFodder · · Score: 1

    OOP can be less efficient to work with if you are talking about a project with one programmer who knows everything about the codebase and the platform.

    Real projects have multiple contributors, multiple phases, and use external libraries. OOP makes interfacing with unknown code easier. Java in particular enforces code naming and library placement rules that guarantee you can always find a bit of code you are trying to use.

    You could reproduce this structure with a non-OOP language like C, but since it takes time and effort developers often don't, and therfore create code that is hard to add to and hard to maintain. Obviously there are exceptions to this rule; a handful of large open-source projects come to mind.

    PS: the parent comment is a troll, but it is also a perfectly valid opinion and therefore should .

    1. Re:OOP works when you don't know everything by Chrax · · Score: 1

      If it was a troll, it wasn't meant to be. I just have trouble seeing what other people see in Java. Having tried it myself, and the things that were simple in C were made more complex than they should have been when implemented in Java. Also the inability to deviate from the object orientation is a killer for me. It seems to take away from the actual code and simply focus on the structure. When I call it inefficient, I mean that when I write a perl script (a self-proclaimed inefficient language) to implement the same things I've seen done in Java (admittedly very low level, as I haven't gotten into hardcore Java, primarily because of the repulsion I've had from early experiences) the perl script runs faster. Anyway, just thought I'd explain, because apparently I came off worse than I meant.

    2. Re:OOP works when you don't know everything by shutdown+-p+now · · Score: 1

      Cross-platform framework. That's what is most valuable in java. All those things like Swing, JDBC, JDNI... you don't have it in C/C++. Language itself is far from perfect, but it's bearable if you consider the benefits provided by its framework.

    3. Re:OOP works when you don't know everything by ttfkam · · Score: 1

      Sounds like you were trying to code C in Java. In almost every case, less code is required in Java than in C. The same story with Perl. You absolutely cannot make a direct translation. Between Perl and C, the lines are pretty clear. Between Java and C however, the differences between the two can really come around to bite you in the ass.

      Think of Spanish versus English. If I were to say, "Me duelen los pies," any Spanish speaker would understand what I was talking about. Let's make a direct translation to English: "Me they hurt the feet." Given sufficient patience, an English speaker could figure out what you were talking about, but it's definitely not clear. "Oh!" you say in English, "you mean, 'My feet hurt.'" To which the literal translater passes back to the Spanish speaker, "Mis pies duelen." To which the Spanish speaker recoils half expecting you to kick him. Humor ensues.

      String is not just a sequence of bytes (and characters are two bytes long, not one or variable). Vector/ArrayList reallocations double the memory when it gets full (just like std::vector). Vector/ArrayList are effectively the same speed as a fixed size array, so avoiding them for efficiency is usually pointless (like std::vector). "instanceof" is slow. Reflection is slower. Reuse of long-lived objects is important. I/O should almost always be buffered.

      String output = "";
      for (int i=0;i<1000;++i) {
      output += "key=" + myKey + ";value=" + myValue + "\n";
      }
      System.out.println(output);

      Coming from C (and getting past the initial horror of Strings getting concatenated with the '+' operator), it looks perfectly fine syntactically and runs like an absolute dog. But just as my earlier English/Spanish example, to a Java programmer, it's obviously a problem. (Perhaps compilers in the future will become smart enough to handle this and more complex items.) Remember, Java String objects are immutable. This example is gratuitously slow because multiple implicit StringBuffer objects are created and destroyed. Use StringBuffer explicitly here instead.

      StringBuffer output = new StringBuffer();
      for (int i=0;i<1000;++i) {
      output.append("key=").append(myKey).append(
      ";value=").append(myValue).append("\n");
      }
      Syste m.out.println(output);

      The reworked version is much faster as the buffer will simply reallocate as space is needed as opposed to recreating and destroying multiple buffers on each loop. However, to inch out a little more speed, we can fall back on some of our old C habits such as preallocating a buffer.

      StringBuffer output = new StringBuffer( 16000 );
      for (int i=0;i<1000;++i) {
      output.append("key=").append(myKey).append(
      ";value=").append(myValue).append("\n");
      }
      Syste m.out.println(output);

      Now dynamic memory allocation is at a minimum. This works if we know that the keys and values are all eight characters or less for example. Well... technically it works even if they're not. It's just that the StringBuffer will reallocate the memory if the buffer fills up (as opposed to getting a buffer overflow in C).

      But this is more of the mundane and somewhat cryptic aspects of Java. The reason I like it is the interfaces, pure and simple. When I want a database connection, I don't code for a particular database. I code to the JDBC interfaces. When I want a thread, I don't hunt for a cross platform thread library or choose between POSIX flavors and Win32. I get a Thread. When I want to work with XML, I use the W3C DOM interfaces or SAX interfaces. The databases may change. The operating systems may change. The parsers may change. But the interfaces stay the same. If I need to use database-specific features, I can. But it is abundantly clear in the code what is the standard inteface and what is a driver extension.

      Then there's javadoc. Once you get used to one set of documentation, you've gotten used to them all. If yo

      --

      - I don't need to go outside, my CRT tan'll do me just fine.
  174. Re:STUPID MODS by pediddle · · Score: 2, Interesting

    So are the vast majority of internet games. I don't go a day without seeing somebody play poker, pool, or fantasy football online.

  175. Steaming cup... by Anonymous Coward · · Score: 0

    ... or steaming pile? The UI improvements are far from adequate. Please, Sun, admit Swing is a failure and make SWT part of the JRE!

    Also the new generics support has been implemented in a horribly ugly way. I'm dreading the day I have to debug code written using generics.

  176. Ok Billl by SuperKendall · · Score: 1

    Nap time again!

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
  177. Actually there are a lot of apps by SuperKendall · · Score: 1

    There are a lot of apps - as others have noted, there are IDE's - JBUilder is one, but also Eclipse and Netbeans re good examples.

    Then there is TogetherJ, a great modeling tool...

    As far as consumer apps, Limewire is a wideley used example. If you look on sourceforge you can also find a lot of other applications. I had also thought there was a Java frontend for OpenOffice, but can't find that right now.

    I think that actually Java apps will start to become more popular on the desktop, in part fueled but the popularity of Java for cell phone programming!

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
    1. Re:Actually there are a lot of apps by Anonymous+Writer · · Score: 1

      As far as consumer apps, Limewire is a wideley used example.

      That's a good example, I didn't realise Limewire was made with Java. However, does it need some modification for each platform? You still need to download a different file for each platfom. I'd like to see software use just one installation package for different platforms, so you can download the same file or use the same installation CD Rom and have it work.

    2. Re:Actually there are a lot of apps by Anonymous Coward · · Score: 0

      The different files for most Java applications are actually just different installers that respect various platform conventions for installation systems (where such exist, e.g. the Windows Installer). Core application files are (or should be) the same irrespective of where they run.

      I think it's unlikely that Java will be used heavily for mainstream consumer applications while Windows retains its overwhelming dominance in this sector. Developers can after all reach around 95% of the consumer audience by writing for Windows alone, and they can leverage all the platform-specific features directly using highly productive development environments from the likes of Borland and MS.

      Things are of course different on servers, which utilise a wide range of hardware and operating systems. Java's capability to run on all the major platforms is a big plus here, as is the fact that it will transparently scale to multi-parallel n-bit systems. It has a plethora of IDEs (commercial and open source) that ease the job of writing, debugging, _and_ documenting complex, multi-threaded applications, and an incredible variety of commercial and open source add-ons, tools, and even alternative JVM-targeting programming languages that combine to make server-side development in Java a notably pleasurable experience.

  178. MOD PARENT UP by Milo77 · · Score: 1

    setting reference to null in java is stupid, stop saying it...

  179. What are "WeblogicBeans"???? by SuperKendall · · Score: 1

    It still sounds like something funny is going on there, do you mean JavaBeans or EJB's? They are not Weblogic specific.

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
  180. Re:STUPID MODS by aled · · Score: 1

    I have run the same webapps in windows, linux and IBM iSeries without changing a comma, but I understand that mobile devices may be different.

    --

    "I think this line is mostly filler"
  181. java 5? no. by dynamo · · Score: 1

    What kind of idiot decides to use "Java 5" as an alias for "Java 1.5"??? Are we Diebold? The same crap happened with Java 1.2. Why do intelligent people accept this marketing bullshit?

    When "Java 2" came out I had the same objection and still do. What the hell? When the real Java 5 comes out, are we gonna call it Java 50?

    Wake up people! Computer savvy people should know about how numbers work.

  182. Re:J2EE -- 1.3.1 still by aled · · Score: 1

    There's one inside the jdk, but I don't see as a bad thing.

    --

    "I think this line is mostly filler"
  183. Unless.... by douglips · · Score: 1

    They are using Eclipse. In which case, the IDEA user is missing out on that $800.

    Wow! I'm having emacs vs. vi flashbacks! Except vi is also free...

    1. Re:Unless.... by tobinibot · · Score: 1

      $800? Ummmm, check your prices again. It's $500 normally, and they have deep discounts for personal licenses a couple of times of year.

    2. Re:Unless.... by EvilSuggestions · · Score: 1

      But wouldn't the discount have to be somewhere in the neighborhood of 100% to beat the price of Eclipse?

      --
      "There is a thin line between ignorance and arrogance, and only I have managed to erase that line." - Dr. Science
    3. Re:Unless.... by ZenShadow · · Score: 1

      You get what you pay for, in this case. Based on the brief experiences I've had with Eclipse, IDEA flattens it.

      Of course, my favorite thing about it isn't all the refactoring tools, it's that it properly supports emacs editing keys (after being tweaked in a couple of places)... But that's just me ;)

      For

      --ZS

      --
      -- sigs cause cancer.
    4. Re:Unless.... by douglips · · Score: 1

      Did you miss the part where I said this is just like emacs vs. vi?

      Based on the brief experiences I've had with IDEA, Eclipse flattens it. Remember, the plural of anecdote is not data.

      And, you can ask Eclipse to use emacs keybindings.

      And you can download open source plug-ins for Eclipse to do things like edit/debug perl/c/c++/cobol/eiffel/groovy/python/ruby/etc. You can use aspect-oriented programming with AspectJ.

      You can write your own plugins for whatever you need Eclipse to do (sound like emacs?) And it doesn't cost a penny.

      $500 for IDEA? I'll buy two iPods and download eclipse, thanks anyway.

    5. Re:Unless.... by ZenShadow · · Score: 1

      Oooooh, school me, why don't you.

      I posted my opinion. Remember, having a different opinion does not mean that you have to be a condescending jackass.

      If I felt strongly enough to enter a *holy war* on Eclipse vs. IDEA, rather than entering my opinion, you can bet your ass Id've backed it up. The sad fact, however, is that I have better things to do than fight holy wars over text editors or development environments.

      And if you can't afford $500 for a kickass IDE that you'll use constantly, then get your employer to buy it for you. Works for me.

      Oh, it might surprise you to know that I use both emacs *and* vi.

      --ZS

      --
      -- sigs cause cancer.
    6. Re:Unless.... by douglips · · Score: 1

      Well, I didn't think I was too far out of line interpreting "You get what you pay for" as condescending jackass, but you're right, this isn't worth a holy war.

      I have a friend who regularly uses both eclipse and IDEA, his thoughts are "use the right tool for the job". And, he's right, even vi has it's uses. For example, you may need it to be able to build emacs. :)

      Like any other holy war, it boils down to opinion, and you're right - if you like it, it's worth the $500. Especially if it isn't your money.

    7. Re:Unless.... by SpryGuy · · Score: 1

      Well, imho, IntelliJ IDEA offers more than Eclipse, so it's worth the extra cost.

      --

      - Spryguy
      There are three kinds of people in this world: those that can count and those that can't
  184. Comment removed by account_deleted · · Score: 1

    Comment removed based on user account deletion

  185. Are you sure that reviewuates correctly? by douglips · · Score: 1
    When perl reviewuates that code on the line
    public void renumberList(MyList list)
    what will happen?
  186. Not to ask a stupid question... by Anonymous Coward · · Score: 0

    ...but i'm gonna ask a stupid question:
    Does this affect end users, or just developers (i.e. will downloading this make Azureus run faster/crash less)?

  187. Re:hmm. but how does this compare with Mono by MemoryDragon · · Score: 1

    Will it? You cannot forget about several things. First they have the advantage of having the huge Microsoft marketing machine indirectly behind their backs. Secondly Iczaza is an excellent marketing guy for his projects. Third java always was and always is uncool because it is not OSS and it is by Sun (believe me, the name Sun gives you the complete hatred of the Microsoft zealots)

    The main problem I see with Mono is, that if you code with that stuff you might end up with a solution which basically is dependend on the goodwill of Microsoft which has several core patents within the non ECMA parts of the library.

    Mono itself is an okish platform for development, the language is nice, and what they do in the non Microsoft parts might be good enough to get out programs. Because most programs dont really heavily rely that much on speed, you need good hooks into the underlying gui toolkit and you can cover 90% of the programs out there even with a really slow language.

    The main problem java had for a long time is, that it uses its own toolkit and in the beginning it was really slow (not anymore but thats another issue) So even if the language was fast enough for many purposes it ran into major problems from the user interface side of things.

    So they word of mouth that java was dog slow basically came from the early swing implementations. Probably most people wouldnt even notice a java program anymore nowadays, once it is properly skinned.

  188. Re:hmm. but how does this compare with Mono by miguel · · Score: 2, Informative

    Mono is slower than .NET in certain areas, but in
    some others it is a lot faster. The areas that
    get the most testing and use from the team are
    likely to be more tuned than the Microsoft
    counterparts (this is a nice benefit of using
    Mono to develop itself: we actually use it to
    maintain our own compilers, editors, and day-to
    day tools).

    You are mistaken about the JIT nature of Mono,
    Mono has an optimizing JIT engine with pluggable
    optimizations. You can control the level of
    optimizations using the -O flag to the runtime,
    and we support Ahead-of-Time compilation as well
    which means that you can turn on all the obscene
    optimizations (those who might be too expensive
    to do at JIT time, and that historically JITs
    had to implement by doing dynamic recompilation).
    In our case, we turn on all the expensive
    optimizations, and run the code natively, without
    a dynamic translation (like a JIT would do).

    Anyways, Mono has a dedicated staff to support
    and maintain it (16 developers reporting to me,
    plus other contributors from Novell in other
    areas of the VM) in addition to the 250 accounts
    for external contributors that continue to
    improve Mono.

    We are not in a quest to compete with Java, we
    bring something different to the table (and in
    fact, we even support Java in Mono ;-), but your
    statements are incorrect.

    Miguel.

  189. Re:hmm. but how does this compare with Mono by miguel · · Score: 1

    Your argument has a few flaws, let me explain.

    When GCC started, nobody thought that it could
    match any commercial compilers, but with a strong
    community and thousand of contributors it matched
    the best optimizing compilers of its time, it is
    a continuous race between compilers in general,
    and there is no end in sight here.

    Mono is repeating this story, we are tuning it,
    improving it constantly and most users can
    already appreciate a 30% performance boost from
    Mono 1.0 to Mono 1.1.1 (in only three months
    of development). We are also investing heavily
    in high end optimizations (and as I pointed out
    in a separate thread, we can afford this because
    of our AOT-compilation mode).

    But even if we always were to be slower than .NET, being dog slow has not stopped Java
    adoption in the past. Being slow in general
    has not slowed down interpreters like Python and
    Perl in the past: what mattered was the
    functionality.

    And to some folks .NET is fantastic, and if they
    can run it in MacOS, S390, SPARC and Linux all
    the better.

    That is your second flaw: that people only care
    about performance, they dont (but even then,
    we do, and we want to make Mono rule ;-)

    Love,
    Miguel

  190. Re:hmm. but how does this compare with Mono by metasyntactic · · Score: 1

    Could you post some links to back up your claim? Thanks!!

    -- Cyrus (http://blogs.msdn.com/cyrusn)

  191. Re:Java 5 or 1.5? by gumpish · · Score: 1

    How much confidence do you have in a product that has 5 major releases before it hits 2.0?

    Actually it's Java 2 Standard Edition 5.0

    (all marketroids must be destroyed)

  192. Remembering experience by zabuldyga · · Score: 2, Informative

    I used to work for a company that made a UML modeling tool. The earlier versions of it had been written in C++ and just about 8 years ago a Java version was launched. The decision that was made a year later was rather risky: to discontinue C++ version and switch to Java completely. This allowed to concentrate the development on just one product, which finally brought the success.

    Was Java one of the main reasons for the big success of the product and the company? Quite possibly so.

    Would the company have succeeded had not Java been chosen? Perhaps, with a bit of luck.

    If Java was such a crap as it's often depicted, would this be possible at all? I very much doubt it.

    1. Re:Remembering experience by amembleton · · Score: 1

      Is this product called 'Together' by any chance? Now owned by Borland. Together is probably my worst experience of Java.

    2. Re:Remembering experience by zabuldyga · · Score: 1
      Together is probably my worst experience of Java.
      Nonetheless it was (and is still) used by thousands of users worldwide, despite all its drawbacks. And I'm not aware of any other modeling tool that could come even close to it in functionality. Can you point at something better? RationalRose perhaps? I'm sure it was my worst experience with C++.
    3. Re:Remembering experience by MemoryDragon · · Score: 1

      Togehter is not the only one written in Java, Omodo comes to my mind as well as Poseidon/ArgoUML

  193. Re:STUPID MODS by Misch · · Score: 1

    Speaking of which, "Tournamet Poker: No Limit Texas Hold 'Em" is written in Java. The commercial package comes with Windows and Mac Installers. Sadly, the Linux installer isn't included on the CD and appears to be a separate download. I'm going to just copy the files over to my linux box and mess with the classpath to see if I can get it to run.

    The company that put it together (Donohoe Digital) is interested in translating other games to computer based games with their Game Development Framework (GDF).

    --

    --You will rephrase your request for me to go to hell. Goto statements are not acceptable programming constructs
  194. Great News by brsmith4 · · Score: 1

    I'm sure there are probably plenty of trollish or insightful statements regarding the language and its features, so i'm going for simple: It can use GTK2 themes and has Anti-Aliased fonts for Swing apps! Limewire looks like a gnome application now (not too mention it runs almost as quickly as one). This is what we need, cross-platform bytecode and cross-platform interfaces to common widget sets. Rock on!

    /* End hysteria... */

  195. Re:Okay, I'll Bite (a.k.a. "A Java Flame") by Nautica · · Score: 1

    Don't know what you have been installing, but mono is a pain in the ass to install via RPM, DEB or whatever. Java is simple. ./java-install.sh Done!

  196. Re:STUPID MODS by Misch · · Score: 1

    I'll follow up my own post and say that I just e-mailed the company, and they'll send me a link to download the Linux installer version.

    (yeah, a non-automated e-mail response in 3 minutes. Rock on.)

    --

    --You will rephrase your request for me to go to hell. Goto statements are not acceptable programming constructs
  197. Re:J2EE -- 1.3.1 still by Anonymous Coward · · Score: 0

    Yeah, but the post was titled "J2EE -- 1.3.1 still", which is INCORRECT. Did you read the title?

  198. Thou fool by Anonymous Coward · · Score: 1

    ArrayList vector = new ArrayList();
    while (someObscureEndlessLoopCondition) {

    vector.add(new SomeObject());

    }

    That actually brings the machine down. Not the VM. The real machine comes down due to excessive paging (commonly known as thrashing).

    I have been planning sometime to write on the problem that exists between garbage collection and paging.

    1. Re:Thou fool by Pinky · · Score: 1

      That does neither. Java has a max heap size. Deaful is 64 megs. It will grow 'till whatever the max heap size is then just throw out and out of memory exception and kill the thread.

    2. Re:Thou fool by angel'o'sphere · · Score: 1

      A standard VM only has allocated 32MB. Sot it does not "bring a standard machine down".

      Further more, as long as you only allocate memory and dont use it, there is no trashing ... because what is not referenced gets not paged back in.

      angel'o'sphere

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
  199. Re:Java 5 or 1.5? by lanc · · Score: 1

    Well, that's nothing new a sun, is it? DO you remember the Sunos, I mean Solaris, 2.6 I mean 5.6 or 5.8 I mean 8, I mean who knows what _they_ mean? forget it. get acquinted with saying 'current'.

    --
    "First they ignore you, then they laugh at you, then they attack you, then you win." -- Mahatma Gandhi
  200. Re:J2EE -- 1.3.1 still by tmasssey · · Score: 1
    Yes, this is a Sun-only Windows thing.

  201. Re:STUPID MODS by donohoedigital · · Score: 1
    We try!

    FYI, the first run of CDs didn't get the Linux installer for timing reasons, but we updated the gold master and Linux is on it now. It's hit or miss if you get the updated master.

    However, any person who purchased the product can get the Linux installer by emailing us their name, address and activation number. Support details and demos are at our ddpoker webpage.

    Thanks.

  202. Apple lag by ewg · · Score: 1

    That's strange:

    I just ran Mac OS X Software Update and it's not there.

    I'll try again in the morning.

    --
    org.slashdot.post.SignatureNotFoundException: ewg
  203. The enemy of my enemy is my friend by Anonymous Coward · · Score: 0

    Manus Deï> Therefore you should all be in love with Sun's Java Platform

    That sums it all...

  204. Freenet is fucked anyways by Anonymous Coward · · Score: 0

    Don't use that shit, the devs are so lame they don't know shit about what they're doin

    1. Re:Freenet is fucked anyways by amorsen · · Score: 1

      You're absolutely right, I've given up the Freenet project a long time ago. That doesn't change the fact that Java is broken too.

      --
      Finally! A year of moderation! Ready for 2019?
  205. Re:Okay, I'll Bite (a.k.a. "A Java Flame") by Espectr0 · · Score: 1

    Install slackware 10, it comes with java sdk preinstalled, ready to use.

  206. Re:STUPID MODS by chaoticset · · Score: 1

    The vast majority of the world's rice is grown in raw human waste. Doesn't make the rice inedible -- doesn't make the games unplayable. It doesn't turn the crap into gold, either.

    --

    -----------------------
    You are what you think.
  207. Re:STUPID MODS by ElGuapoGolf · · Score: 1

    It's called reading for context.

    Parent post to mine said he was "disappointed that it didn't live up to its advance billing and bring more applications to the various mobile devices I've used over the years". I pointed out that many, if not the vast majority, of mobile applications/games are java powered.

    I corrected the original posters misconception. I wasn't saying "Java rules, you drooling moron". I just said it's there, you're missing it. You came in with a feces comment. Bravo sir, Bravo!

  208. Freezope by ttfkam · · Score: 1

    I noticed the URL. For what it's worth, I think Zope/Plone is an excellent web framework. It has some warts that have really frustrated me (usually from 3rd party addons rather than the core), but overall well worth the time examing/using it. ...and let me tell you, when it works, it's great. When you need to see some API documentation for it, I start wishing for something more like javadoc. Yes, I've seen the automatic documentation from source for Python. While I found the functions easily, the weak typing in Python made what you pass to those function unclear.

    That said, the WebDAV support and object management are top notch. I'm glad I chose it for a project. There's no way I could have implemented another solution from start to finish in less than a month without it in any language (even Python).

    --

    - I don't need to go outside, my CRT tan'll do me just fine.
  209. STUPID STUPIDS by nazsco · · Score: 1

    Are you aware that most cell phones have a jvm so that you can run crappy games like 21 or slot machine? and that this just bloated the processing power and consecutively the price and degraded batery life?

    Besides, they're written in java because they're useless. they're put there in the last minute to please marketing folks. so the ppl that makes them (crapy soft houses) are aware and choose to develop in java. it would be oh-so-portable if they developed in basic for that matter since it's other people (cell phone programers) who have to write the jvm. i bet they would rater write a basic interpreter... By the way, are the genereal UI and even the camera thingy in java? no, cuz they were planned to be there, so it could be well developed. not just trhow there in the last minute.

    Cell phones gives cancer!

  210. Beware your 'first cup of Java' by Anonymous Coward · · Score: 0

    Java is not dying, despite what a lot of people think.

    The following is a very good explanation of the real reasons.

    Explanation.

  211. Java? Don't you mean a steaming pile? by Anonymous Coward · · Score: 0

    Of course, if you like to suck on the brown substance I suppose a cup would do. Go wild, get shitfaced.

  212. Who said anything about ML? This is _Java_ 5.0. by Trejkaz · · Score: 1

    Oh, I'm sorry. I thought we were talking about Java.

    In Java, you have the add(Object) method on the List interface. You need to get an int in. int is not an object. Time to box it. Either do it manually, or automatically, I don't care. Personally I would prefer automatically.

    Remember that the first requirement for 1.5 was that the existing bytecode still needed to work on the new VM. If they made List support the ML style of generics, they would have needed to break the VM pretty significantly. I'm not saying they shouldn't have, though... because it would be nice to be able to use List<int> instead of List<Integer>, sure, but like I said, since the majority of collections in REAL LIFE are not of primitive types, who really gives a fuck?

    --
    Karma: It's all a bunch of tree-huggin' hippy crap!
  213. You're missing the important thing, though. by Trejkaz · · Score: 1

    If there were a java.lang.NullPointerException, my code would have caught the exception. You can't catch segmentation faults.

    --
    Karma: It's all a bunch of tree-huggin' hippy crap!
  214. I know about that hack already. by Trejkaz · · Score: 1

    You're missing a couple of points with regards to that hack:

    1) (And the most obvious problem with the hack!) Not every user on a computer has Administrator privileges in order to write into the Windows system directory, where javaw resides... or even permission to write into the JDK directories. That is to say, some people work in (gasp!) offices, instead of posting naked on Slashdot as ACs from their homes.

    2) If you want to bundle SWT into your application, then your users need to be informed about this hack in order for your application to look modern. Do you really think that directing ordinary users to a Wikipedia entry and telling them to do it themselves is the appropriate course of action?

    Meanwhile, WX4J works natively, out of the box, with no such hacks. Why is it so hard for SWT to work the same way? Perhaps they just don't care, perhaps they are just too retarded to figure it out. I don't know.

    --
    Karma: It's all a bunch of tree-huggin' hippy crap!
  215. Oreilly's guide to Tiger by rexguo · · Score: 1

    If you need a more detailed (but not terse) guide to Tiger, try O'Reilly's Java 1.5 Tiger: A Developer's Notebook. It's one of those books with light-hearted writing style and nice simple examples written by dudes who really know the stuff.

    --
    www.rexguo.com - Technologist + Designer
  216. i use ... by Anonymous Coward · · Score: 0

    jCreator cause java sucks

  217. slackware 10 and java by mattdm · · Score: 1

    I downloaded the package from Slackware, and the tarball includes what appears to be essentially the same license (although with the truncated paragraphs complete). Unless there's some extra special dispensation (and I didn't find one), anyone redistributing this package (with or without Slackware 10.0) appears to me (IANAL) to be in violation.

    Does anyone have any furhter information on this?

    It's nice of Sun to turn a blind eye, but is that _really_ the attitude towards intellectual property we want Linux distributions to have? (Especially with Sun's dubious financial relationship with everyone's favorite company SCO?)

  218. Re:hmm. but how does this compare with Mono by lupus-slash · · Score: 1

    The MS license prohibits publishing benchmark data, but you can check for yourself, for example, the performance of Reflection.Emit (mcs, for example).
    Last time I checked we did better also in a few cli-grande benchmarks and, of course, we could write benchmarks that highlight where we're faster.
    Of course we have still work to do: anyone following mono development will find that the cvs version is already much faster than 1.0 and we have a roadmap page on the web site with details on the improvements we're currently working on.

  219. Re:Okay, I'll Bite (a.k.a. "A Java Flame") by lupus-slash · · Score: 1

    Just use the precompiled packages and apt-get or redcarpet.
    Also note that he was referring to licensing issues: mono is free software so it can be legally included in distributions. Java has some distribution restrictions.

  220. JCP date only official start by SuperKendall · · Score: 1

    A lot of the features were under discussion pretty well before the grab-bag JCP hit... I will say that C# helped light a fire under a few thngs like that, so from that standpoint it was helpful! Even generics they'd probably still be arguing about today, I still feel it should have been in 1.4.

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
    1. Re:JCP date only official start by Anonymous Coward · · Score: 0

      Maybe you need read some C# books to understand how superior it is to your coffee language, perhaps C# for Dummies?

  221. You can kind of do that now... by SuperKendall · · Score: 1

    There are actually a few differnt ways to achieve that right now. usually what people do is have an installation jar for Windows, possibly something for another platform - and then a self-extracting jar that runs the installer (Zero-G and other installers will make these for you pretty easily). On OS-X you can double-click a jar and just have it run, and on Linux you can say java -jar and run the installer that way. So, it comes pretty close to having just one installer and windows people all get the exe files they know and love.

    I forget but I think you can also double-click jar files on Windows once the JRE is installed.

    You can also install over the web via java web-start, then it will even download the VM for them. We do that internally with some Java apps, but I'm not sure how many people are making heavy use of that over the web right now (possibly Puzzle Pirates?).

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
  222. Yes of course... by SuperKendall · · Score: 1

    You do realize that there aren't really any features in either Java or C# that are new, right?

    Yes, it's true there is very little under the Sun which is new.

    However it's easy to see the varied parentage of Java, whereas looking at .Net (and the standard libraries especailly) there's more than a striking resemblance to a singular language.

    I'm not saying they didn't do a decent job refining some stuff that is in Java. I will say I consider it a terrific waste of time on everyone's part to work on erecting a Java clone instead of taking new directions with languages, like a next-generation functional language for the masses. Instead we get to damage the minds of impressionable youngsters with a horrific twist on MethodCapitalization and rewrite Ant just because we can.

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
    1. Re:Yes of course... by Anonymous Coward · · Score: 0

      (not-so)SuperKendall,

      You didn't get the point, C# is not a Java clone. C++ => Java => C# it is an evolution.

      Some came from Java (i.e interface), some came from C++ (i.e, operator overloading ).

      It is an evolution and it will continue on - maybe Java6 or C#/.NET3, maybe even a new language.

      Before you say anymore nonesense about something you don't know, please try to be humble and understand what is happening first.

      Otherwise, what you say is just crap.

      A. Coward

    2. Re:Yes of course... by SnowZero · · Score: 1

      Or C# goes nowhere, which is the fate of the vast majority of languages. Only time will tell...

  223. Wrong by greenrd · · Score: 1
    This does not work in Java because generics are implemented using erasure. So in this "any" type example, only methods of Object are callable.

    That's not correct.

    Java can do this too. All you have to do is do it the statically-typed way, viz:

    public <T extends SomeInterface> void foo (T o) { o.someMethod (); }

    1. Re:Wrong by mmusson · · Score: 1

      The whole point of generic programming is that you don't want to know the SomeInterface ahead of time. You have two independent libraries. An class in one library is not going to implement the required interface from the other library. Your only recourse is to wrap the class with a new class that implements the interface.

      From the standpoint of making the function generic, the T extends SomeInterface method is no better than simply making the function take an argument of type SomeInterface. The only possible advantage I see is for templated return values and again it's just to avoid explicit type casts. Note, this isn't even preventing a class of problems because misuse of the explicit type-cast still leads to a compile time error.

      Of course another unfortunate thing is that the syntax is inconsistent in that extends is for inheritance, and implements is for interfaces.

      --
      SYS 49152
  224. Re:hmm. but how does this compare with Mono by MemoryDragon · · Score: 1

    Miguel, thanks for answering in this thread. This question probably has been asked over and over again, but how are you guys are going to cope with the patent problem. I mean everything is dependend in parts of your projects on the goodwill of Microsoft (I am not speaking about the EMCA parts and your bindings into GTK2 and Gnome, but about things like WinForms or ADO, which war plastered all over with patents)

  225. Re:oh great by Anonymous Coward · · Score: 0

    you're new here, aren't you?

    And, of course, you decided that since he was new here, he didn't deserve an answer to his question. So I have a question for you: HTF is he supposed to learn if you don't answer his question? Answer me that, <troll>you dried stain on the toilet bowl of life</troll>.

  226. Re:oh great by Anonymous Coward · · Score: 0

    peopal here don't misspell artical.

  227. Re:oh great by NateTech · · Score: 1

    You're seeing the results of low standards American schools set when teaching the English language.

    Our President is a shining example. He supposedly graduated from a prestigous University and still has zero command of the language.

    --
    +++OK ATH
  228. Re:Okay, I'll Bite (a.k.a. "A Java Flame") by rjshields · · Score: 1

    Give me an environment that provides me with the following (or equivalent) and I'll convert:

    Servlets, JSP, Ant, JUnit, Tomcat, Struts, JSF, EJB, JDBC, Eclipse, garbage collection, write once run anywhere (yes, it really does work)

    I choose Java because no other platform offers me the productivity, for the kind of apps I write, that Java does. Show me the light and I'll gladly convert. Do you think you can?

    --
    In this world nothing is certain but death, taxes and flawed car analogies.
  229. You're right by GCP · · Score: 1

    Whoever moderated you as "flamebait" is just trying to silence truthful words that he doesn't want others to hear.

    I was a member of one of the JCP expert groups that worked on Java 5 (a.k.a. "Tiger" & "1.5"). I like Java as a programming *system* for certain tasks. I say "system" instead of language, because the big advantages are in areas other than the programming language, per se.

    Although I don't find the C# language exactly exciting, I definitely prefer it to Java. The language improvements over Java (again, *language*, not associated ecosystem) are based on years of complaints from Java developers--complaints long ignored by Sun for reasons of backward compatibility and due to design philosophies of some senior designers who want a language that is optimized for productivity in the hands of frequently-changing commodity programmers.

    Only the power of competition from C# has had the ability to shake the Java gods out of their committment to a frozen language. Sun is still committed to a frozen bytecode/JVM design, while Microsoft is not, so the gap is likely to widen, not narrow, while Java is likely to remain more widespread (new code will run everywhere on all of the old JVMs).

    I prefer Java's portability and developed ecosystem, but I definitely prefer the C# language features, so I'm hoping that Mono will succeed at making C# much more portable.

    Of course, for language only without consideration of the associated ecosystem (implementations, libraries, programmer availability, etc.), I most enjoy really dynamic languages like Lisp and ML, but whaddya gonna do....

    --
    "Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
  230. Whatever. by Anonymous Coward · · Score: 0

    You chose the right name, dude.

  231. generics by cbr2702 · · Score: 1
    The official way to implement

    public <T> void foo(T o) { o.somemethod(); }

    Is to write"

    public <T implements SomeMethodable> void foo(T o) {o.someMethod();}

    This is not a great soltion, though, as you might as well just write:

    public void foo(SomeMethodable o) {o.someMethod();}

    The point here is that this was delt with with interfaces, and this isn't where generics help.

    --


    This post written under Gentoo-linux with an SCO IP license.
  232. Comment removed by account_deleted · · Score: 1

    Comment removed based on user account deletion

  233. Re:oh great by perseguidor · · Score: 1

    Then sorry about the comment, I didn't want to be offensive : ).

    It's just something that I find intriguing.

    --
    O make me a mask