Slashdot Mirror


Java's Backup Plan If Oracle Fumbles

GMGruman writes "In an InfoWorld blog, Paul Krill suggests that those concerned that Java might get lost in Oracle's tangle of acquired technologies should relax a little: Java's future isn't wholly in Oracle's hands, so if Oracle screws up or lets Java languish, the popular language has other forces to move it forward nonetheless."

276 comments

  1. What could possibly go wrong ... by Noam.of.Doom · · Score: 2, Informative

    ... when being owned by Oracle?

    --
    It is the universe that makes fun of us all.
    1. Re:What could possibly go wrong ... by hotfireball · · Score: 1

      Java is not owned by Oracle.

    2. Re:What could possibly go wrong ... by Noam.of.Doom · · Score: 1

      That was supposed to be a sarcastic comment, but doesn't Oracle own any IP of some sort regarding Java? Patents? Trademarks?

      --
      It is the universe that makes fun of us all.
    3. Re:What could possibly go wrong ... by Big+Jojo · · Score: 5, Informative
      Go away troll....

      Microsoft was entirely within its rights to extend Java to provide native support for Windows O/S. The lawsuit was ridiculous and wrongly decided.

      The issue was violating the the compatibility constraints, so that code would no longer be portable to non-Windows O/S. This was precluded by the license which MSFT signed, so the lawsuit was reasonably decided.

    4. Re:What could possibly go wrong ... by Anonymous Coward · · Score: 0

      Microsoft did not extend java. They removed features (RMI, JNI) and provided windows only replacements instead of providing the windows libraries as addition to a full java implementation, they also modified several classes to work better with a windows environment.

      I see the embrace and extinguish parts but there is no extends here.

    5. Re:What could possibly go wrong ... by Anonymous Coward · · Score: 2, Informative

      But Java's cross-platform compatibility has always been a myth. AWT apps were least-common-denominator pieces of shit most of the time. Swing apps weren't as bad, but never fit in with any desktop environment, and this only got worse as Sun kept cranking out a shitty new theme with each release of Java. Many Java apps made assumptions about file names and directory locations, and this prevented them from running on other OSes.

      The situation was slightly better for server-side Java, but we still ran into the FS path problems, and early on we had to use JDBC drivers that depended on native code (it was a few years before pure Java JDBC drivers were available for some database systems).

      The only thing that ever worked perfectly for us was to develop on Solaris workstations, and to then deploy to our servers running Solaris. Developing on Windows and deploying to Solaris was almost always a recipe for trouble. Java has never really been a viable option on Mac OS X, and Mac OS before that.

    6. Re:What could possibly go wrong ... by Sycraft-fu · · Score: 2, Interesting

      Also a side effect of it was the web getting stuck on Java 1.1.6 for so long. Basically it got stipulated that MS had to ship that version, unmodified, in IE. That's what happens when you let lawyers after tech issues. Sun wanted MS to not make special mods to their version of Java but basically it can down to having to have that version. So the MS Java in IE languished at 1.1.6 and people kept using that because they wanted to be compatible. Finally MS was able to just remove Java and say "download it yourself" and it could be current.

      At any rate you have an extremely good point. People need to remember that if something is really open, then it also means it is open to someone doing their own thing with it. Open languages have that advantage and disadvantage. Anyone can implement them in any way they see fit, but the standards are guidelines, not rules set in stone. Someone can very well build a C++ IDE and compiler that is based on C++, but modified and not compatible. That would be ok. In some ways, this is already done with things like Visual Studio that offer more capabilities and as such can generate code that is not compatible with all compilers.

      A locked down, single company controlled language has the advantage of having only one way of it being implemented. You know any implementation is the same because they can force that. However the big disadvantage is if said company decides to not care or stop handing it out or whatever, you are screwed.

      Frankly I'd be happy to see Java die. Maybe if it did, something better would replace it. My objection isn't so much with the structure of the language, more the implementation, the JVM. It's a crap way of doing things. I think it could be done better, and would be, in the event that Java died off and people had to come up with something to replace it.

    7. Re:What could possibly go wrong ... by roman_mir · · Score: 2, Insightful

      You are wrong.

      Microsoft wanted to provide their own extensions and JVM that was not compliant with Sun Java while still calling the environment Java and using Sun Java trademarks and logos. The entire lawsuit was about the Java trademark. Eventually MS released their own language that is partially compatible with Java, you should know about it, it became what's known as J++ and later J#.

      MS was forbidden from using the Java Compatibility trademark - the steaming coffee cup logo.

    8. Re:What could possibly go wrong ... by Anonymous Coward · · Score: 3, Insightful

      Java's cross-platform compatibility has always been a myth

      Don't talk nonsense, man. Back that up with something.

      If you write the code properly, and stick to Java (no JNI stuff), it's cross-platform. How is that a myth?

    9. Re:What could possibly go wrong ... by arjan_t · · Score: 1

      People need to remember that if something is really open, then it also means it is open to someone doing their own thing with it.

      Right, and so many companies actually did with Java. Only with one 'minor' difference: they didn't call it "Java SE".

      The problem with MS was not that it was extending Java, but that it was luring programmers into thinking they were coding for the Java SE standard. If you were at a MS platform and only checked your code with Visual Studio, then you as a programmer wouldn't know. Until your users tried to run your Java app on their Linux or Solaris boxes, and found out it didn't work at all.

      A very simple solution for MS would have been to provide flags in their environment for "standard compliance Java development" and "non-standard compliance Java development". If my memory serves me well, they had such flags for C++ in their compiler.

    10. Re:What could possibly go wrong ... by haydensdaddy · · Score: 2, Informative

      Java has never really been a viable option on Mac OS X, and Mac OS before that.

      The reason for this was never Java itself, but Apples stranglehold on the implementation and their very public "fuck you" attitude toward developers wanting a release within 2 years of the releases on other platforms.

    11. Re:What could possibly go wrong ... by EsbenMoseHansen · · Score: 1, Informative

      The myth is that it is especially so. Most languages are crossplatform to the same degree, including C, Python, Haskell and ECMAscript.

      --
      Religion is regarded by the common people as true, by the wise as false, and by rulers as useful.
    12. Re:What could possibly go wrong ... by Tim+C · · Score: 5, Insightful

      Many Java apps made assumptions about file names and directory locations, and this prevented them from running on other OSes.

      That's the fault of the programmer(s), not Java.

      Besides, while you have valid points, they are irrelevant to the topic at hand; MS signed a licence saying that they could not introduce Windows-specific classes into the java.* package hierarchy, and yet they did so. No one would have cared if they'd put them in com.microsoft.*, but they chose not to do so.

    13. Re:What could possibly go wrong ... by KermitTheFragger · · Score: 5, Informative

      But Java's cross-platform compatibility has always been a myth. AWT apps were least-common-denominator pieces of shit most of the time. Swing apps weren't as bad, but never fit in with any desktop environment,

      Besides Apple no one cares about consistency on the Desktop anymore. Have you looked at Microsoft apps lately ? Visual Studio looks different then the rest, Office looks different from the rest, Outlook looks different from the rest of Office, Media player looks different from the rest, Home Server UI looks different from the rest and I could go on and on.

      and this only got worse as Sun kept cranking out a shitty new theme with each release of Java.

      In the like 14 years of Swing existence there have only been 3 themes in the JRE: Metal, Ocean and Nimbus. And metal is selected by default. Java never sets one of the newer themes by itself. So basically the default theme hasn't changed.

      Many Java apps made assumptions about file names and directory locations, and this prevented them from running on other OSes.

      So there are people who make crappy programs in Java. How exactly is that different from other languages ?

      early on we had to use JDBC drivers that depended on native code (it was a few years before pure Java JDBC drivers were available for some database systems).

      A few years before pure JDBC drivers were available ? That was when, 2000 or something ? Since that problem is long solved I don't really see how thats relevant today.

      Java has never really been a viable option on Mac OS X, and Mac OS before that.

      Apple does the Java implementation by their selves, not Sun / Oracle and yes, it shows. If Sun had done the Mac OS X implementation for Java it would probably be better.

    14. Re:What could possibly go wrong ... by kthreadd · · Score: 2, Informative

      It depends on what you mean when you say Java.

      The Java(tm) name is owned by Sun/Oracle.

      The Java Language Specification is owned by Sun/Oracle and is offered online for free, with a few restrictions however. As an example you are only allowed to print it once and not make any copies of it.

      The Java software platform is a piece of software licensed as GPL. Anyone can take it, modify it and give it away to someone else.

      So the answer varies depending on what you mean with Java. While the phenomenon known as Java may in theory be owned by Oracle it is in practive decoupled enough to be independent.

    15. Re:What could possibly go wrong ... by Anonymous Coward · · Score: 0

      Java has never really been a viable option on Mac OS X, and Mac OS before that.

      Apple does the Java implementation by their selves, not Sun / Oracle and yes, it shows. If Sun had done the Mac OS X implementation for Java it would probably be better.

      Sun did the Java implementation on the "classic" mac before Apple did. It was totally unusable, so much so that the "MRJ" runtime that Apple produced afterward was a huge improvement. And MRJ was really crappy; it never supported anything beyond Java 1.1. Still, that was worlds better than Sun's, ie. it actually worked some of the time.

      Just look at how long it took Sun to do an OpenOffice port for OSX. Its attitude was, "Just install x11, n00bs."

      Apple is better at doing Java than Sun is at doing MacOS.

    16. Re:What could possibly go wrong ... by toriver · · Score: 2, Informative

      No, it was a breach of contract suit; Sun and Microsoft agreed to a (publically available) contract about Microsoft making the reference implementation of Java on Windows, but then Microsoft broke the terms by doing stupid things like adding keywords (delegate, multicast) to the language and methods and fields/constants to the standard classes.

      I mean, this is public knowledge - why do you choose to lie? Yes, Sun was late in specifying JNI, and hence both Microsoft and Netscape came up with their own implementations of "native", but that was just one aspect of it and far from the most significant.

      In summary: You are the one without a clue.

    17. Re:What could possibly go wrong ... by jbengt · · Score: 1

      My son has a job developing for a major financial company. They do development on MS Windows desktops and deploy on Linux servers. It works just fine for them: (Admittedly, there's not much of a user interface requirement for those apps)

    18. Re:What could possibly go wrong ... by Anonymous Coward · · Score: 0

      Besides Apple no one cares about consistency on the Desktop anymore.

      Who really actually cares Java on the desktop?

      At most you may have an applet to configure a Brocade switch, but personally I've only really run across it in a J2EE fashion (or perhaps embedded in Blu-Ray). It generally died in a pure-desktop fashion long ago.

      As server-side environment, I think it's very cross-platform.

    19. Re:What could possibly go wrong ... by multi+io · · Score: 1

      Who really actually cares Java on the desktop?

      Many people who don't write shrink-wrapped end user applications for the mass market, but things like specialized UIs for corporate desktops and workstations.

    20. Re:What could possibly go wrong ... by Anonymous Coward · · Score: 0

      Apple cares about consistency on the desktop? that must be why Safari 5, QuickTime X Player, iTunes and Finder all look the same. Oh wait. None of them look the same.

    21. Re:What could possibly go wrong ... by dmorris68 · · Score: 5, Insightful

      But Java's cross-platform compatibility has always been a myth.

      Bollocks.

      I've been a Java developer and manager of Java developers for about 10 years now. Before that, 20+ years as C/C++/asm guy across a wide variety of platforms ranging from embedded system to Honeywell/Bull and IBM mainframe and just about every mainstream business platform in between (AS400, VAX/VMS, various Unix flavors, Linux, Windows, Mac, etc.). So application portability is a subject I have a bit of experience with. While in the earliest days of Java portability was more wishful thinking, I can unequivocally say that since, oh, Java 1.4 if not earlier, cross platform portability has been spot on. It just works. I can't even remember the last time I took a Java application I've written to a platform that it didn't work on. Even today I am always mildly surprised to take a fairly complex GUI application I've developed on, say Windows, and drop it on another platform, like Linux or OSX, and watch it run flawlessly. I recently wrote a manufacturing line simulator to use as a test backend for a Java-based shop floor system. This is a multi-threaded GUI app simulating and displaying in real-time movement of product through the line, while interfacing with OPC servers and host applications via message queues and databases. When it was done, I dropped it on an Ubuntu desktop box and aside from the slight differences in the Linux GUI appearance, you wouldn't know which one you were looking at.

      The only portability problems I've seen are either from dependency on native JNI code (which is rarely but occasionally necessary) -- and almost all databases these days support pure-Java Type4 drivers without dependency on native clients -- or due to lousy programmers who hardcode platform specific constructs. I have *never* had an issue with filesystem path portability over the hundreds of Java applications I've written or managed in the last decade, because I never assume/hardcode anything specific to the platform I'm developing on. This is a common failure of your typical VB developer that is new to Java -- all they think about is Windows, many have had zero exposure to other environments, so that's all they know. Which is fine I guess if you're a 100% Windows shop or targeting a Windows base, but then I'd certainly question the transition to Java in that case. Regardless, don't blame the language for its misuse by developers -- if so then we could condemn every programming language ever made.

      I like Java well enough and am proficient enough with it that even if I were stranded in Windows purgatory forever, I'd still consider using it over .NET even without the portability benefits. I've had the occasion to have to write some C# due to some OPC/DCOM integration code that required it. While there are some things about the .NET platform and languages that I find appealing, there's not enough there to win me over from Java.

    22. Re:What could possibly go wrong ... by drinkypoo · · Score: 2, Interesting

      Apple cares about consistency on the desktop? that must be why Safari 5, QuickTime X Player, iTunes and Finder all look the same. Oh wait. None of them look the same.

      Apple doesn't give one tenth of one shit about their own HIG and they never did.

      What I find really interesting about Mac OS is that it's the last environment using a "Unix-style" file picker where you have as many panes as you like and each subdirectory click results in a pane shift to the left as the new directory is opened in the rightmost pane. Meanwhile KDE has a totally Windows-styled version and GNOME has a sort of fusion of Win and Mac.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    23. Re:What could possibly go wrong ... by HiThere · · Score: 2, Informative

      No, it's not decoupled enough to be independent...but it's decoupled enough to *become* independent, if enough people put enough time and work in on it. (The constraints listed mean, e.g., that the entire documentation would need to be recreated in a logically equivalent form, but in a form different enough to not run afoul of copyright restrictions.)

      Still, good progress seems to be being made in that direction. But much more should be done, even if Oracle demonstrates both commitment and competence.

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
    24. Re:What could possibly go wrong ... by HiThere · · Score: 1

      Python, yes. C, no. Not unless you include the source code, and recompile for the new platform.

      Sun's claim was that Java class files wouldn't need to be recompiled to run. I found that reasonably true. (Of course, you had to be running on a compatible JVM which had been compiled for the appropriate local platform.)

      Note, by the way, that Python achieves cross-platform capability by an exactly comparable means. Ruby and ECMAscript basically don't HAVE a compiled form, but if they did it would be the same argument. (Don't know about the others.)

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
    25. Re:What could possibly go wrong ... by mgkimsal2 · · Score: 2, Interesting

      So *why* was/is Apple in charge of the Java implementation for Mac? I don't buy the 'too much resources' argument I've heard. If your entire company is about Java (changing your stock symbol to JAVA for goodness' sake!) why cede control of implementation on a major developer platform (or one which could become a major developer platform)?

    26. Re:What could possibly go wrong ... by EsbenMoseHansen · · Score: 0, Flamebait

      Python, yes. C, no. Not unless you include the source code, and recompile for the new platform.

      You are confusing the language with the runtime environment. Nothing prevents a C program to be translated to Java bytecode (or python ditto), which can then be run in a JVM. Likewise, there is no rule that a Java program has to be translated into intermediate bytecode, to be interpreted or compiled at invocation.

      Sun's claim was that Java class files wouldn't need to be recompiled to run. I found that reasonably true. (Of course, you had to be running on a compatible JVM which had been compiled for the appropriate local platform.)

      Note, by the way, that Python achieves cross-platform capability by an exactly comparable means. Ruby and ECMAscript basically don't HAVE a compiled form, but if they did it would be the same argument. (Don't know about the others.)

      My point exactly. It's hardly unique, even at the time.

      --
      Religion is regarded by the common people as true, by the wise as false, and by rulers as useful.
    27. Re:What could possibly go wrong ... by kthreadd · · Score: 2, Insightful

      According to the Sun engineers I've talked to it all has to do with a really old license agreement between Apple and Sun that they can't change for now. It originates from the very early days of Java, a time when Apple was almost desperate to get more attention to the Mac and saw Java as a lifesaver as applications developed for it would almost automatically work on the Mac as well. So they basically gave Sun a big load of money in exchange for the exclusive rights to make Java for the Mac platform. That gave them a good opportunity to also make Java fully integrated on the Mac and back then they actually made a good job doing that. It's too bad that their dedication have slowly declined as the Mac gained more popularity over the years.

      Due to this Sun/Oracle is basically forbidden to directly release Java for Mac OS X until the agreement expire or Apple decides to make a new agreement. The only practical solution they proposed was to use the BSD port of OpenJDK. You won't have the Aqua UI and I think you have to deal with X11, but you will have an overall better and newer Java.

    28. Re:What could possibly go wrong ... by The+Snowman · · Score: 1

      Only for trivial applications.

      You can be utterly 100% certain that a non-trivial application will require re-work to run in a different environment other than what is was coded for.

      At work, I develop a large Java application with approximately 14,000 class files encompassing over 100 MB worth of compiled code and other resources. This code touches every area of a system: UI, database, specialized hardware devices, networking, logging, financial system integration, etc. It does run flawlessly on multiple platforms.

      The only changes for running on different platforms have to do with configurations, and even that is one or two system properties. For a remotely managed kiosk-style system that is set up once and managed remotely in aggregate, that is extremely simple.

      --
      24 beers in a case, 24 hours in a day. Coincidence? I think not!
    29. Re:What could possibly go wrong ... by shutdown+-p+now · · Score: 1

      MS signed a licence saying that they could not introduce Windows-specific classes into the java.* package hierarchy, and yet they did so. No one would have cared if they'd put them in com.microsoft.*, but they chose not to do so.

      Out of curiosity, can you give some examples? I didn't look closely at Microsoft J++ back in the day, but I do distinctly remember that it had a lot of classes in com.ms.*, so I kinda assumed that everything "extra" was there. E.g. the whole "Windows Foundation Classes" was under com.ms.wfc. What was the non-standard stuff under java.*?

    30. Re:What could possibly go wrong ... by shutdown+-p+now · · Score: 2, Informative

      we still ran into the FS path problems

      Yes, well, when trying to use some platform or technology, it helps to RTFM.

      Seriously. Java won't make any code written in it portable automagically, but it does give you everything you need to write portable programs, and has plenty of documentation explaining how to do just that.

    31. Re:What could possibly go wrong ... by shutdown+-p+now · · Score: 1

      Eventually MS released their own language that is partially compatible with Java, you should know about it, it became what's known as J++ and later J#.

      Actually, J++ was "Microsoft's Java" (or rather, the development environment for it), and was the product targeted by Sun's lawsuit. As you rightly note, it was a matter of trademarks but also licenses - Sun owns the trademark "Java", and it licensed it to MS under certain specific conditions, which included adhering to the spec.

      J# was an altogether different thing. It was an implementation of Java 1.1 language (but not JVM nor other bits that are needed to be properly called "Java") on top of .NET, mainly aimed at porting applications. Since it never called itself Java, it was legally in the clear.

    32. Re:What could possibly go wrong ... by MichaelSmith · · Score: 1

      Nothing prevents a C program to be translated to Java bytecode

      ...or running the executable in a virtual machine.

    33. Re:What could possibly go wrong ... by devent · · Score: 1

      Well, you can do that in Dolphin, if you like. It's called "Columns View Mode". But actually, it's pretty useless. Why should I care of the parent directory if I go one directory deeper? And now I can only use 1/3 of the Dolphin window to see the files I'm interested in.

      --
      http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
    34. Re:What could possibly go wrong ... by dmorris68 · · Score: 2, Insightful

      Only for trivial applications.

      You can be utterly 100% certain that a non-trivial application will require re-work to run in a different environment other than what is was coded for.

      Umm, your reading comprehension skills are apparently the only thing trivial here.

      Did you even attempt to read what I wrote? I specifically described a "non-trivial" application, and could go on to describe dozens more. In fact, I pretty much don't write "trivial applications" these days.

      As I and others who have posted here, plus any number of other Java developers, will attest, Java is absolutely portable if you have half a clue as a developer.

      It's obvious you either:
      (a) have no real experience with Java in the last 6-8 years
      (b) have no "non-trivial" programming experience to speak of at all
      (c) are a troll

    35. Re:What could possibly go wrong ... by Zeinfeld · · Score: 1
      The lawsuit included claims related to com.ms.* additions.

      The fact was that J++ always provided you with a switch you could use to check for strict compatibility - if that is what you wanted. Sun's lawsuit was brought to prevent Microsoft from allowing any native access to the Windows O/S.

      And once the lawsuit was brought against Microsoft, it pretty much killed any chance of Apple backing Java rather than Objective C.

      The reason the whole industry swung behind Java was that C++ was a crock and Sun appeared to be offering an open alternative. The lawsuit proved otherwise. Sun did not make clear that they intended to exercise control and veto extensions that might leverage any O/S feature not in Solaris. Once that became clear the opportunity was lost and Apple and Microsoft both moved to their own platforms.

      Jobs might well have persuaded Gates to move to Objective C had Java never appeared on the screen. The flaws of C++ had already become obvious by the time Jobs returned to Apple. And keeping Apple alive (but not too healthy) was a major priority for Microsoft at that time.

      --
      Looking for an Information Security student project suggestion?
      Try http://dotcrimeManifesto.com/
    36. Re:What could possibly go wrong ... by Zeinfeld · · Score: 1
      Visual J++ was Microsoft's Java environment. You could write 100% compatible code with it and the compiler would check for compatibility.

      What Sun was objecting to was that besides running every 100% compatible application, Microsoft also supported extensions. So if you wanted to use Windows specific functions you could use them from Java. But nobody was ever going to do that by accident, you had to turn on those features.

      Most people interpret compatibility as meaning 'can do everything required by the standard'. Sun turned that round to mean 'does not do anything that we don't permit'. Even if the contract had permitted them to do that (Microsoft would not have signed it had they known the courts would uphold that interpretation), the fact that Sun did try to enforce that meaning was bad for open software.

      --
      Looking for an Information Security student project suggestion?
      Try http://dotcrimeManifesto.com/
    37. Re:What could possibly go wrong ... by Anonymous Coward · · Score: 0

      Who was it who said that being utterly 100% certain about anything was a sign of insanity?

      The simple truth is that most Java applications really do run perfectly on any platform. I have personally taken a large, complex in-house Swing application, with many custom GUI components, written by someone with poor coding standards and little knowledge of Java who never expected it to be run on anything other than the single flavour of Unix workstation it was written for -- and it worked perfectly in Windows and in Linux, first time, not one single adaptation required.

      No pixie dust or fairies involved, just the real-world fact that Java provides cross-platform compatibility if you aren't too worried about consistent look-and-feel and can cope with the fact that it's a nasty language with an unnecessarily restrictive type system and a philosophy of deliberately making things verbose.

    38. Re:What could possibly go wrong ... by Zepalesque · · Score: 1

      Your Kung-Fu is strong.

    39. Re:What could possibly go wrong ... by Zeinfeld · · Score: 1
      That is what Sun claimed at the time. But if you bother to read the lawsuit you will see that actually Sun abandoned their original breach of contract line of attack and instead were making claims in copyright and trademark law.

      The reason for that was that the contract had a clause that specifically prohibited Sun from going to court for an injunction over interpretation of the contract.

      Of course you would have known that if you had bothered to actually read the source documents rather than relying on Sun's own claims and flamewars out on Slashdot.

      You know it is entirely possible for Microsoft and Sun to both be wrong. The fact that you don't like Microsoft does not mean that anyone who sues Microsoft is automatically doing it for the best of motives or that it is in your interests that they win.

      The reason Sun signed the deal with Microsoft was that they needed Redmond's support to make Java the industry standard programming language. The outcome of the lawsuit was that Microsoft would no longer support J++ and the VDM would be frozen for the next five years and eventually discarded. So instead we have four industry standard languages and three object frameworks.

      I can't really write code in either Java or C# without portability issues. If I write in Java I can't use the Windows or Mac platforms to the full. If I code in C# I have to wonder if the code is really going to work on other platforms.

      --
      Looking for an Information Security student project suggestion?
      Try http://dotcrimeManifesto.com/
    40. Re:What could possibly go wrong ... by billcopc · · Score: 1

      I care about Java on the desktop in that I strongly despise it. I'd say over the my 14 years of involuntary contact with Java, I've had about a 50/50 success rate running desktop Java apps. Either they break due to some dependency or hardcoded path failure, or they run but the UI is so absurdly messed up it makes it unusable. Error handling also seems like a chore as more of the time they seem to be ignored.

      I'll be 100% frank here: 14 years ago as a teenager, I started learning Java. I built a few web applets and some standalone apps, got extremely fed up with the abysmal performance and boilerplate tedium, and went back to my beloved Pascal/Delphi and C. Years later when I was required to deal with other people's Java apps and code, the pain of it all led me to religiously avoid both Java jobs and Java coders. There is so much navel-gazing in a Java project: interfaces to classes to functions to tag libraries, everything abstracted ten levels deep... are Java coders paid per line of code ? :P There was a joke "Hello World" program that was about 5 pages long, but it wasn't funny to me because that's exactly what most commercial code looks like.

      To this day, I see the whole Java universe as a make-work project for millions of incompetent programmers. When job hunting if I am asked if I do Java, I proudly respond "Fuck NO!". Half the time it elicits strong laughter followed by "Amen, brother!", the rest of the time it conveniently ends an interview for a job I would surely hate.

      --
      -Billco, Fnarg.com
    41. Re:What could possibly go wrong ... by billcopc · · Score: 2, Interesting

      Dolphin's column view is kind of crap, but that doesn't mean it's useless. Shuffling files and folders around is something I do daily, and it's mighty nice when I can access several dozen folders from one window, rather than having to open a bunch of individual windows and juggle them with Alt-Tab or very meticulous tiling.

      That said, the fact that this view is predominantly used on Apple's nerfed OS is quite ridiculous.

      --
      -Billco, Fnarg.com
    42. Re:What could possibly go wrong ... by kaffiene · · Score: 1

      Bullshit. As early on as Java 1.17 I was producing GUI apps that ran on Windows from a Linux development environment.

      If DEVELOPERS make assumptions about file names and directory locations then the DEVELOPERS are dumb. That doesn't make Java any more or less cross platform.

    43. Re:What could possibly go wrong ... by kaffiene · · Score: 4, Interesting

      Rubbish, Java *is* especially cross platform when compared to other languages. For example, C - which you cite.

      If you write a simple command line app, then sure, C and Java are about as cross platform capable as each other. Write a GUI app in C and Java and the former has no cross platform options.

      In C, you have to worry about endianness, in Java you don't.

      In C, you have to allow that primitives types may have different sizes, in Java you don't.

      In C, you have to allow that structures might pack differently, in Java you don't.

      In C, critical issues like threading will be platform dependant or non-existent, in Java it's consistent and standard.

      Java also has a consistent memory model, which provides a lot of value in working cross platform as well as the huge common library which is likewise valuable.

      I could go on, but I think that's sufficient to call BS on your claim.

      In Haskell or JavaScript, there are nowhere near as large *common* sets of libraries, so you can't as easily rely on your library of choice being supported on a client system.

      Christ, JavaScript doesn't run the same browser to browser, let alone cross platform.

    44. Re:What could possibly go wrong ... by dintech · · Score: 1

      In C, critical issues like threading will be platform dependant or non-existent, in Java it's consistent and standard.

      While I agree with the sentiment of what you're saying, Java threading is not able to be standard because of platform differences. For example, thread priorities work differently depending on the OS. However, the same code should run on all platforms, just with a potential for minutely different behaviour.

      This is a good comparison of java threading models.

      What's interesting is that you can't have thread priorities at all on Linux unless you're running as root. I assume this applies to all software, not just Java apps. I didn't know that...

    45. Re:What could possibly go wrong ... by Xest · · Score: 1

      I agree with you for the most part, I'm a real big fan of Java, however it's worth pointing out that multimedia can be problematic- when you start working with audio and graphics dependency on the JNI increases, and that's when you start to run into problems.

      For apps that don't need this stuff like most business apps, most back end apps and so forth, there's no question, Java portability just works, and it's far and away the best language for the job. It's performance nowadays is excellent too.

      Regarding C#/.NET, if you're doing Windows only stuff is certainly is much nicer than Java, but that's because of the additional features it offers - things like Linq, operator overloading, Lambda expressions, extension methods, delegates, properties and such. Importantly though also is Visual Studio, it's still the best development environment out there IMO. The issue is of course, to learn/make use of all C#/.NET and Visual Studio's features you tend to have to use it a fair bit, so unless you do and as such if you only do a little bit of work in it and don't have the time to invest in learning all C#'s features then as you say, you're best off just sticking with Java as it's a fine language. If you ever end up having to do a sizeable amount of Windows only work though in C#/.NET then I'd say it's well worth learning those extra features and you'll rapidly begin to appreciate why C# does so well in the Windows world nowadays.

    46. Re:What could possibly go wrong ... by SenseiLeNoir · · Score: 1

      I have created in the past an application that "on the fly" modifies MP3s per request (inserting adverts, seaming together descrete files, etc), as part of a large Podcast CMS web application (Tomcat deployment).

      The application was written in 100% pure java, and was developed on PCs running Windows, test on Intel PCs running Linux, and deployed on a Sun T1000 Solaris.

      It was as "write once, run anywhere" as you can get, the same WAR deployed and ran successfully on all platforms.

      --
      Have a nice day!
    47. Re:What could possibly go wrong ... by yyxx · · Score: 1

      Even today I am always mildly surprised to take a fairly complex GUI application I've developed on, say Windows, and drop it on another platform, like Linux or OSX, and watch it run flawlessly.

      No Java GUI application runs "flawlessly" on Linux or OS X because the Java runtime gets a number of things wrong with desktop integration on Linux and OS X.

    48. Re:What could possibly go wrong ... by quanticle · · Score: 1

      No more than could go wrong when being owned by Sun.

      Seriously, I have not seen a single technology come out of Sun's research labs that hasn't been screwed up by Sun's attempts to turn it into a product. Java, SPARC, Solaris, NetBeans, all have suffered from Sun's management and marketing incompetence. From chip design right up through applications, Sun has screwed up every technology its ever got its hands on. Oracle, at least, can make and market a decent database.

      --
      We all know what to do, but we don't know how to get re-elected once we have done it
    49. Re:What could possibly go wrong ... by quanticle · · Score: 1

      The myth is that it is especially so. Most languages are crossplatform to the same degree, including C, Python, Haskell and ECMAscript.

      The other languages, sure, but not C. Sure, the standard library is cross platform, but the moment you go beyond the standard C library, you're stuck with platform specific tools. With Java, you can write an application that takes draws a GUI for the user, pushes files over the network, plays sound, etc. without touching any platform specific code. You can do the same (I think) with Python and ECMAScript (with HTML5). You can't do that in a totally cross platform manner with C.

      --
      We all know what to do, but we don't know how to get re-elected once we have done it
    50. Re:What could possibly go wrong ... by EsbenMoseHansen · · Score: 1

      The myth is that it is especially so. Most languages are crossplatform to the same degree, including C, Python, Haskell and ECMAscript.

      The other languages, sure, but not C. Sure, the standard library is cross platform, but the moment you go beyond the standard C library, you're stuck with platform specific tools.

      No. You are free to use cross platform tools, same as Java. There is no difference in class, only in the details. That is, in both languages it is possible to write cross platform (I have done so in both, the effort is really not that great), and in either it is possible to break a platform. For example, some platforms does not support files starting with a number in some cases. Sure, Java comes with a huge cross platform library, but that has little to do with the language.

      --
      Religion is regarded by the common people as true, by the wise as false, and by rulers as useful.
    51. Re:What could possibly go wrong ... by volkram · · Score: 1

      Look who's living in 1995.

    52. Re:What could possibly go wrong ... by Anonymous Coward · · Score: 0

      So a language is cross-platform if the interpreter exists for more than one platform?
      Then I could say VBA is platform-independent, because with WINE/Crossover Office you can run MS Office on Mac OS, Linux, Solaris [...], which enables me to run VBA on that platform.

      In VBA you dont have to worry about endianness

      In VBA your primitive types alkways have the same size

      Convinced?

    53. Re:What could possibly go wrong ... by badkarmadayaccount · · Score: 1

      Can't they release a JVM for GNUStep, and just make sure it's (roughly) source-compatible with OS X?

      --
      I know tobacco is bad for you, so I smoke weed with crack.
    54. Re:What could possibly go wrong ... by kaffiene · · Score: 1

      Because Mac *wasn't* a major platform.

    55. Re:What could possibly go wrong ... by dave87656 · · Score: 1

      Many Java apps made assumptions about file names and directory locations, and this prevented them from running on other OSes.

      We've been using Java in a mixed environment for 10 years and haven't run into issues with file names. Most business applications don't do much with local files anyway, even if that were true, since most reference databases.

      I had great hopes about Solaris as an optimized Java platform, but it didn't work out that way.

      That only reason MacOS X has issues with Java is because Steve Jobs doesn't like java, probably because he doesn't own it and he was hurt that Sun didn't create a binary apple version, like it did for MS Windows and Linux. Once Apple decided to get on board, java worked fine.

    56. Re:What could possibly go wrong ... by dave87656 · · Score: 1

      The fact is, you can create a Swing desktop program with extensive functionality which runs on Linux, Windows, Max OS X, Solaris and Windows as is without recompiling. Sure that are things you could do which are not platform independent but you usually don't have to.

      You can also use java for everything from Cell Phones to Server Side applications.

      I know of no other language with that flexibility.

    57. Re:What could possibly go wrong ... by dave87656 · · Score: 1

      Very well put. Thanks.

    58. Re:What could possibly go wrong ... by EsbenMoseHansen · · Score: 1

      Let me give you a few then: Ruby, Python, Perl. Plus, all of these are not the fantastical pain in the behind to write in, since they have proper resource management (something Java only have for memory).

      And frankly, I find the value of not having to recompile very small. I mean, it is a matter of a build environment, since you need the actual test environment anyway. If that artificial requirement is dropped, we can add C++, which is oh-so-much better suited to desktop applications than Java is.

      Really, you need to read less marketing and more reality.

      --
      Religion is regarded by the common people as true, by the wise as false, and by rulers as useful.
    59. Re:What could possibly go wrong ... by dave87656 · · Score: 1

      since they have proper resource management (something Java only have for memory).

      What resource mgmt are you referring to?

      And frankly, I find the value of not having to recompile very small. I mean, it is a matter of a build environment, since you need the actual test environment anyway.

      I have about 80 desktops. Installing a build environment on each would be a royal PIA, and, for each update, going to each machine and rebuilding?

      C++, which is oh-so-much better suited to desktop applications than Java is.

      Not sure you noticed, but C++ itself does not provide a desktop environment. You could use GTK but Windows compatibility is not always given. You could use Qt, but it's not a pervasive as GTk, though it would work. Still, for every update, I'd have to rebuild for each platform and each platform would have to have it's own update procedures.

      Really, you need to read less marketing and more reality.

      My application of 1.1 million lines of code runs on 80 boxes, currently mostly linux with some windows with updates happening multiple times a day. I also had tried Gtk with C++ and the main application used to be in Gtk/C++ so I know what's involved. Java is much much easier on multiplatform for those who have actually used both in real world environments. I guess this might be the "reality" you were referring to.

    60. Re:What could possibly go wrong ... by EsbenMoseHansen · · Score: 1

      since they have proper resource management (something Java only have for memory).

      What resource mgmt are you referring to?

      Window handles, files, pipes, sockets. You know, resources: stuff that needs to be released at the right time.

      And frankly, I find the value of not having to recompile very small. I mean, it is a matter of a build environment, since you need the actual test environment anyway.

      I have about 80 desktops. Installing a build environment on each would be a royal PIA, and, for each update, going to each machine and rebuilding?

      I assume that these 80 desktops are not running 80 different OS's? As I wrote, you need a build environment for each of the different test environments you already (presumably) have.

      C++, which is oh-so-much better suited to desktop applications than Java is.

      Not sure you noticed, but C++ itself does not provide a desktop environment. You could use GTK but Windows compatibility is not always given. You could use Qt, but it's not a pervasive as GTk, though it would work. Still, for every update, I'd have to rebuild for each platform and each platform would have to have it's own update procedures.

      GTK would be C; I haven't used it. Mostly I use QT, and I just include it on windows --- everywhere else, it will be installed by the local package management (perhaps including Mac OS, we don't have customers on that platform at the moment). Compared to the other libraries I usually need, QT is quite benign.

      Really, you need to read less marketing and more reality.

      My application of 1.1 million lines of code runs on 80 boxes, currently mostly linux with some windows with updates happening multiple times a day. I also had tried Gtk with C++ and the main application used to be in Gtk/C++ so I know what's involved. Java is much much easier on multiplatform for those who have actually used both in real world environments. I guess this might be the "reality" you were referring to.

      What sort of masochism had you use a C toolkit for C++? No wonder you have a bad experience. Multiple updates per day sounds like a nightmare for customer relations if nothing else. Thankfully, I don't have to use anything with that many updates.

      I tried to make something with Swing once. And SWK another time. I'm still traumatised by the (bad!) experience. Too hard to do even simple things.

      --
      Religion is regarded by the common people as true, by the wise as false, and by rulers as useful.
    61. Re:What could possibly go wrong ... by dmorris68 · · Score: 1

      No Java GUI application runs "flawlessly" on Linux or OS X because the Java runtime gets a number of things wrong with desktop integration on Linux and OS X.

      Again with the presumptuousness. "No" Java GUI application runs flawlessly on Linux or OSX? Really? Perhaps you determine "flawless" as fully integrating as a native app with dbus or COM or whatever. That is not what I look for in a general purpose application, and it has no bearing on a Java app being "flawless" when run between platforms. I'll concede there may be some specific examples where such desktop integration is important to an app, but not in any that I work with. I certainly can't recall any of the dozens of Java apps that I've moved to Linux giving me any problems whatsoever, and that includes GUI apps. I've done much less work on OSX by comparison so my sample size is smaller, but I've still yet to run into any noticeable issues there either.

      As one other commenter noted, there are some virtual/niche application areas where Java does not excel, such as certain multimedia or gaming applications. I'm the first to admit that -- I've always been a "right tool for the job" kinda guy. For probably 75+% of applications though, it's a fit and works extremely well. In my line of work, about the only areas I consider Java seriously lacking in is device drivers (obv), COM/DCOM, or other areas that must be specific to a platform. Native code will always have a place, but I've been able to minimize it a great deal since adopting Java. I still write C/C++ and C#, but it probably accounts for less than 10% of code.

      BTW, as an anecdote, one of the best open-source DLNA servers for streaming media is PS3 Media Server. Despite initially being targeted for PS3's, I've found it to be the most compliant with a larger number of DLNA renderers, to include my Bravia TVs and LG BR players, than MediaTomb or other big DLNA servers. Configuration is also easier, and auto-transcoding almost "just works" out of the box with very little tweaking required. It's written in Java, btw. ;) Although it does make use of 3rd party libraries such as MPlayer & ffmpeg, it runs on any platform where those libraries are supported (at least Windows, Linux, and OSX). I run it on a Linux box and it pretty much works "flawlessly."

    62. Re:What could possibly go wrong ... by yyxx · · Score: 1

      Again with the presumptuousness. "No" Java GUI application runs flawlessly on Linux or OSX? Really? Perhaps you determine "flawless" as fully integrating as a native app with dbus or COM or whatever.

      On Linux and OS X, Java GUI programs don't even reliably register the right characters in response to keystrokes, and they don't handle drag-and-drop quite right. I'd call that pretty big flaws.

    63. Re:What could possibly go wrong ... by kaffiene · · Score: 1

      I don't agree that you've pointed out a counter example to what I was saying. Yes, priorities are not able to work the same across platforms but that is by definition. They make no guarantee that priorities will work the same across platform.

      It's like saying that C is broken because you get a different result by dereferencing null on different platforms. It ain't broken - the results are undefined. Ditto with Java threads - priorities explicitly NOT guaranteed to work across platforms.

    64. Re:What could possibly go wrong ... by dave87656 · · Score: 1

      What sort of masochism had you use a C toolkit for C++?

      You can still use C++ with GTK, in fact there is a C++ wrapper which I didn't use. I layered it in my own C++ objects, for the most part, which worked well.

      Multiple updates per day sounds like a nightmare for customer relations if nothing else.

      It's an internal mfg/sales/cust rel application which is constantly moving. The updates have to happen on the fly and not affect anyone other than the targeted group. In java you can use your own class loader to accomplish this. Under Windows, if someone has an application open on a shared drive, you have to wait for everyone using the application to close it before you can update it. The problem would be similar for java if you use jar files.

      I tried to make something with Swing once. And SWK another time. I'm still traumatised by the (bad!) experience. Too hard to do even simple things.

      IMO Swing is more difficult that GTK and also less amenable to abstraction. With GTK, it was alot easier to do even the basic things. Swing has the problem of not being thread-safe. Plus, the GTK apps loaded much more quickly. Java has improved alot since then, though.

  2. Oracle actually uses Java by bdsesq · · Score: 3, Interesting

    Oracle uses Java for supporting it's bread and butter database.
    The Universal Installer is written in Java as are a number of other tools.
    It would cost Oracle millions of dollars to rewrite these tools if they killed Java.
    They could still kill Java but it it would not be an easy decision for them to make.

    1. Re:Oracle actually uses Java by Anonymous Coward · · Score: 1, Insightful

      The tools you're referring certainly didn't have production costs of millions of dollars. They're not very complex and a bit crappy. I do assume they have complex in-house JEE systems which might well be worth that amount though.

      But Oracle cannot _kill_ Java, Java is open source. I'm pretty sure Google or IBM would gladly take over as the Java figurehead.

    2. Re:Oracle actually uses Java by red_dragon · · Score: 2, Insightful

      It isn't just the Universal Installer that's written in Java; for some things there are shell scripts that bypass it. A much bigger and profitable product for them is the E-Business Suite, which is mostly Java with a few native code components. Letting Java languish would mean losing billions of dollars in support and maintenance fees as customers abandon EBS (and the Oracle database by extension) for more up-to-date enterprise software.

      --
      In Soviet Russia, Jesus asks: "What Would You Do?"
    3. Re:Oracle actually uses Java by M.+Baranczak · · Score: 1

      The tools you're referring certainly didn't have production costs of millions of dollars. They're not very complex and a bit crappy.

      Well, this is Oracle we're talking about.

    4. Re:Oracle actually uses Java by sjames · · Score: 1

      By kill it, they don't mean a deliberate management decision that it is to be no more. They mean more of a running management indecision that turns it to muck leaving the management standing around wondering how that happened. Sorta like a 3 year old who forgot to feed the goldfish for 27 consecutive days and wonders where it went.

    5. Re:Oracle actually uses Java by Bing+Tsher+E · · Score: 1

      The Marketing guys know what they're selling. And the coders will be able to get it going by the time it ships. Or eventually, anyway, maybe. This is Oracle.

  3. What about Google? by Anonymous Coward · · Score: 1, Insightful

    The article fails to mention Google, certainly one of the big players and evidently a big supporter of Java. There's GWT, there's Android, they really push hot stuff onto the dusted platform.

    IBM was also not mentioned, another huge company that really pushes Java forward - although in a direction I personally don't like.

    1. Re:What about Google? by fishermonger · · Score: 1
      Mod up please RE google. Also I read a few blogs (sorry no references, look it up) about people moving away from Windows Azure because of ridiculously high costs for small/medium sized sites which are free on app engine! Hence some traffic coming from dotnet guys.

      I am anxiously waiting to see how this fight turns out. I am going to start teaching some open-source tools and langs soon. Nothing closed, no Microsoft technologies. Harder, yes, but with App Engine the sky's the limit i think.

      --
      "...normal evolution would have gone Word to Frame to troff, but instead, the computer industry has gone the other way!"
  4. Only Morbidly Obese Aspies use Java by Anonymous Coward · · Score: 0, Troll

    If you weigh more than 400lbs and have Aspergers and you can't get laid and the only job you can get is cleaning out Supermarket trash then you are a java programmer. Meanwhile winners use C#.net Professional.

  5. Doing all my programming in C# by anss123 · · Score: 1, Troll

    Which is pretty much Visual Basic with Java syntax. I find Java source code a tad easier to read and Javadoc make C#'s cumbersome "compiled comments" look silly. Does Java still have checked exceptions in common use? In that case I envy you guys. Scratching my head over which exceptions can spew out of a library is annoying, even if checked exceptions can be annoying at times too.

    1. Re:Doing all my programming in C# by drewhk · · Score: 2, Insightful

      I think checked exceptions are largely misunderstood. When people complain about them, they unknowingly, but almost always complain about the try..catch construct -- it is very wordy, annoying, inflexible and is almost impossible to factor out common idioms.

    2. Re:Doing all my programming in C# by Anonymous Coward · · Score: 1, Interesting

      You're supposed to assume that all exceptions can be thrown from all code. That's the only safe way to develop reliable Java or C# code.

      Java checked exceptions do absolutely nothing to help when you're working with dynamically-loaded code, for instance. I had to work with one Indian team who claimed that using checked exceptions everywhere would prevent uncaught exceptions from ever being thrown. Then they decided to use a library that used a library that dynamically loaded some JDBC drivers that threw unchecked exceptions in some cases. Of course, their software broke, and I got stuck fixing it. But it was extremely annoying have to deal with them, having them tell me that the situation we were witnessing could never occur because they used checked exceptions in their code.

    3. Re:Doing all my programming in C# by sourcerror · · Score: 1

      The thing is, that in a lot of cases you actually should use Runtime Exception instead of static ones. Actually, as far as I know Java is the only language that has static exceptions. (C++ has only runitme exceptions, scripting languages too; I don't know about C#)
      The worst thing you can do is catch all exceptions silently in the outmost method.

    4. Re:Doing all my programming in C# by drewhk · · Score: 1

      "Then they decided to use a library that used a library that dynamically loaded some JDBC drivers that threw unchecked exceptions in some cases. "

      In other words, checked exceptions can only help when they are used.

    5. Re:Doing all my programming in C# by Eskarel · · Score: 4, Insightful

      C# is really more sort of the averaging of Java and C++ than anything else, and VB is now C# with a slightly different syntax(sort of wish Microsoft had the balls to just end it rather than farting around with putting god awful VB syntax onto a language which is nothing like it.

      I do agree that Microsoft needs to do something about the exceptions though, not necessarily checked exceptions cause those are a pain, but some easy way in Visual Studio to get a list of exceptions that can be thrown by a call so you know what you could check for. You're also right about javadoc.

      That said, LINQ is just incredible, and IIS with .NET is a hell of a lot easier to configure and tune than Tomcat, it's really 6 of one and a half dozen of the other with Java and .NET at the moment, which is why what Oracle does is so important.

    6. Re:Doing all my programming in C# by drewhk · · Score: 1

      "The worst thing you can do is catch all exceptions silently in the outmost method."

      No, it is actually worse to have only RuntimeExceptions and handle none. In the static version, at least a code reviewer will immediately see the empty catch blocks, while in the dynamic case the problems will remain hidden.

      In the checked case, when I ignore exceptions (catch, and do nothing) at least I document it explicitly in the code by writing the empty catch block. This is not true for unchecked ones.

    7. Re:Doing all my programming in C# by anss123 · · Score: 1

      You're supposed to assume that all exceptions can be thrown from all code.

      I disagree. I catch the general execeptions up in the code tree from where I will abort the whole opperation when they occur, putting my main focus on exceptions that are likely to be thrown - primarly on how they affect the user. Rare exceptions, even if an exception handeler can make a clean fix, are sent to the error box.

      Checked exceptions also give you insight into the function that documentation often lacks. For instance I'm working on an app that connects to a database, the app have to work even when the database is down so it's nice to know which library method will cast database exceptions. It is not always obvious, had a recent bug where a method worked most of the time when the DB was down except for in certain circumstances stemming from an event handeler. In this case I wrote the library myself so I'm the one to blame, but oh well.

      Java checked exceptions do absolutely nothing to help when you're working with dynamically-loaded code, for instance.

      I did not know that.

    8. Re:Doing all my programming in C# by arjan_t · · Score: 2, Insightful

      >Does Java still have checked exceptions in common use?

      No, I'm sorry for you. The standard platform is moving away from them and is resorting to run time exceptions being mentioned in Java doc. E.g. an excerpt from the platform standard class EntityManager:

      public interface EntityManager {
          /**
           * Make an entity instance managed and persistent.
           *
           * @param entity
           * @throws EntityExistsException        if the entity already exists.
           *                                      (The EntityExistsException may be thrown when the persist
           *                                      operation is invoked, or the EntityExistsException or
           *                                      another PersistenceException may be thrown at commit
           *                                      time.)
           * @throws IllegalStateException if this EntityManager has been closed.
           * @throws IllegalArgumentException     if not an entity
           * @throws TransactionRequiredException if invoked on a
           *                                      container-managed entity manager of type
           *                                      PersistenceContextType.TRANSACTION and there is
           *                                      no transaction.
           */
          public void persist(Object entity);

    9. Re:Doing all my programming in C# by anss123 · · Score: 1

      IIS with .NET is a hell of a lot easier to configure and tune than Tomcat

      I find LAMP easier still, also the main webapp I run at work can't run on ISS7 so I know it's not all green hils over there. Of course I've never written anything big enough to spend any significant time on tuning. Don't make too many DB queries is my general rule.

      That said, LINQ is just incredible

      I've been looking for some excuse to use LINQ in my code, but the closest I've come is lambda expressions. Do see the value though.

    10. Re:Doing all my programming in C# by anss123 · · Score: 1

      That's really too bad. I got the feeling that most coders think "get it done now" rather than "get it done right". It is probably the correct attitude to take, not like you get paid extra for clean code, but still....

    11. Re:Doing all my programming in C# by drewhk · · Score: 3, Informative

      "Java checked exceptions do absolutely nothing to help when you're working with dynamically-loaded code, for instance."

      The same is true for invoking methods through reflection. Or transforming bytecode through custom classloaders, etc.

      But these are low-level techniques that should be used with care -- exactly because they can break things in unexpected ways. But this is not an argument against checked exceptions.

    12. Re:Doing all my programming in C# by arjan_t · · Score: 1

      Java checked exceptions do absolutely nothing to help when you're working with dynamically-loaded code, for instance.

      That's only partially true. If the language would only have checked exceptions and you would be coding against interfaces (often still the case with dynamically-loaded code), then checked exceptions would still work, whether the code implementing said interfaces was dynamically loaded or not.

      Now the problem here is that there are also unchecked exceptions which the code might throw, but this is really unrelated to the dynamic loading. One thing that could break things though, is if you not only dynamically load the code, but also execute said code via reflection. Then indeed checked exceptions might not do anything...

    13. Re:Doing all my programming in C# by anss123 · · Score: 1

      Hey, just have the IDEs add "throws exception" to all the methods by default and those folks will be happy. We can then add longjmp() to temp to C holdouts to the embrace of Java, not like the IDE guys would figure out and abuse that call right?, and then finally multiple inheritance to bring in large swaths of old murky C++ code.

    14. Re:Doing all my programming in C# by arjan_t · · Score: 1

      No, it is actually worse to have only RuntimeExceptions and handle none..

      Checked vs unchecked is and endless debate in Java, but to add my 2 cents:

      If you only have RunTimeExceptions, then at run time the error actually will surface if you don't explicitly handle them. This means your unit tests and integration tests (you do have those, don't you?) will most likely catch them.

      Checked exceptions are only useful if you can handle them, but 99 out of 100 times you can't. If there's a SQLException being thrown, seriously, what can your code do about it? In practice what we see is that either exceptions get wrapped and wrapped and wrapped... up till 10 levels or more deep. Alternatively, your code can declare the exceptions being thrown by its dependencies, but then you end up with dependencies bleeding into layers where they have no business.

    15. Re:Doing all my programming in C# by Krahar · · Score: 2, Interesting

      C# is really more sort of the averaging of Java and C++ than anything else,

      C# is just like Java except without some of the problems and with some good things added. E.g. Java generics aren't really worthy of the name, while C# generics are pretty spiffy.

    16. Re:Doing all my programming in C# by M.+Baranczak · · Score: 1

      I disagree. A checked exception in this case would do you absolutely no good; if your application encounters an error during a DB operation, then there's usually nothing you can do to recover, so it doesn't matter if you catch the exception yourself or let the container handle it.

    17. Re:Doing all my programming in C# by Anonymous Coward · · Score: 0

      As someone who used Java generics extensively and is now working with C#, I miss covariance and contravariance.

    18. Re:Doing all my programming in C# by firewrought · · Score: 1

      get a list of exceptions that can be thrown by a call so you know what you could check for

      .NET will generally document expected exceptions, but in general, you should not assume to know all the reasons that a method can fail. Even if you think you know all the reasons a method might fail today, tomorrow that call might be modified to hit a database or do something completely different and whole new failure categories open up.

      If you don't know what to do with an exception (and you usually don't), clean up your resources and throw it up the call chain until you do know what to do with it (log it, tell the user, ignore it and try a fallback strategy, attempt to fix it, wait a few second and try it again, etc., etc.). Distinguishing the type of the exception only matters in special cases where it impacts your response strategy.

      --
      -1, Too Many Layers Of Abstraction
    19. Re:Doing all my programming in C# by Anonymous Coward · · Score: 0

      Are you using C# 4.0, which supports covariance and contravariance?

    20. Re:Doing all my programming in C# by Anonymous Coward · · Score: 0

      Problem is: You _can't_ do things right with Java's checked exceptions.

      Suppose that I have a MyGenericAlgorithm that can be adapted to different things via interface MyGenericAbstraction { void apply(int parameter); }. Now, I need to implement that interface with something that may throw an SQLException. What's the right way to handle that?

      I'll answer myself:

      try {
        MyGenericAlgorithm.invoke(sqlExceptionThrowingThingy.getMyAbstraction());
      } catch (SQLException e) { fail(); }

      Try doing that in Java without useless glue code or polluting the interfaces with stuff that doesn't belong there. Generic exceptions would make it possible but that sounds even more silly than normal Java shit.

    21. Re:Doing all my programming in C# by shutdown+-p+now · · Score: 2, Informative

      C# has declaration-site variance for generics, while Java has use-site variance. What this means is that interfaces which are always co- or contravariant (e.g. IEnumerable in .NET, which is analogous to Iterable in Java) can be declared as such. But if an interface has a mixture of methods, some of which are covariant and some are contravariant, the result has to be invariant in .NET. For example, IList<T> is invariant, because it has both Add(T), and indexer returning T.

      In Java, due to use-site variance, you can have a method which takes a List in a covariant or contravariant way (with "? extends T" and "? super T" wildcards), at which point you're restricted to using only those methods of List which can legally be used covariantly or contravariantly. You cannot do something like that in C#.

      To sum it up: Java generic variance is more powerful, but places a higher burden on API clients, because they have to use wildcards whenever they want variance. C# generic variance is more limited, but is completely transparent to API clients - for them, passing an IEnumerable<Derived> where IEnumerable<Base> is expected "just works".

      But then, of course, C# generics are reified, while Java ones are not. So there is some compromise whichever side you take.

    22. Re:Doing all my programming in C# by shutdown+-p+now · · Score: 1

      C# is really more sort of the averaging of Java and C++ than anything else

      Not quite.

      If we're talking about C# circa 1.0, then it was really by and large semantically Java - single-inheritance-with-interfaces object model, no generics, implicit references etc. But with some syntax - usually borrowed from C++ - thrown it for good measure. For example, class Foo extends Bar in Java became class Foo: Bar in C#, and Foo() { super(123); } in Java became Foo(): base(123) { } in C#. The official story is that this was done to ease transition for C++ programmers (which were the majority back then on MS platform). Many people thought that it was rather done to prevent it from looking too much like Java :)

      Now, it also had a bunch of things of its own - e.g. properties and events as first-class language elements, or explicit "virtual" paired with "override" - which are rather reminiscent of Delphi. Given that the latter was initially designed by Anders as well, this isn't particularly surprising.

      But that's C# 1.0. Since then, things have changed a lot. 2.0 has got proper (reified) generics, and, perhaps even more importantly, first-class functions (closures). 3.0 added type inference and extensive syntactic sugar for list comprehensions (LINQ). 4.0 added the ability to dynamically dispatch methods on name, i.e. duck typing a la Python. All these steps have moved it further and further away from Java, for which the only major change since the time C# 1.0 was released was the addition of generics.

    23. Re:Doing all my programming in C# by Anonymous Coward · · Score: 0

      Sure there is, you can cleanup and notify the user gracefully rather than crashing.

    24. Re:Doing all my programming in C# by sproketboy · · Score: 1

      They should just add checked exceptions but not in the core APIs. Checked exceptions are best uses as domain exceptions. In the core they just confuse things.

    25. Re:Doing all my programming in C# by sproketboy · · Score: 1

      Tomcat is hard to configure? You don't even need to install it. Just unzip into a folder. How hard is that? I know editing text files is hard for you Windoze monkeys but seriously... Unlike IIS you have have multiple Tomcat instances on a single development machine targeting different JVMs. Try to do that in .NET - sorry nope. You'll need whole new windows installations for that.

    26. Re:Doing all my programming in C# by Eskarel · · Score: 1

      I can and have configured Tomcat, and yes, if all you want is out of the box you can unzip it(there's even an installer which will set it up as a windows service). If you want it to actually perform properly under enterprise level loads it's rather a different story.

      I don't want to target multiple .NET runtimes or multiple JVMs because I write internal code and I get to put whatever the hell version of .NET or Java I want onto my servers.

    27. Re:Doing all my programming in C# by Eskarel · · Score: 1

      LAMP is great if all you want is something basic, but MySQL sucks as a database(it's not even the best open source one), and I've yet to encounter a project that could keep a loosely typed scripting language project under control past a certain point. There are a few forums and some mediocre CMSs, but if you want enterprise code, use an enterprise language.

      Linux and Apache are perfectly fine for enterprise code of course, I've written quite a few Linux/Tomcat/Java/Oracle applications.

    28. Re:Doing all my programming in C# by Eskarel · · Score: 1

      Most of the time with web applications a lot of the checking is pointless(one of the things I like about .NET). If I'm doing a get in a Servlet and writing to the HttpResponse fails due to an IOException then there's not really any remotely sensible place to try to handle that. If I'm doing a post, that's a very different scenario. In Java I have to handle both or override the default behaviour for the post.

      I'm also aware of the .NET doco(I'm not a fan of the formatting, but I'm aware of it), it would just be nice to be able to get a list of potential exceptions via the IDE, in an interpreted language like .NET or Java it's not even remotely impossible to actually do that.

    29. Re:Doing all my programming in C# by jrumney · · Score: 2, Insightful

      Java doesn't force you to handle exceptions, it forces you to be aware which exceptions can happen. You just have to declare your own functions as throwing them if you don't handle them.

    30. Re:Doing all my programming in C# by thePowerOfGrayskull · · Score: 1
      Why would you assume that?

      You can -- but there has to come a point where you rely on checked exceptions (as that is their purpose) and handle unchecked exceptions at a higher level; for if an unchecked exception occurs, it will generally be far more serious and won't be something you can handle with a simple error message.

    31. Re:Doing all my programming in C# by Anonymous Coward · · Score: 0

      >>>"rather than farting around with putting god awful VB syntax onto a language which is nothing like it

      What? How you got modded insightful I don't know after that.... C# and VB are the languages... MS is not 'putting ... VB syntax onto a language'

      And yes, I left out the 'god awful' because I don't see that part of your statement either. The worst part of it for me is 'Dim'.... but beyond that, there are no unnecessary noise characters (unless your force them on yourself), the syntax is english-like yet terse, and in Visual Studio, it's auto-formatted decently.

      Oh sure, there are some things that are unbelievable (compiler doesn't enforce returning a value from a function anyone?), but hey, it's a Microsoft product. It just wouldn't feel right without some stupidity somewhere.

      I'm not sure I by the 'LINQ is incredible' part either - oh sure, it's extremely powerful, and does things that you really want it to do..., but if you rely on it, you're non-standard from that moment on, and if you need to port or adapt your code, you are up a creek.

    32. Re:Doing all my programming in C# by bingoUV · · Score: 1

      Can you describe the "common idioms" a bit more? And how do other languages solve those problems?

      I have experience only in C (no "exceptions" as such) and java (the one you are pointing out problems with). I am vaguely familiar with some other languages, but I am not at first name terms with them. So I cannot identify with what you say, though it seems to be interesting.

      --
      Bingo Dictionary - Pragmatist, n. A myopic idealist.
    33. Re:Doing all my programming in C# by drewhk · · Score: 1

      "Checked exceptions are only useful if you can handle them, but 99 out of 100 times you can't."

      Then you just don't handle them! But this will be an explicit decision, while in the RuntimeException case you are not forced to document this decision.

      "In practice what we see is that either exceptions get wrapped and wrapped and wrapped..."

      And this is a good thing. One of the most important job in exception handling is not recovery, what most people think, but changing the abstraction level, collecting context information and giving useful information for debugging.

      "Alternatively, your code can declare the exceptions being thrown by its dependencies, but then you end up with dependencies bleeding into layers where they have no business."

      No, you should declare an own exception, and wrap the exception of the dependencies in that new exception.

      Anyway, most of the exception handling idioms boil down to:
        - wrap, rethrow
        - log, rethrow
        - log, swallow
        - handle, swallow
        - partly handle, wrap, rethrow

      If the exception handling syntax makes these cases concise and readable, and allows to factor out common patterns (attachable exception handlers; inheritance like constructs) then I think all of the pain with checked exceptions could be reduced to the point where the benefits overweight them.

      The problem is that try...catch is not suitable.

    34. Re:Doing all my programming in C# by drewhk · · Score: 1

      "Can you describe the "common idioms" a bit more? And how do other languages solve those problems?"

      Other languages do not have checked exceptions, Java is the only one I think.

      I do not want to repeat myself, so I just link to my other comment where I explain some common cases:

      http://slashdot.org/comments.pl?sid=1707628&cid=32797252

      What I would like to see is more declarative exception handling.

      Some examples:
        - pattern matching on nested exceptions
        - declaring that a class will simply wrap and rethrow all exceptions in a given higher level exception
        - implementing common exception handler routines in a separate class and declaratively attaching them to other classes - AOP style would be handy
        - chaining attached handlers
        - package level declarations about the exception types that could be thrown to classes outside the package

    35. Re:Doing all my programming in C# by bingoUV · · Score: 1

      Coder mistake.

      While designing the code, the coder knew that it is a "generic abstraction". This should have given him a hint to add an exception specific to this abstraction. No implementation level exceptions make sense at this layer because there is no implementation. So, the interface declaration should have said

      MyGenericAbstraction { void apply(int parameter) throws GenericAbstractionException; }

      Now we come to the exception. This should extend the java.lang.Exception. The constructor to create this exception using another exception as the cause makes awesome sense (because implementation will have its own exception types). So create that constructor, and test it well.

      Now the implementer just needs to do

      try {
          MyGenericAlgorithm.invoke(sqlExceptionThrowingThingy.getMyAbstraction());
      } catch (SQLException e) { throw new GenericAbstractionException(e); }

      Generic exceptions would make it possible but that sounds even more silly than normal Java shit.

      What do you mean by "generic exceptions"? If it is java.lang.Exception, yeah it doesn't make sense. But defining a custom exception definitely makes sense. Because any caller at higher layers would need to know that this particular abstraction gave a problem. He can investigate the implementation level cause of this exception by ".getCause()" method.

      But if you are saying the aforementioned GenericAbstractionException sounds silly, I think generic abstractions should also sound silly to you. So why did you create an interface MyGenericAbstraction ?

      --
      Bingo Dictionary - Pragmatist, n. A myopic idealist.
    36. Re:Doing all my programming in C# by bingoUV · · Score: 1

      To add to the sibling post by an AC: if the error is a DB error, I need to inform the appropriate person in the user's organization. So while I cannot rectify the DB problem on my own (maybe the DB is down?), I will log it in such a way that the DBA of the user's organization reads this error message.

      If that is not possible, I will inform the user to contact his DBA, and give enough information for the DBA to be able to solve the problem.

      --
      Bingo Dictionary - Pragmatist, n. A myopic idealist.
    37. Re:Doing all my programming in C# by bingoUV · · Score: 1

      I don't understand. Your other post seems almost to be arguing for java type exception handling. All those idioms are well supported in java.

      Only thing that java does not have is convenience/terseness. But the java language designers have long held that coding must be done in an IDE and it is the IDE's problem if user is having to type a lot, or having to hand-code complicated but well-known idioms. I can't say I completely agree, but in that case, you should say that your only problem with java exception handling is having to use a good IDE.

      pattern matching on nested exceptions

      If you mean string pattern matching, I am horrified at the disaster that it will be. But yeah, object patterns can and are matched in java exception handling.

      try
      {
              throw new java.sql.SQLException();
      }catch(Exception e)
      { // pattern has been matched. Since SQLException is a kind of "Exception".
      }

      - declaring that a class will simply wrap and rethrow all exceptions in a given higher level exception

      IDE functionality. Java just provides a way to wrap. Doing it en-masse on the class is a problem of your IDE.

      implementing common exception handler routines in a separate class and declaratively attaching them to other classes - AOP style would be handy

      This is true. Though I don't see why you would do AOP style coding for exception handling. While developing code, a developer is most aware of the exceptional circumstances each code fragment can run into. Especially with the generous use of checked exceptions in java. If the exception handling "aspect" is left to another day, many exceptions would be missed. If they have to be done together, coder would needlessly have to alternate between business logic aspect and the exception handling aspect. This is the undesirable decoupling of 2 things that go together.

      chaining attached handlers

      I don't know what you mean by this. Is it an instance of partly handle, wrap, rethrow? If so, same argument. Verbose but supported.

      package level declarations about the exception types that could be thrown to classes outside the package

      Could be interesting. Any concrete example where this information would be useful? And how would the compiler / execution engine use it? It can't force the client developer to catch in all methods each of the exceptions that a package was going to throw, right?

      PS:
      And the verbosity/inconvenience is not just a problem with exception handling in java. Method calling with named parameter passing is also something java does not have. It is not needed if you code with IDEs, but for less powerful editors, it would have been extremely useful.

      E.g. computeExponent(base=8, exponent=2) == 64

      computeExponent(8,2) is just too confusing and prone to error.

      --
      Bingo Dictionary - Pragmatist, n. A myopic idealist.
    38. Re:Doing all my programming in C# by yyxx · · Score: 1

      Does Java still have checked exceptions in common use? In that case I envy you guys

      Don't. Checked exceptions are unsound and a design mistake.

      Scratching my head over which exceptions can spew out of a library is annoying,

      You can never know which exceptions can spew out of a library, even in Java. You're supposed to catch the ones that are meaningful to you, let all others pass through, and then have a few general recovery points where you catch everything.

    39. Re:Doing all my programming in C# by yyxx · · Score: 1

      But these are low-level techniques that should be used with care -- exactly because they can break things in unexpected ways. But this is not an argument against checked exceptions.

      Java checked exceptions also fail for simple OOP techniques. If I define a class A with methods throwing exception AX and I give a reference to an instance of A to an instance of class B to get some work done for B, then it's reasonable to expect that I can get and catch AX exceptions when calling methods on B. In Java, I can't do that. It's a totally bizarre restriction that breaks common and basic abstractions.

    40. Re:Doing all my programming in C# by Anonymous Coward · · Score: 0

      There is no way that you can make statically checked exceptions do what they were intended to do; they were a language design mistake because exceptions are inherently not a feature that you can check at compile time. Other languages tried checked exceptions before and they all gave up because they just don't work.

      Using checked exceptions isn't "get it done right", it's just wrong.

    41. Re:Doing all my programming in C# by drewhk · · Score: 1

      "then it's reasonable to expect that I can get and catch AX exceptions when calling methods on B. In Java"

      It is reasonable if B also declares to throw that exception. Otherwise it must wrap it in XB. B must explicitly document that it is letting AX exception through. I don't see why is this a problem.

    42. Re:Doing all my programming in C# by drewhk · · Score: 1

      "I don't understand. Your other post seems almost to be arguing for java type exception handling. All those idioms are well supported in java."

      You misunderstood me then. I am pro checked exceptions and contra try..catch control structure (or it being the only one).

      "Only thing that java does not have is convenience/terseness."

      Every syntax is about convenience/terseness. Otherwise go to binary code directly. While I agree that language designers are reluctant to introduce syntax sugar for each possible use-case, checked exceptions I think important enough to be supported by better syntax.

      "If you mean string pattern matching, I am horrified at the disaster that it will be. But yeah, object patterns can and are matched in java exception handling."

      String matching is obviously no go. I was talking about matching the exception chain that results from deeply nested exceptions. In several cases for correct recovery, you must traverse the exception chain, but some syntax sugar could really help here.

      "This is the undesirable decoupling of 2 things that go together."

      I agree with you on this matter, I think you misunderstood me a bit. I just don't want to repeat the same handling pattern every time but I want it to refactor it to one place. I stumbled many times into problems, when the handling/recovery part was almost the same, but with one parameter changing. In this case your best bet is to factor out some of the handler part into a method (or sometimes it's own class) and call it from the catch blocks. But the try..catch clutter will remain. Don't repeat yourself is violated here.

      "IDE functionality. Java just provides a way to wrap. Doing it en-masse on the class is a problem of your IDE."

      First of all, you cannot delegate every important stuff to the IDE. It makes sense in many cases, but not every time. Also, if I could declare the rethrow case at the beginning of the class, it would make the code more readable. Again, I am talking about syntax.

      "Could be interesting. Any concrete example where this information would be useful? And how would the compiler / execution engine use it? It can't force the client developer to catch in all methods each of the exceptions that a package was going to throw, right?"

      It was a draft idea, but basically it is matching the exception model with the modularity models of OSGi and Jigsaw. In those models, you can hide many aspects of the module behind the explicitly exposed interfaces. Of course if these interfaces declare the throwable exceptions, then my idea is completely unnecessary.

    43. Re:Doing all my programming in C# by bingoUV · · Score: 1

      Every syntax is about convenience/terseness. Otherwise go to binary code directly.

      In the sense I used the word convenience (less typing for the programmer) - I strongly disagree. (Hence) also strongly disagree for terseness.

      (I'll replace binary with assembly from now on, because binary is absolutely useless for developing code.)

      At times compiled code might be longer than assembly code, but programmers might still find it easier to work with higher level language than assembly code.
      1. Higher level languages expose coding ideas to programmers which is easier to relate to / understand.
      2. It reduces repetitive work, but might introduce extra cruft (e.g. variable declarations).
      3. It also makes it easier to make the code more maintainable. E.g. change a constant at one place and have a lot of functionality reflect the change. Or comment out some code for the time being.
      4. And in java's case, the language is also hiding platform specific complications from the programmer. In a round-about way, yes, it prevents the user from having to type code separately for each platform. But in this case, higher level language is mainly helpful because modifying code for each platform is repetitive work and humans are not good at it.

      I was talking about matching the exception chain that results from deeply nested exceptions. In several cases for correct recovery, you must traverse the exception chain, but some syntax sugar could really help here.

      I don't think you have a solution here.

      I just don't want to repeat the same handling pattern every time but I want it to refactor it to one place. I stumbled many times into problems, when the handling/recovery part was almost the same, but with one parameter changing. In this case your best bet is to factor out some of the handler part into a method (or sometimes it's own class) and call it from the catch blocks. But the try..catch clutter will remain. Don't repeat yourself is violated here.

      Very true. I was very perplexed with java (1.3)'s way of doing things when I first got into such a scenario 7 years ago. I was coming from perl and C coding - where I would have used function pointers to solve this problem very elegantly. The try..catch block goes into the function for which I use pointers in all the handling places. Arguments to this functions control its behaviour.

      But it was a harsh discovery for me that java does not have function pointers. The "replacement" is
      1. Reflection : Performance is awful. And it has its own complicated syntax.
      2. Now closures are coming. I think this is the syntactic sugar you are want. Though not exactly what you are asking for.

      "IDE functionality. Java just provides a way to wrap. Doing it en-masse on the class is a problem of your IDE."

      First of all, you cannot delegate every important stuff to the IDE. It makes sense in many cases, but not every time. Also, if I could declare the rethrow case at the beginning of the class, it would make the code more readable. Again, I am talking about syntax.

      If you have followed Java languages' progress, you would have lost hope for terse constructs long ago. Like I did. Java designers' argument has always been that coding has to be done in an IDE. While I don't agree with this position, Java still seems to be the best bet for many situations, so I have come to accept it.

      Readability: IDE helps there too. Just have it to collapse unnecessary code automatically and open only when you need it. It is not Java's way (TM) to reduce verbosity to enhance readability. According to anthropomorphized Java, that is what an IDE is for. But I guess closures is the solution from Java's side in this case too.

      --
      Bingo Dictionary - Pragmatist, n. A myopic idealist.
    44. Re:Doing all my programming in C# by drewhk · · Score: 1

      "In the sense I used the word convenience (less typing for the programmer) - I strongly disagree. (Hence) also strongly disagree for terseness."

      Hm, I think we talk about the same, but maybe using different words. Convenience/terseness is useful if it improves readability, maintainability and helps reducing errors (duplications usually end up with bugs)

      "I don't think you have a solution here."

      No, I don't. In fact, I don't think there is a real possibility to solve this in Java. However, there are other languages, like Scala that I use -- pattern matching is natively supported there, so it is easy to use on exceptions as well. The problem is that most new languages (e.g. Scala) abandon the idea of checked exceptions, which I found to be sad. There were no attempts to take the idea to one step further.

      "2. Now closures are coming. I think this is the syntactic sugar you are want. Though not exactly what you are asking for."

      It helps somewhat, but does not solve everything. I think they will also introduce the resource handling construct that handles safe closing of resources. It is nice, but not generic enough.

      "If you have followed Java languages' progress, you would have lost hope for terse constructs long ago"

      I lost, too. My point was however about checked exceptions in general -- but the only example is Java that I know of, that uses them.

      "According to anthropomorphized Java, that is what an IDE is for. But I guess closures is the solution from Java's side in this case too."

      Well, they lost me already, although I'm interested in the new closures addition.

    45. Re:Doing all my programming in C# by Anonymous Coward · · Score: 0

      MyGenericAbstraction { void apply(int parameter) throws GenericAbstractionException; }

      I have done lots of stuff that way but I feel it's the wrong way. It's just lines after lines of useless bloat for no real benefit.

      What do you mean by "generic exceptions"?

      interface MyGenericAbstraction<T extends Throwable> { void apply(int parameter) throws T; }

      class MyGenericAlgorithm {
          static<T extends Throwable> void invoke(MyGenericAbstraction<T> mga) throws T { mga.apply(42); }
      }

      Almost there, but two problems:

      1. Whatever I'm passing to invoke usually doesn't throw checked exceptions and I know it there so there's no point catching it. But that's no big deal since I can use a dummy RuntimeException as a type argument. Feels a little stupid though.

      2. This is basically just clutter that gets in the way. If Java was smart enough, it could just do this template throwable thing everywhere for me, but that's against their philosophy of checked exceptions. After all, if I catched (Exception) at main() there would be nothing to complain about. (yet that'd be precisely what I want. If I wanted errors I'd leave that trycatch out or add "mustntthrow" specifier to other program places where I want to make sure that exceptions are caught).

      I know you can go on wanking with wrapping exceptions inside others infinitely but it's isn't a good thing or something you should be doing. Exceptions are for exceptional stuff. Ther are not something you should be concerned with when you're writing the middle level abstraction which doesn't even know what is SQL.

    46. Re:Doing all my programming in C# by arjan_t · · Score: 1

      Then you just don't handle them!

      I hear you, but that wasn't what I meant really. When I don't want to handle exceptions because I simply can't handle them, I don't mean I want to swallow them.

      In my personal experience, it seems that in a lot of cases the only sensible course of action is to let the exception bubble up right to some top handler that does 'handle' the exception by simply aborting the operating.

      In a request/response Java EE situation, this simply means aborting the request and displaying a general error page. Runtime exceptions let you do exactly this without all the boiler plate code and verbosity, which can introduce its own bugs simply by means of obfuscating the real code in your system to your programmers.

      No, you should declare an own exception, and wrap the exception of the dependencies in that new exception.

      Indeed, this is a reasonable approach, but one that does lead to very deep levels of chained exceptions. Now if the exception is really exceptional this might not be the end of the world, but constantly applying the wrap-retrow pattern can still add a lot of mental overhead to your code. Sometimes this is justified, but in a lot of cases all you want is the exception to be handled by the top level exception handler. You're then creating lots of specific exceptions, lots of specific try/catch code, but it's never really used since it's only the first exception in the chain that counts and nothing is ever done with the intermediate ones.

      I do agree that checked exceptions are a great way to force people to document what exceptions a method is expected to throw, which is indeed a benefit.

      Anyway, I didn't really start the move away from checked exceptions, just observing that this seems to be happening ;)

    47. Re:Doing all my programming in C# by yyxx · · Score: 1

      It is reasonable if B also declares to throw that exception. Otherwise it must wrap it in XB. B must explicitly document that it is letting AX exception through. I don't see why is this a problem.

      It's a problem because class B may have been written long before class A and because it knows nothing about class A other than those aspects of class A that are required by the interface between the two.

      The problem is particularly serious with control abstractions. Just like a for(;;) { ... } construct lets all exceptions pass through without declaration and without forcing you to catch them, so should classes, because many classes that implement control abstractions are just more sophisticated versions of for loops.

      For example, class B may abstract a tree search, and it may be used with different classes. I may reasonably want to write (pseudo-code):

      try {
              result = new TreeSearch().search(new FileSystemTree("/"),"something");
      } catch(IOException e) { ...
      }

      That is, TreeSearch.search invokes some methods on FileSystemTree that may trigger an IOException, but TreeSearch doesn't and shouldn't need to know about that.

      The problem is kind of fixable if you have a file system in which classes like TreeSearch are parameterized not just by types but also by exceptions. But even that doesn't fix all cases, and it's a huge amount of bother for no demonstrable gain in program correctness.

      The real problem with exception declarations is that they actually cause people to handle exceptions badly. Last I looked (a few years ago), the Java source code was full of bugs in exception handlers that people put in only because they were trying to make the compiler shut up about catching exceptions.

    48. Re:Doing all my programming in C# by drewhk · · Score: 1

      "That is, TreeSearch.search invokes some methods on FileSystemTree that may trigger an IOException, but TreeSearch doesn't and shouldn't need to know about that."

      Ok, that is really a problematic case. However, if Java would allow to attach exception handler classes to other classes this would be easily solvable.

      "The real problem with exception declarations is that they actually cause people to handle exceptions badly."

      No, the real problem is that people don't give a damn about proper exception handling, checked or not. Checked exceptions just make them more annoyed, because they have to do some work to get rid of them - therefore they go to the unchecked language.

    49. Re:Doing all my programming in C# by yyxx · · Score: 1

      No, the real problem is that people don't give a damn about proper exception handling, checked or not.

      Well, yes, that is the problem. Proper exception handling is to handle those exceptions that you know how to handle and to let all other exceptions propagate upwards.

      Checked exceptions just make them more annoyed, because they have to do some work to get rid of them - therefore they go to the unchecked language.

      Checked exceptions make proper exception handling harder because they force people to concern themselves with exceptions they don't know how to handle and they should just leave alone.

    50. Re:Doing all my programming in C# by drewhk · · Score: 1

      "Checked exceptions make proper exception handling harder because they force people to concern themselves with exceptions they don't know how to handle and they should just leave alone."

      No, they only force people to indicate that they let that exception propagate upwards. In the unchecked case I could get exceptions that I was completely unaware that could happen - even if I probably could handle them.

    51. Re:Doing all my programming in C# by yyxx · · Score: 1

      No, they only force people to indicate that they let that exception propagate upwards

      That is what "concerning themselves with exceptions they don't know how to handle" means.

      In the unchecked case I could get exceptions that I was completely unaware that could happen - even if I probably could handle them.

      It's wrong handle exceptions just because you "could". Unless you have a clear reason and strategy to handle an exception, the correct thing is to leave it alone because there should be a reliable, general purpose exception handler above you in your call chain anyway.

    52. Re:Doing all my programming in C# by drewhk · · Score: 1

      "That is what "concerning themselves with exceptions they don't know how to handle" means."

      Even if you don't know how to handle, you should be aware of the exceptional control paths of the code you use. Also, handling is not necessarily recovery, but also context and debug information collection.

      "It's wrong handle exceptions just because you "could"."

      Let's reword my previous statement then, to express myself more clearly:
      In the unchecked case I could get exceptions that I was completely unaware that could happen - even if I probably could _recover_ from them.

      But because I am unaware that the given code could throw that exception I just don't write the handler.

    53. Re:Doing all my programming in C# by yyxx · · Score: 1

      In the unchecked case I could get exceptions that I was completely unaware that could happen - even if I probably could _recover_ from them.

      You always can get exceptions that you were completely unaware of, even in Java. Not only does Java have exception types that don't need to be declared, because the static exception declarations don't actually match the semantics of exceptions, people end up wrapping them so often that you still don't know what you're getting.

      You shouldn't write recovery code where you think exceptions are thrown, you should write recovery code where it makes sense to write recovery code. Knowledge of the specific exceptions only helps with improving the quality of the recovery code, but the system really should do something sensible even for completely unknown exceptions.

      Thinking like yours--namely driving recovery code through knowledge of where exceptions are raised--is why so many Java programs keep spewing out all those uncaught exceptions.

    54. Re:Doing all my programming in C# by drewhk · · Score: 1

      "Thinking like yours--namely driving recovery code through knowledge of where exceptions are raised--is why so many Java programs keep spewing out all those uncaught exceptions."

      I totally disagree on this matter, but let's finish this thread.

    55. Re:Doing all my programming in C# by yyxx · · Score: 1

      Well, you can "totally disagree", but what are your reasons? I think if you want to argue that Java's exception handling is a better way of doing it, it would be good if you could point at some observations and some examples/research from other languages supporting your view.

      What is see is that: (1) Java programs spew out uncaught exceptions more frequently than programs in other languages with exceptions, (2) when I reviewed Sun's Java source code, a large percentage of exception handlers were incorrect, and (3) even religiously statically typed languages like ML do not use exception declarations (in fact, they tried it in early versions of the language and then removed them because they found that they don't make sense).

    56. Re:Doing all my programming in C# by drewhk · · Score: 1

      Well, I really wanted to finish it here, as this thread starts to get really long, but I have to answer your points.

      "I think if you want to argue that Java's exception handling is a better way of doing it"

      If you had taken really care to read my comments, then you would not make such statement. I am pro-checked exceptions but I also stated that I find the Java implementation to be inflexible. I am not saying anything like "Java's exception handling is the better way".

      "it would be good if you could point at some observations and some examples/research from other languages supporting your view."

      If you do not have citations then you cannot have a good point, that's what you imply? Or are you stating that every important research is already done, and no new research will ever happen that deserves attention?

      "(1) Java programs spew out uncaught exceptions more frequently than programs in other languages with exceptions"

      What I see, is that people fuck up exception handling in ALL of the languages that have exceptions regardless of checked or not-checked. Also, a lot of people still avoid using exceptions at all.

      It is also important to note that most of the exceptions coming out from Java programs are NullPointerExceptions.

      "when I reviewed Sun's Java source code, a large percentage of exception handlers were incorrect,"

      Sun messed up other things, too. If you want to see some nice exception handling, look at the code of the Guice framework.

      "even religiously statically typed languages like ML do not use exception declarations (in fact, they tried it in early versions of the language and then removed them because they found that they don't make sense)."

      I don't know ML specifically (although I learned SML long ago), but many functional languages adopt the two-state return type, like the Option[T] type in Scala. Now constructs like this with a strict type system ends up people writing almost the same code as with try...catch.

    57. Re:Doing all my programming in C# by yyxx · · Score: 1

      If you had taken really care to read my comments, then you would not make such statement. I am pro-checked exceptions but I also stated that I find the Java implementation to be inflexible. I am not saying anything like "Java's exception handling is the better way".

      So which language implements static exception declarations better then? If you don't know of any, then I'm wondering why nobody has come up with any such language in 50 years of programming language design.

      If you do not have citations then you cannot have a good point, that's what you imply? Or are you stating that every important research is already done, and no new research will ever happen that deserves attention?

      I didn't ask you for "citations". Observations, specific anecdotes, and examples would do. I've given some (ML, looking at the Sun Java source code, etc.), I'm not asking for more.

      What I see, is that people fuck up exception handling in ALL of the languages that have exceptions regardless of checked or not-checked. Also, a lot of people still avoid using exceptions at all.

      Well, the question is whether checked exceptions cause people to "fuck up" in more ways than otherwise. Java is the only language where I have seen deployed, supposedly working applications output exception backtraces on standard output. Haven't you seen that?

      It is also important to note that most of the exceptions coming out from Java programs are NullPointerExceptions.

      My point is that if you see a backtrace, that means there is no recovery code; I consider that a problem. Why do you think there is no recovery code?

      "when I reviewed Sun's Java source code, a large percentage of exception handlers were incorrect," Sun messed up other things, too. If you want to see some nice exception handling, look at the code of the Guice framework.

      Yes, but if even the creators of Java can't do exception handling well with declarations, what reason is there to believe that declarations provide any benefit? (In fact, a lot of the Java exception handling code has clearly been put in because the compiler was complaining, but the code was incorrect. Arguably, Java's exception handling requirements caused errors to be introduce.)

      I don't know ML specifically (although I learned SML long ago), but many functional languages adopt the two-state return type, like the Option[T] type in Scala. Now constructs like this with a strict type system ends up people writing almost the same code as with try...catch.

      Option[T] in functional languages is the equivalent of alternatively returning a null pointer; you use it when returning nothing is an option during normal operations. Exceptions are for unexpected occurrences, not for loop exits or alternate return values, among other things because exceptions may be extremely slow. Program as if every exception contains a "sleep(1)".

      Scala has exceptions but doesn't check them, which also tells you something when a statically typed Java derivative dispenses with checking exceptions.

      So, I'm still wondering whether there is any argument or example for checked exceptions other than "I think they are a good idea". I'm genuinely interested. I doubt it's going to convince me, but that's not the point. At least I'd like to understand more why people want checked exceptions because I simply don't understand why anybody would want them.

  6. Letting Java languish is not the problem. by Eskarel · · Score: 4, Insightful

    Oracle will not let Java languish, they need Java to exist because it's part of their ecosystem now whether they wanted it or not. It's a lot easier to connect to an Oracle database using Java than it is with .NET, and Oracle really doesn't want .NET to win since MS SQL is now a viable alternative(and substantially cheaper) than Oracle for all but the largest of data sets.

    The issues for Java are either Oracle getting into a fight with IBM and resulting in a fork of Java or distrust of Oracle pushing a critical mass of developers away from Java and onto .NET. As to the first, Oracle has to suppress their natural desire to charge like wounded bulls for everything they own, and try not to interfere with the JCP much at all, which is a big ask really. For the second, it's already starting to happen in certain areas. There are shops out there who have spent an awful lot of time and money getting Oracle out of their DC and they don't want it back again.

    1. Re:Letting Java languish is not the problem. by Anonymous Coward · · Score: 1, Interesting

      You're saying there are people who don't want any Oracle products (including Java) for religious reasons? I can assure you that there are lots of MS-haters too, but I don't believe either are a real factor.

    2. Re:Letting Java languish is not the problem. by Threni · · Score: 1

      > It's a lot easier to connect to an Oracle database using Java than it is with .NET

      It's hardly difficult to connect to Oracle using .net. In fact, it's identical to how you'd connect to SQL Server using .NET. Hell, I'm still supporting VB6 apps which connect to Oracle and that's also a piece of piss.

      What complexity are you talking about? Installing the drivers, establishing the connection, or executing arbitrary SQL statements and stored procedures?

    3. Re:Letting Java languish is not the problem. by ultranova · · Score: 1

      It's a lot easier to connect to an Oracle database using Java than it is with .NET, and Oracle really doesn't want .NET to win since MS SQL is now a viable alternative(and substantially cheaper) than Oracle for all but the largest of data sets.

      So... should we expect to see using non-Oracle databases from Java becoming harder?

      --

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

    4. Re:Letting Java languish is not the problem. by rbrightwell · · Score: 1

      > It's a lot easier to connect to an Oracle database using Java than it is with .NET

      Connecting to Oracle with .Net is cake. I don't see the "a lot" harder part you are talking about.

    5. Re:Letting Java languish is not the problem. by Eskarel · · Score: 1

      I meant primarily in the ORM sphere. If you use nHibernate you need to install either the full Oracle Client or the ODAC on your IIS server, Java just takes a small JAR file copied into the right location.

      For entity framework as far as I can work out you need to actually pay for something that works remotely well.

    6. Re:Letting Java languish is not the problem. by marcosdumay · · Score: 1

      Well, if Oracle creates an incompatible version of Java, and starts selling it for big prices and requiring it to connect into their database, it will be a giant shot on their foot. Old Oracle customers can't migrate away from them now, since rewriting their SQL code would be too expensive, but rewriting their Java code would be orders of magnitude more expensive. You can't expect rationality from all of any population, but I'm quite confident that most of their customers would choose to save some 99% of the expensive, and ditch the database.

  7. Java isn't really built for the future is it? by erroneus · · Score: 1, Troll

    There have been many discussion about multi-core processing being the way forward as we have already, more or less, reached the limit of what can be done with a single processor. Multi-core and multi-processor methods are expected to transition to multiple cores. At the moment, we have the core OS managing processor time on multiple processors but that's not the efficiency that has been imagined even it if it helpful and yields good results. So what about Java? The language itself is of the classical variety. The "interpreter/VM" of Java is what runs the code, but I haven't seen or heard anything in the way of it advancing to take advantage of multi-processor platforms.

    Is Java doomed to get stuck behind in the single processor world or will it actually pave the way forward by running its VM across multiple cores?

    1. Re:Java isn't really built for the future is it? by betterunixthanunix · · Score: 1

      There have been many discussion about multi-core processing being the way forward as we have already, more or less, reached the limit of what can be done with a single processor.

      The 1970s, 1980s, and 1990s called, and they want their predictions back. People have been saying that single core architectures have reached their limit for a long time now, so what makes you think it is definitely true now as opposed to a decade ago?

      --
      Palm trees and 8
    2. Re:Java isn't really built for the future is it? by roman_mir · · Score: 1

      Just what are you talking about? Blaming a language for something that is an architectural decision?

      I've been using multiple cores in a 2-quad core processor environment for over a year now, of-course my design allows me to do so and has nothing to do with the language itself.

      Under GNU/Linux use taskset to attach a process by Id to a specific core (or to a number of cores) and start more than one JVM and have your application's architecture use that cluster correctly.

    3. Re:Java isn't really built for the future is it? by Eudial · · Score: 4, Insightful

      You have an aptly chosen user name. Not only is multi-threaded programming in Java quite easy to use, Java hasn't been interpreted in quite a long time.

      --
      GAAH! MY PRINTER IS ON FIRE!!! PUT IT OUT! PUT IT OUT!
    4. Re:Java isn't really built for the future is it? by arjan_t · · Score: 4, Insightful

      Is Java doomed to get stuck behind in the single processor world

      Far from it actually... of course Java has had the absolute low level concurrency primitives from the very beginning (Threads, synchronized blocks, wait/notify). More than half a decade ago, the java.concurrent library was added to the platform, which added tons of goodies for concurrent/parallel programming like concurrent maps, blocking queues, thread pools and executor services, cyclic barriers, programmatic locks with timeouts (which actually performed better than the build-in locks based on the synchronized keyword) etc.

      Now Java 7 will be extended with the join/fork framework, which is essentially a thread pool and support code for (recursively) computational intensive operations and supports advanced features like work stealing. The join/fork framework has been specifically designed to scale into the many, many multi-core range. Not just quad, hex or oct cores but well beyond that.

      Parallel array is another topic on the agenda, which allows you to express in an almost declarative style operations on arrays, which the library will then execute for you in parallel. To really make this work elegantly, closures are needed, which were on and off the radar for the Java SE 7 release. Because of that, parallel array has somehow stalled. Now that closures are back, so might parallel array be, but I haven't heard anything about it for a while to be honest.

      This blog post has a nice summary about some of the added concurrency items in Java 7: http://www.baptiste-wicht.com/2010/04/java-7-more-concurrency/

    5. Re:Java isn't really built for the future is it? by Anonymous Coward · · Score: 0

      Well it's quite simple for most programmers to reach that conclusion. All you need do is ignore every piece of technical information available and pay close attention to vague controversial bullshit parroted by ignorant morons.

    6. Re:Java isn't really built for the future is it? by ultranova · · Score: 1

      People have been saying that single core architectures have reached their limit for a long time now, so what makes you think it is definitely true now as opposed to a decade ago?

      The fact that CPU makers have stopped boasting about their chips megahertz rating and instead switched to boasting about how many cores they have comes to mind. Also, graphics cards are massively parallel (1600 cores in Radeon 5870), and there seems to be a push to get them to work on general computing.

      --

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

    7. Re:Java isn't really built for the future is it? by Anonymous Coward · · Score: 0

      Mostly because the companies that actually make CPUs have given up on single-core performance, and are focusing primarily on multi-core CPUs.

      Not long ago, a new generation of CPUs would have much higher clock speeds than the previous generation, in addition to being more efficient. You could pretty much count on single-core performance doubling every couple of years or so.

      That's no longer the case. Now, new generations of CPUs have comparable clock speeds to the previous generation (usually between 2GHz and 3GHz), usually increasing only a little as fabrication processes improve. They're still more efficient, although less so. Performance improvements are actually coming from putting more cores onto a single die.

      Intel have gone from a dual-core CPU to a six-core CPU in around five years.

    8. Re:Java isn't really built for the future is it? by careysub · · Score: 3, Insightful

      ... To really make this work elegantly, closures are needed, which were on and off the radar for the Java SE 7 release. Because of that, parallel array has somehow stalled. Now that closures are back, so might parallel array be, but I haven't heard anything about it for a while to be honest...

      Elegance? Closures? Now you have me scared. Really scared.

      The most serious problem with Java today is the whole complexity of the generics feature added in Java 5. Typing container classes was fine (and the only thing any working programmer I have talked to actually uses), but as soon as you venture beyond that it descends into a nearly incomprehensible API, all in pursuit of the elusive and trivial pursuit of absolute type safety (at which it fails anyway). Angelika Langer's FAQ about Java generics is 512 pages long. One of the world's leading Java experts, Ken Arnold, cannot explain the meaning of the Enum generic class's definition, I could go on and on.

      As a whole the generics is a useless and dangerous disaster. If you mastered Langer's FAQ and could actually write code using generic wildcards no other programmer could understand and maintain your code. And I am doubtful that you could yourself, 6 months later. Java generics seems to require at least a graduate level course in type theory to use (possibly an actual degree in the field).

      And the root cause of this disaster, as opposed to a useful tweak (typing containers and letting it go at that) is the search for "elegance" in a formal Comp Sci PhD dissertation type way.

      What we need right now is for whoever is guiding Java development to find away to back out of the generics disaster to simplify the language and leaving only features people can actually use. This will clear the field for actual useful innovations.

      --
      Starships were meant to fly, Hands up and touch the sky - Nicky Minaj
    9. Re:Java isn't really built for the future is it? by betterunixthanunix · · Score: 1

      So you are basing your argument on marketing? The parallel processing on graphics cards is only suitable for a few problems; general purpose programs do not gain much from the level of parallelism that graphics cards offer, and the style programming that is being pushed by Nvidia (CUDA) is not at all suitable for most computing tasks. Shared memory architectures have been tried many times in history, and hit very serious walls when issues like hot spots and coherency come about; creating a 64 core shared memory machine is right around the upper limit of usefulness even for tasks that lend themselves to parallel programming, and that has been the case for a long time now (it was the case long before the current physical problems with semiconductor clock speeds). The reason that boasting about megahertz rates has ended is mainly that the chip makers do not know how to increase clock speeds any further on silicon without creating problems with power density and cooling; other semiconductor materials which can overcome these problems are known but are not yet practical or economical.

      People talk about parallel programming like it is some kind of silver bullet that is going to make everything happen faster, when the reality is that we really have no idea how to improve most programs by executing code in parallel. Even if we ignore the huge amount of IO-bound code out there and focus only on those programs that are CPU-intensive, there are plenty of tasks that have too many data dependencies or that wind up create hotspots, which kill performance in parallel programs.

      Worse still is the fact that single core architectures are not even being used to their full potential. x86 has tons of instructions that are unused by most programs, even programs that could take advantage of those instructions, because compilers have a hard time figuring out how those instructions can be used. There are plenty of programs that could use the SSE instructions, even in cases where there is no vector math in the code, but compilers are generally unable to take advantage of the majority of instructions out there. Claiming that we have hit the limit of single core architectures, when we are not even using them to their full potential, is not very accurate.

      --
      Palm trees and 8
    10. Re:Java isn't really built for the future is it? by arjan_t · · Score: 1

      ... To really make this work elegantly, closures are needed, which were on and off the radar for the Java SE 7 release. Because of that, parallel array has somehow stalled. Now that closures are back, so might parallel array be, but I haven't heard anything about it for a while to be honest...

      Elegance? Closures? Now you have me scared. Really scared.

      Don't be afraid for the unknown my brother. For these kinds of libraries closures actually are very elegant. Apple added a similar thing to C for their GCD library.

      And about generics, they are definitely not a useless and dangerous disaster. Yes, you can go overboard with them, but when used in moderation (i.e. 'typing containers'), they work perfectly fine. Much better than having to downcast Object all the time to some type I think might be inserted into the collection.

    11. Re:Java isn't really built for the future is it? by etymxris · · Score: 5, Insightful

      Generics seem pretty straightforward to me, even the "? extends Whatever" syntax. Maybe you could give some concrete examples as to the problems with generics. The only problem right now is that type erasure makes arrays of generics impossible. Hopefully they'll fix that with the next revision.

    12. Re:Java isn't really built for the future is it? by M.+Baranczak · · Score: 2, Insightful

      I don't think generics are a 'disaster'. More like 'potential disaster if you don't watch your ass'. And to date, I still haven't seen a better way to do it. (Your suggestion, "typing containers and letting it go at that", makes no sense; there was no way to do that without adding generics to the language, or something that works like generics.)

      Anyway, it doesn't matter. There's no way in hell that they'll be removing a widely-used feature from future versions of the language. As long as we're coding in Java, we're stuck with generics.

    13. Re:Java isn't really built for the future is it? by dominious · · Score: 3, Insightful

      As a whole the generics is a useless and dangerous disaster

      You keep repeating that. Citation needed.

      Java generics seems to require at least a graduate level course in type theory to use (possibly an actual degree in the field)

      So? Is this a bad thing? It's like saying "expert field" seems to require at least "expert field" graduate level course. If you are no expert, then don't use java generics. And if you can't read other's code, then maybe we should hire someone who can.

      I remember using java generics to build a visual keyboard for any kind of text component. I'm reading my code now, and yes, I understand it.

    14. Re:Java isn't really built for the future is it? by drinkypoo · · Score: 1

      So you are basing your argument on marketing?

      Everyone and their mom is building processors for the consumer and server markets alike with more and more cores. Even handhelds have gone multicore. If this doesn't tell you that we're in the age of multicore processing, then I don't know what can help you. But maybe you could try to keep up with the pack so that you too can see where we are headed.

      Right now basic limitations of physics mean that we're going to have to make a sort of right turn and go beyond basic photo-litho procedures if we're going to continue making smaller features. So for at least a while we can expect to see a bunch of cores.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    15. Re:Java isn't really built for the future is it? by lehphyro · · Score: 1

      Did you ever heard of Azul Systems? They sell hardware with up to 768 processing cores on 16 processor chips and 768 Gbytes of memory and a JVM optimized for this kind of hardware.

    16. Re:Java isn't really built for the future is it? by HiThere · · Score: 1

      Well, that would work. But it would be LOTS of work.

      A better choice would be a dataflow language, like Prograf was. (Though preferably one that didn't only have graphical representations of it's programs.)

      In the meantime, even Google's go would appear to be an improvement over Java in this area. (It needs LOTS of work on it's documentation...or at least it did the last time I looked at it. And it's libraries are still pitiful...but they claim a knowledgeable user can add any C library, so that should be quickly solved...if their claim is correct.)

      But for now... Unicode made me decide that C and C++ weren't appropriate languages. (Perhaps C++ 2012 will change my mind. But I really wish they could also add garbage collection, even if there was a requirement that you never cast a non-pointer to a pointer.) D is really nice, but it's got severe library problems. Python is good, if you're doing the right applications. Ruby is elegant, but, like Python, only for the right applications. (Both are slow at handling large datasets.)

      So. Java is a compromise language, but it's a good compromise, for now. (Something about the code really grates on my teeth, and it's quite verbose, but it seems a decent compromise.) But getting Java to work on multiple processors strikes me as quite icky, and very system dependent. (There's probably some way to automate the starting of processes and binding them to processors, but I can't think of one that could dynamically adapt to other system loads. [nice and renice have their points, but those are shell commands, not all that effective, and it's hard to boost the priority of another process when something else is waiting for it's result.])

      I really think that what's needed to use large numbers of cores effectively is a new language. Probably one inspired by Prograf and Occam. And it's got to be able to use C (and preferably C++) libraries without much user coaxing. Normal FFIs just don't cut it. (This probably means that wrappers for the functions need to be included with the language installation.)
      N.B.: Even *this* language wouldn't be sufficient for the next generation of 100's to 1000's of cores. People just can't consciously think in that kind of pattern. Language is serial. But there might be some automated way to convert a program in a language specified in the manner I mention into one suitable for more parallelized computation. Or perhaps not.

      At a bare minimum languages should start to use some phrase equivalent to "for each" to mean "This is a block of instructions that should be executed many times, but the order in which the blocks is executed is not specified. They can be executed in parallel on different processes." rather than using it to mean a really shallow variant of "for".

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
    17. Re:Java isn't really built for the future is it? by ultranova · · Score: 1

      So you are basing your argument on marketing?

      I'm basing my argument on the simple logic that if a CPU manufacturer could make a single-core CPU that's significantly faster than the current ones, they would, rather than force the programmers to make parallel programs which, as you yourself noted, is hard.

      Was this really that difficult to understand, or did you simply figure this would be a nice cheap shot?

      People talk about parallel programming like it is some kind of silver bullet that is going to make everything happen faster, when the reality is that we really have no idea how to improve most programs by executing code in parallel. Even if we ignore the huge amount of IO-bound code out there and focus only on those programs that are CPU-intensive, there are plenty of tasks that have too many data dependencies or that wind up create hotspots, which kill performance in parallel programs.

      Yes, this is all true. Which is simply more evidence that single-core processors have hit their limit: after all, why would the processor makers keep pushing parallel chips otherwise?

      Besides, single-core chips have long been parallel. The original Pentium had two pipelines, allowing it to perform two instructions in parallel (altought they weren't equivalent). More were added in later models, however the data dependencies you noted meant that came increasingly hard to keep them all busy, requiring more and more transistors for the control logic. Hyper-Threading was an attempt to help the situation, based on the assumption that two different threads would have less dependencies than the nearby instructions of a single one. Multi-core CPUs simply mean that the processor makers have given up, and are spending the transistor budget of the chip for several separate cores rather than trying to boost a single one.

      Worse still is the fact that single core architectures are not even being used to their full potential. x86 has tons of instructions that are unused by most programs, even programs that could take advantage of those instructions, because compilers have a hard time figuring out how those instructions can be used.

      Um, what?

      There are plenty of programs that could use the SSE instructions, even in cases where there is no vector math in the code, but compilers are generally unable to take advantage of the majority of instructions out there.

      SSE is an example of parallel execution. Compilers have problems using it for the same reason they have problems parallelizing programs in general: it's hard.

      Claiming that we have hit the limit of single core architectures, when we are not even using them to their full potential, is not very accurate.

      Frankly, I doubt that you understand what you're talking about. Your earlier comment about unused x86 instructions kinda implies that.

      --

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

    18. Re:Java isn't really built for the future is it? by siride · · Score: 1

      It will require a different paradigm for programming. Programs these days are built around monolithic flows of execution with lots of global and interconnected state. These really can't be parallelized. I don't know what the answer is, although I have some naive ideas based around extreme encapsulation and loose coupling. I'll leave solving that problem to people who are smarter than me.

    19. Re:Java isn't really built for the future is it? by HiThere · · Score: 1

      The trouble with generics is that to allow backwards compatibility they broke the implementation. Otherwise it's an excellent idea. (I'm not really sure I like the syntax, though.)

      Still, if you use them properly and carefully, they allow much cleaner code.

      OTOH, I'm not at all sure about Java7. I recently downloaded NetBeans 6.9, and it keeps crashing. It's usable, but just barely. And not enough that I continued to use it. (I've started to use Eclipse instead. This is a pity, as Eclipse seems to assume that my screen is larger than it actually is, or possibly that I surely couldn't want to see anything besides it's wonderful self.) Now it's not fair to judge Java7 by NetBeans6.9...but it causes me to feel cautious.

      OK, now I've read the linked story. It doesn't mention anything about multi-cores except in cone of the comments. It talks about threadpools and things that are lighter then threads. (OK. I seem to remember that Java threads are now system processes, at least on Linux, but they once weren't, so I don't feel any guarantee that these still are.

      Still, it threads are processes, and TransferQueue means what it might mean, then Java will be superior to many languages in concurrent processing. Unfortunately, I don't think that's sufficient. At this rate some development of Erlang will be the next major language. (They've *got* to add ways to do decent graphics into the language in an accessible form.) Mind you, I don't think Erlang is the right model. But it's one that's a lot better (in the multiprocessing area) than what is being proposed for Java, C, C++, Ruby, Python, ...

      What's needed is a language where the *executable* can look at what it needs to do and what it's environment is, and decide how to parcel out the tasks. This is where dataflow languages excel. But they don't do well in single or dual processor configurations, so their development has lagged seriously.
        (I'm not familiar with any that currently exist. Only with a couple that used to exist. They were, in the proper phrase, far before their time.)

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
    20. Re:Java isn't really built for the future is it? by betterunixthanunix · · Score: 1

      Besides, single-core chips have long been parallel.

      Which has little to do with multithreading or writing parallel programs, so what exactly is your point? At best, this can be taken advantage of by programmers writing code that their processors are better at executing in parallel, which is more of a job for their compiler.

      SSE is an example of parallel execution.

      No, it is an example of vector math, which is related to parallel execution, but not quite the same. Programmers using SSE instructions are still writing programs as a single instruction stream. There is no locking or contention to deal with in vector math, there are guarantees about execution order (at least as far as the results of the execution are concerned), and so forth. Compilers have trouble making use of vector math instructions because it is difficult to tell when using those instructions is appropriate, at least with current compiler technology and algorithms.

      Frankly, I doubt that you understand what you're talking about. Your earlier comment about unused x86 instructions kinda implies that.

      Then you have never bothered to take a look at how many x86 instructions there are, and how many of those instructions are actually placed in the code generated by your compiler, or how many times the programs on your system actually use those instructions. Even the Intel compiler team has not figured out how best to use the x86 instruction set. Seriously, take a look at the situation before asserting that single core processors are at their limit.

      --
      Palm trees and 8
    21. Re:Java isn't really built for the future is it? by ultranova · · Score: 1

      Besides, single-core chips have long been parallel.

      Which has little to do with multithreading or writing parallel programs, so what exactly is your point?

      The point is that modern processors (everything from Pentium on) are basically parellelizing the program on the fly. Since laws of physics set limits to the clock rate, and laws of logic set limits to how few clock cycles it's going to take to perform an operation (1 at the absolute minimum), the only remaining source of further speed is performing multiple operations per clock cycle.

      At best, this can be taken advantage of by programmers writing code that their processors are better at executing in parallel, which is more of a job for their compiler.

      It's a job both for the compiler and the processor's AI. The former generates the assembly code, and when its executed the latter further compiles it to processor internal microcode and queues microcode instructions for execution in processor's various units, trying to keep them all busy all the time.

      No, it is an example of vector math, which is related to parallel execution, but not quite the same. Programmers using SSE instructions are still writing programs as a single instruction stream.

      SSE is an instruction set that allows certain operations to be carried out for multiple registers in parallel. And as I already stated, programs written as a single instruction stream are actually executed with as many instructions in parallel as the CPU can manage.

      There is no locking or contention to deal with in vector math, there are guarantees about execution order (at least as far as the results of the execution are concerned), and so forth.

      Actually, there is, it simply all happens inside the processor where you the programmer don't see it. I told you, modern processors execute multiple instructions in parallel; that requires locking and ensuring that a value has been calculated before any instruction requiring it arrives at the stage it's required in, and so forth.

      Compilers have trouble making use of vector math instructions because it is difficult to tell when using those instructions is appropriate, at least with current compiler technology and algorithms.

      Compilers have trouble making use of SSE and friends for the exact same reason they have trouble automatically parallelizing programs: it's hard to look at low-level construct and trying to figure out what the programmer was trying to do. And better algorithms would, of course, solve the whole problem, and allow automatic generation of multithreaded programs.

      Then you have never bothered to take a look at how many x86 instructions there are, and how many of those instructions are actually placed in the code generated by your compiler, or how many times the programs on your system actually use those instructions. Even the Intel compiler team has not figured out how best to use the x86 instruction set. Seriously, take a look at the situation before asserting that single core processors are at their limit.

      If x86 instruction set contained an instruction that caused the processor to send "Help I'm a CPU" to some PCI device in Morse, would a compiler that failed to use this instruction "have not figured out how best to use the x86 instruction set"?

      Look, I get that there are lots of instructions that don't get used much, but that has nothing to do with the speed of programs. For example, few people use x86 Real Mode, and those who use Protected Mode usually don't use segments, since simply using just plain paged memory is faster and simpler.

      I'm not sure what problems in your mental model of a processor could cause this bizarre obsession with the number of different instructions used - do you perhaps think that different instructions are like cylinders of a car?

      --

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

    22. Re:Java isn't really built for the future is it? by careysub · · Score: 2, Interesting

      As a whole the generics is a useless and dangerous disaster

      You keep repeating that. Citation needed.

      Since this is the first time I have ever commented on this topic it seems unlikely that I "keep repeating it". And I gave two examples in my comment. But also see Ken Arnold's opinion: http://weblogs.java.net/blog/arnold/archive/2005/06/generics_consid_1.html and http://www.artima.com/weblogs/viewpost.jsp?thread=222021 and Joshua Bloch's attempts at favorable treatment are pretty damning: http://java.sun.com/developer/technicalArticles/Interviews/bloch_effective_08_qa.html.

      Java generics seems to require at least a graduate level course in type theory to use (possibly an actual degree in the field)

      So? Is this a bad thing? It's like saying "expert field" seems to require at least "expert field" graduate level course. If you are no expert, then don't use java generics. And if you can't read other's code, then maybe we should hire someone who can.

      Indeed it is a bad thing. A problem that all excessively obscure and complex languages have rapidly revealed (C++, Perl) is that every difficult-to-use feature gets used (if it is usable at all) and has to be supported by every other programmer eventually since 90% of all programming is support of existing code.

      The saving grace for Java generics is that beyond container typing it seems sufficiently hard to use that it rarely gets used. Some time back I scanned the source of several substantial and active open source projects without finding any examples in use beyond container typing.

      I remember using java generics to build a visual keyboard for any kind of text component. I'm reading my code now, and yes, I understand it.

      Beyond container typing what aspects did you actually use? Have you ever written one genuine generic algorithm? That is - an algorithm with a generic interface that takes any appropriate generic type and returns an appropriate result type while maintaining typing throughout?

      --
      Starships were meant to fly, Hands up and touch the sky - Nicky Minaj
    23. Re:Java isn't really built for the future is it? by shutdown+-p+now · · Score: 1

      Is Java doomed to get stuck behind in the single processor world or will it actually pave the way forward by running its VM across multiple cores?

      The VM itselfs runs "across multiple cores" just fine - ultimately it JIT-compiles to native code for most performance-critical stuff, and that, obviously, will happily run on any core. The trick is writing Java code that is parallelizable.

      This, of course, isn't a Java-specific problem - you're dealing with the same in any conventional language, be it Java, C++ or Python. The current pragmatic approach to this seems to be providing high-level libraries operating with primitives such as "tasks" and their dependencies, which are then scheduled across multiple cores automatically. Two notable examples are Apple's GCD, and Microsoft's Parallel FX (PPL for native, and Parallel LINQ for managed).

      Now, not only is there a plan to add something similar to Java, but there is ongoing work on getting first-class functions (closures) into the language for the next major release, which is largely motivated by the requirements of such libraries (similar to how Apple added __block for GCD - those libraries become too unwieldy to use without this kind of thing).

    24. Re:Java isn't really built for the future is it? by careysub · · Score: 1

      I don't think generics are a 'disaster'. More like 'potential disaster if you don't watch your ass'.

      Thanks, that is close enough for me. Languages can only afford so many treacherous features.

      And to date, I still haven't seen a better way to do it. (Your suggestion, "typing containers and letting it go at that", makes no sense; there was no way to do that without adding generics to the language, or something that works like generics.)

      "Something like it" is right. Just much less ambitious and intrusive into the language. A minimally ambitious implementation.

      Anyway, it doesn't matter. There's no way in hell that they'll be removing a widely-used feature from future versions of the language. As long as we're coding in Java, we're stuck with generics.

      Actually there is a way it can be removed. A less ambitious subset that people actually use (container typing with directly related simplified support features is the poster child here) can be left and at most a compiler switch can be used for the more complex aspects if they are actually used.

      And you know the bit about type erasure as the implementation mechanism? You know, generics disappearing in the byte code to maintain backward compatibility? Well a down-scoped release of generics will still be backwardly compatible.

      --
      Starships were meant to fly, Hands up and touch the sky - Nicky Minaj
    25. Re:Java isn't really built for the future is it? by roman_mir · · Score: 1

      I don't disagree that there is room for improvement, but my applications are doing that exact thing: a work-flow + separate services, each running in its own JVM that either can be scheduled by the OS or bound to specific CPUs/Cores, which I do with GNU/Linux, it's not as much work as you think, I pass around serialized data objects between JVMs, that's the extend of the difficulties there and Java makes it easy to do.

      In fact the concept almost always ends up being very similar, just look at a real time OS like QNX with its so called 'transparent distributed processing', it's exactly the same thing. I had to implements things like that a few times around, my last contract was with BellTV in Toronto where I built a system I called iService :) which did the same thing in Java again, it's just a natural thing to do.

      1. A common framework to run any separate service.
      2. A message bus.
      3. A workflow (which I normally implement as a state machine that is serialized and passed between processors/services together with the data).

      Takes 2-3 days to set this up, then it's all 'plugin' environment, meaning you can plug in as many services on separate cores as you need and have hardware for. The good thing about it is that by extension of this idea it is the next natural step to use the message bus across multiple network nodes, so that work is now scaled across a network.

      That's how it can be done anytime.

    26. Re:Java isn't really built for the future is it? by shutdown+-p+now · · Score: 1

      Elegance? Closures? Now you have me scared. Really scared.

      Why, because you'll have to learn new things again, rather than cranking out code in the same old mid-90s style?

      Guess what, the industry we're in is one of the fastest development ones - every year, it's learn new stuff, or become irrelevant.

      And, as of now, Java is the only mainstream language that doesn't have closures. C++ has them (C++0x is still a draft, but both g++ and MSVC implemented C++0x lambdas in shipping compilers already, and lambdas are used in shipping code of some major products already - I can tell you because I wrote some for one of those myself). C# has had them for 5 years. Heck, VB - the much-derided Visual Basic! - has them for almost 3 years now!

      Time to catch up. That, or join the cohorts of COBOL programmers.

      Typing container classes was fine (and the only thing any working programmer I have talked to actually uses), but as soon as you venture beyond that it descends into a nearly incomprehensible API

      What, pray tell, is the API for generics? What does this even mean?

      If you mastered Langer's FAQ and could actually write code using generic wildcards no other programmer could understand and maintain your code. And I am doubtful that you could yourself, 6 months later.

      I haven't even read that FAQ, but I understand Java generics just fine, and know many other people who do. Guess what, wildcards are really just a rather straightforward representation of use-site covariance and contravariance; once you understand those two concepts, you understand wildcards. And they are very easy to understand.

      The fact that there are so many Java programmers who are unable (or unwilling) to learn those things just shows how many people are out there that really shouldn't be writing code in the first place. Being a programmer requires some aptitude for learning new things and concepts.

      Java generics seems to require at least a graduate level course in type theory to use (possibly an actual degree in the field).

      I don't have any formal high education, much less one in CS, so your argument goes down right there.

      But, anyway, are you seriously claiming that understanding type co/contravariance requires a "degree in the field"??

    27. Re:Java isn't really built for the future is it? by hibiki_r · · Score: 1

      Complex definitions require quire a bit of careful working, but 99.99% of the code that uses generics is trivially easy, and gets rid of the huge amounts of unnecessary typecasts. Remember that, in the end, Generics make no difference whatsoever at they bytecode level: they go away at compile time.

      If you don't want to use generics, then don't use them.

    28. Re:Java isn't really built for the future is it? by HiThere · · Score: 1

      Dataflow isn't workflow. I'm not certain, but I think you were confused by the similarity of names.

      Dataflow architectures basically allow each operation to proceed as soon as all the inputs it requires are ready. In programming one you don't place the order the execution of the steps, you specify which results are needed for which step, and let the compiler figure out how to place in order the steps.

      Well, that's oversimplified. In the one example I really worked with you drew connections between the output of one step and the input to another, and you clearly need a way to do something like that. OTOH, that one (Prograf) was running on a Mac LC3, i.e., a uniprocessor system. And it was never designed to handle multi-processor systems. But it clearly had the capability of such an extension.

      That said, I'll admit that I found it hard to think in dataflow terms. This is probably because it's rather different from normal sequential thought. But it was conceptually elegant, and I'm sure that one could LEARN to think that way. I'm not at all sure that one could learn to think in most parallel logics that I've encountered. (Just imagine trying to think like a neural net...despite the fact that you're using one to do your thinking.)

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
    29. Re:Java isn't really built for the future is it? by roman_mir · · Score: 1

      Where did I say dataflow? I said I implemented workflows as statemachines.

      States are discreet sets of data that can be defined as 'data being in a state' (a state like: 'order information is received completely' or 'current data is incomplete due to an error of some sort') and transitions are represented by the work that is done by a concrete service.

      So state A transitions to state B by running a service on this data, which service takes data in state A to state B is defined by the current state machine (lets say it's service F1), the workflow engine packs the state machine, the data, serializes it to the bus and one of the available F1 services picks this off the bus for processing.

      It's that simple.

      As far as functional languages go, I have done work in common lisp, ml and scheme, but that was course work too many years ago, IRL almost nobody uses them (outside of universities.)

    30. Re:Java isn't really built for the future is it? by sproketboy · · Score: 1

      OK find me another language/platform which has a universal binary (JAR) and a *guaranteed* number system on ALL platforms and I'll consider it. Java guarantees the sizes, the precision AND the *atomicity* of the number systems. The fact is there is nothing out there that can replace Java right now or in the foreseeable future.

    31. Re:Java isn't really built for the future is it? by HiThere · · Score: 1

      You were responding to me, so I thought you might be responding to one of the things I had said. (Otherwise I didn't see the relevance of your comments about workflow.)

      P.S.: Dataflow isn't the same concept as functional languages, either. And functional languages, and parts of language, aren't that rare. E.g., Scala is an essentially functional language implemented on the jvm. (And can call Java easily.)

      OTOH, I'll agree that some dataflow architectures could be implemented with or as functional languages. The concept is, I think, nearly orthogonal. (I'll admit that I could be wrong about that. I've only experience with one dataflow language. It wasn't functional, but that could be idiosyncratic. I could be being deceived by terminology, but I don't think so. Pure functional languages date back to the 1950's, and they seem to be a very different concept.)

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
    32. Re:Java isn't really built for the future is it? by Anonymous Coward · · Score: 0

      The trouble with generics is that to allow backwards compatibility they broke the implementation.

      And then, to add insult to injury, they broke backwards compatibility anyway! Java code that uses generics cannot be compiled with Sun's JDK into bytecode for any JVM earlier than 1.5, so there was really no excuse for not preserving the typing information.

    33. Re:Java isn't really built for the future is it? by Anonymous Coward · · Score: 0

      I would suggest looking at the enum class for a good example of how messy generics can get. As far as type erasure goes, I wouldn't expect that to be resolved in the next revision. Type erasure is necessary for Java to be backwards compatible, which is one of Java's biggest selling points. Breaking backwards compatibility would be dramatic change, perhaps the kind this article is referring to.

      Personally I don't care for generics in Java; they were poorly implemented. I avoid them except for simple collections, and even then I am leery of them.

       

    34. Re:Java isn't really built for the future is it? by dgriff · · Score: 3, Interesting

      Generics seem pretty straightforward to me, even the "? extends Whatever" syntax. Maybe you could give some concrete examples as to the problems with generics. The only problem right now is that type erasure makes arrays of generics impossible. Hopefully they'll fix that with the next revision.

      Here's an example of how complex it can get. Extract:

      The problem is that the entrySet() method is returning a
      "Set<Map.Entry<capture-of ? extends K, capture-of ? extends V>>",
      which is incompatible with the type "Set<Map.Entry<? extends K, ?
      extends V>>". It's easier to describe why if I drop the "extends K"
      and "extends V" part. So we have "Set<Map.Entry<?, ?>" and
      "Set<Map.Entry<capture-of ?, capture-of ?>>".

      The first one, "Set<Map.Entry<?, ?>>" is a set of Map.Entries of
      different types - ie it is a heterogeneous collection. It could
      contain a Map.Entry<Long, Date> and a Map.Entry<String, ResultSet>>
      and any other pair of types, all in the same set.

      On the other hand, "Set<Map.Entry<capture-of ?, capture-of ?>>" is a
      homogenous collection of the same (albeit unknown) pair of types. Eg
      it might be a Set<Map.Entry<Long, Date>>, so all of the entries in the
      set MUST be Map.Entry<Long, Date>.

    35. Re:Java isn't really built for the future is it? by bingoUV · · Score: 1

      I don't see a problem. Someone was not aware of the "capture-of" concept and it was explained to him. Simple concept, and explained well. I myself was a bit rusty on it, but got on with it quickly on reading this explanation.

      --
      Bingo Dictionary - Pragmatist, n. A myopic idealist.
    36. Re:Java isn't really built for the future is it? by dgriff · · Score: 1

      Well the person doing the explaining agreed that it was tricky, and tricky != simple. IMO language features should be simple enough that you don't get rusty and need to go look things up to refresh your memory.

    37. Re:Java isn't really built for the future is it? by yyxx · · Score: 1

      Parallel array is another topic on the agenda, which allows you to express in an almost declarative style operations on arrays,

      And what "arrays" are those gioing to operate on? After 15 years and despite lots of broken promises, Java still doesn't even have usable multidimensional arrays.

    38. Re:Java isn't really built for the future is it? by bingoUV · · Score: 1

      IMO language features should be simple enough

      They are not compulsory for everyone to use. Use the simple features if you are scared of the advanced ones. There is always BASIC, or LOGO. Advanced functionality will not be available then, but that is only to be expected.

      --
      Bingo Dictionary - Pragmatist, n. A myopic idealist.
  8. The next Cobol? by richman555 · · Score: 0, Flamebait

    Java, while widely used is on the down slide. There really hasn't been any new revolutionary additions to the language in about 7 years. In another 10 years, it will become like COBOL is to IBM.

    1. Re:The next Cobol? by arjan_t · · Score: 1

      Java, while widely used is on the down slide. There really hasn't been any new revolutionary additions to the language in about 7 years. In another 10 years, it will become like COBOL is to IBM.

      The only thing that has remained the same in about 7 years are the posts about "Java is dead", meanwhile Java is still the most widely used language and in those 7 years additions have been made to the language (generics, annotations, type safe enums, etc) and soon we'll have some extra goodies like closures and automatic resource management. Maybe those are not revolutionary, but enough IMHO to keep the language with the times.

      Meanwhile, there is a lot of innovation going on in the platform, especially with Java EE and how it uses annotations for things other languages might use keywords for (e.g. annotations to make methods transactional).

  9. Missing the point... by haydensdaddy · · Score: 2, Insightful

    In a rare fit, I actually read the TFA (I know, I don't know what I was thinking), and it leaves with the feeling that Paul is concentrating on the wrong argument...

    He appears to be arguing that third-party vendors control Java through the development of their frameworks and tools. While most modern-day development is relegated to gluing together frameworks instead of actual programming, I think this misses the point in the same vein as when people talk about JEE being Java.

    Java is a language upon which these frameworks and tools are built. For all of the good things Sun did for Java, they had a tendency to take the path of least resistance when it came to fixing existing features and adding new features to the language. If Oracle continues the trend, or does a worse job of it as many are predicting, third-party vendors will lost interest in developing these wonderful toys and will move on to other languages that are better supported.

    I for one, abhor the ownership of Java by Oracle. Sun had a tenuous grasp on it through its design-by-committee approach, and I have no reason to believe that Oracle will improve on that approach given its history. Java had some wonderful ideas behind it, but I for one have been transitioning my investments over to alternate languages that have caught up and, for the most part, surpassed Java in functionality.

    Well, that's my two cents and my cat agrees with me. So there.

    1. Re:Missing the point... by Anonymous Coward · · Score: 0

      but I for one have been transitioning my investments over to alternate languages that have caught up and, for the most part, surpassed Java in functionality.

      Such as?

  10. let Java languish by nurb432 · · Score: 4, Funny

    Oh wait, i thought this was a poll.. Nevermind.

    --
    ---- Booth was a patriot ----
  11. Re:Java is already dead for new development. by roman_mir · · Score: 3, Insightful

    You are insane.

    Not only there is constantly new Java code written for the back end, not only there are millions if not billions lines of code that are running existing services on the back end, but people are writing front end code in Java, at least for corporate environments.

    How do I know? I am writing some of it.

  12. Re:Java is already dead for new development. by roman_mir · · Score: 1

    Whatever AC.

    Java in a browser is a much better environment for desktop like applications that need to handle large amounts of data without constantly calling the server than a simple HTML design that requires the browser to render all of that data. HTML + browser is one of the slowest ways of doing it, Java beats that by orders of magnitude.

    I know, because I measured it. An HTML page with a table that has 20,000 lines with 8 columns takes just under a minute to render (depends on a machine, but it's a good estimate) and it only takes a second (or less) to render in a Java applet with the same table.

    Even that makes a huge difference, forget about the entire desktop like feel for the app, which is hundreds of times easier to do in a Java applet than in HTML, never-mind gwt or any other help you can get from any libraries, Java+Swing is still easier to write than anything in GWT, it takes much less code to get the same functionality as well.

  13. Java coders should be so lucky. by AnonymousClown · · Score: 4, Insightful

    Java, while widely used is on the down slide. There really hasn't been any new revolutionary additions to the language in about 7 years. In another 10 years, it will become like COBOL is to IBM.

    Don't knock COBOL.

    I know a couple of folks who are making a nice living as a COBOL programmer. And they're not that old. AND, when the majority of the IT market craps out, they always seem to have or can get a job. That's something not many programmers can claim.

    --
    RIP America

    July 4, 1776 - September 11, 2001

    1. Re:Java coders should be so lucky. by cfc-12 · · Score: 1

      I know a couple of folks who are making a nice living as a COBOL programmer.

      Glad to know pair programming works with COBOL as well.

  14. restraint of trade by SgtChaireBourne · · Score: 2, Informative

    Go away, lying revisionist troll.

    The lawsuit in 1997 against Bill's Microsoft by Sun was about contract violation. Microsoft had a contract to distribute java, not their own proprietary version of java, but bona fide java true to the published specifications. The allegations, proven in court, were that Microsoft aimed to harm to Java platform, violated the Sherman Act by illegally monopolizing and illegally maintaining aon the Intel-compatible PC OS market and the web browser market and the office productivity suite market. Microsoft was also illegal tying products, and illegally entering into exclusive dealing and exclusionary agreements (violation of Sec 1 of Sherman Act), and engaging in copyright infringement, and restraint of trade and unfair competition. It was also attempting to illegally start a monopoly in the server operating system market.

    Not only do you Microsoft toads ruin the economy, you make the net more expensive and create security problems. It'd be just fine if DHS started checking hard drives during entry or exit at the US borders and nuked any and all NTFS partitions they find. HFS, FFS, UFS, or EXT would be put on instead. Give a few months warning first and hand out Fedora CDs to those getting a warning. Then after the deadline, bam.

    --
    Beta is broken and the link to classic doesn't work. Stop wasting our time or there won't be anybody left here.
    1. Re:restraint of trade by Digital+Pizza · · Score: 2, Interesting

      While the Right Thing resulted from the lawsuit, it's funny how it hurt Sun and Java more than it hurt Microsoft, which was Microsoft's real goal anyway.

      The thing is, I remember around that time that Sun's CEO Scott McNealy was constantly ranting and raving about how the goal of Java was to take over the desktop and specifically "Kill Microsoft". Launching a frontal assault against Microsoft (especially at that time) was foolish, and look at what happened. If the good folks at Sun had kept their mouths shut, maybe they would have actually succeeded.

      You can applaud the result of the lawsuit, but so many comments on this article reflect a resulting public perception that is not exactly favorable to Sun and Java.

      --
      We apologize for the inconvenience.
    2. Re:restraint of trade by Bing+Tsher+E · · Score: 1

      Andreesen at Netscape was doing the same thing. He upfront said that his aim was to defeat Microsoft. They intended the Netscape browser/server platform to get a proprietary lock on the desktop and take over Microsoft's captive market.

      Waving a big red flag at the bull is never a good idea, particularly when the bull is as big, aggressive, and ruthless as Microsoft.

    3. Re:restraint of trade by Zeinfeld · · Score: 2, Informative
      Yes, and a really bad idea for Andresen to mouth off the way he did when at the time he was attempting to claim sole credit for the invention of the world Wide Web.

      It is a curious fact that the original NCSA Mosaic documentation did not mention CERN or 'World Wide Web' anywhere. That despite the fact that 60% of the actual code in Mosaic was libwww from CERN. I know those facts as a member of the CERN team whose work was plagiarized. Later Andressen commissioned a book titled 'Architects of the Web'. It purports to have a chapter on each of the architects of the Web. Only you won't find the names I would consider the real architects, Tim Berners-Lee is only mentioned twice, both to attack him (there is no chapter on Tim). Nothing on Dave Raggett, Dan Connoly, Ari Luotonen. There were a few chapters in the book that were deserved, but most were not.

      Yes, I know rather more about the origins of the Microsoft/Netscape feud than you might imagine. Lets say that when Marc said something stupid about Microsoft that there were many of us who made sure that it did not escape notice in Redmond.

      At the end of the day the Sun lawsuit was really about giving Scott McNeally an alibi for having run his company into the ground. Then Sun and Netscape managed to persuade the DoJ to turn the anti-trust case into a massive alibi for both of them. In the process causing the DoJ to drop a valid line of enquiry (the Caldera connection and the O/S tying issue) for a bogus one. If you look at the way Netscape managed to take down Spyglass, it was essentially identical to the claims they persuaded the DoJ to make against Microsoft. And at the time Spyglass was Netscape's only competition in the browser market.

      Sun was not brought down by anything that happened in Redmond. What killed Sun was the fact that the UNIX market moved to Linux rather than Solaris and Intel and AMD started to beat Sun in chip design.

      --
      Looking for an Information Security student project suggestion?
      Try http://dotcrimeManifesto.com/
  15. Microsoft vs. Java Trailer (+5 funny) by Anonymous Coward · · Score: 0
  16. Scala by Laz10 · · Score: 1

    The java language isn't that important to develop any further.
    It is the platform that matters and the platform will live on long after java the language goes into decline.

    Currently the successor to java looks to be Scala.
    http://www.scala-lang.org/

    Scala compiles to java byte code, so standard java libraries will work just fine.
    It is type safe (unlike ruby and groovy)
    It performs about the same as java code

    If you are a java developer, I will highly recommend getting "Programming Scala"

    1. Re:Scala by toriver · · Score: 1

      But Scala uses a functional paradigm, and thus represents a different mindset to the OO nature of Java, and even the syntactic mindset of the C family. But yes, it is another tool for writing code targeting the VM.

      An aside: How many .Net developers use F#, the functional programming equivalent there?

    2. Re:Scala by RPoet · · Score: 2, Informative

      Scala is multiparadigmal; you can use the functional features when you want, and ignore them and program Java-style when you want.

      --
      "Oppression and harassment is a small price to pay to live in the land of the free." -- Montgomery Burns.
    3. Re:Scala by shutdown+-p+now · · Score: 1

      But Scala uses a functional paradigm

      No, it's hybrid OO/FP - which has been all the rage lately - with OO emphasized over FP.

      For comparison, F# is also hybrid OO/FP, but the balance is more towards the FP side of things.

      An aside: How many .Net developers use F#, the functional programming equivalent there?

      Well, these days, I consider F# to be the default language for anything that has to do with lexing/parsing text or walking trees on .NET.

      Inside MS itself, it's used for some parts of the ad platform for Bing. Outside, it has some success in financial/banking.

      But, anyway, trying to compare the pairings of Java/Scala vs C#/F# is not particularly meaningful, because C# has considerably more FP and FP-inspired language features compared to Java (most notably, it actually has proper closures), so even where FP makes more sense, you can stick to C# longer than you could stick to Java without things becoming awfully inconvenient.

    4. Re:Scala by yyxx · · Score: 1

      It is type safe (unlike ruby and groovy)

      Ruby and Groovy are also type safe, they simply are dynamically typed.

      Static typing is not necessarily an advantage.

  17. Java may not be as important by Anonymous Coward · · Score: 0

    but who will release, in a timely fashion, the important Java client updates to patch holes in the existing code?

  18. Java cross-platform DOES work by Anonymous Coward · · Score: 3, Informative

    We have java swing code that runs on window, linux, and os-x. We use a custom look-and-feel so things are consistent. Ok, the one-button mouse is a pain.

    We java backend code that runs on intel (windows/linux), powerpc, and arm. I routinely deploy and test on linux-x86 and deploy to powerpc and arm targets with zero problems.

  19. Java Lives On by helix2301 · · Score: 0

    Oracle will not let Java die. It needs Java for a lot of its applications plus other company's need Java so stay alive. I was just at a customers just recently that runs Novell and the entire infrastructure is OES Linux and Free Suse. All most every desktop tool and web tool was Java based.

  20. Re:Java is already dead for new development. by haydensdaddy · · Score: 1

    I don't think that Paul Krill has realized yet that Java is absolutely dead for new development.

    ...for you. While I have moved on to other languages as well for personal and outsourced projects for many of the same reasons you state, I'll have to tell the Fortune 100 company I work for that the millions of dollars per year they pour into new Java based projects doesn't actually exist...

  21. Re:Java is already dead for new development. by EsbenMoseHansen · · Score: 2, Insightful

    By that argument, you might just as well write the entire thing in python/C++/ZoopedUpZuperLanguage++ and provide a download link. The *point* of webbased apps is that there is no download involved and that the application integrates well with the browser. Neither is very true for Java webapps. Besides, even the Java people tell me that applets are a deadend.

    --
    Religion is regarded by the common people as true, by the wise as false, and by rulers as useful.
  22. Hear, hear. by Cyberax · · Score: 1

    Yes, Java core language is stagnating. Even JDK7 has not much new features.

    Java does have a nice ecosystem of libraries, but by now we've explored about 100% of what can be done in libraries without changing the core language. But there are limits, and a lot of things are just not possible to do in libraries.

    For example, java.util.concurrent library is quite nice. But it's rather clumsy even with the planned closures support, any parallel algorithm is quickly drowned in the clutter of anonymous classes. In comparison, Parallel LINQ in .NET is much easier to use.

    Or take QueryDSL as another example - it allows to build nice typesafe queries, but it's not really feasible to use it to query simple collections because of huge runtime overhead. While LINQ works just fine.

    Reified generics in C# also make a lot of things MUCH nicer.

    1. Re:Hear, hear. by mswhippingboy · · Score: 1

      Yes, Java core language is stagnating. Even JDK7 has not much new features.

      I disagree. Java is evolving at a reasonably steady pace and while each subsequent release is not as radically different as its previous as in some newer languages, this is to be expected since the language is already fairly mature. Its usage however, is ever expanding.

      http://langpop.com/

      If you check out the link above, you can see that C# is considerably behind Java in popularity (its even behind old standbys like C, C++, PHP and Perl) which makes me wonder where the "java is dead" crowd are getting their information. Technologies like LINQ/PLINQ are great, but very proprietary in a world that doesn't have to be tied to a specific platform. Why tie yourself down to proprietary extensions when perfectly viable alternatives exist? If MS were to open-source .Net and/or LINQ, then maybe they would stand a chance of being generally accepted, and maybe even incorporated into later versions of open source language environments, but corporate IT departments more and more are beginning to realize they don't have to be held hostage to proprietary technologies (it's taken a long time, but I see it happening every day and I for one, welcome it).
      Almost every third party corporate application that I've seen implemented over the last 3-4 years has been based on Java, and most of them contain open-source libraries at their core. The richness of the available java libraries and open-source components makes developing applications from scratch unfeasible from a cost perspective. What better platform to develop in to take advantage of this vast array of pre-existing, pre-tested code than Java (or one of it's offspring such as Scala)?

      --
      Sometimes the light at the end of the tunnel is the headlight of an oncoming train.
    2. Re:Hear, hear. by Cyberax · · Score: 1

      "Its usage however, is ever expanding."

      Where? Java is pretty stable only in enterprise because of large volume of legacy code. All other usage areas are disappearing.

      langpop is rubbish. If you want to get real picture - try searching Monster.com or freelance sites. C# now dominates Java in nearly everything.

      The pace of Java development can hardly be described as 'steady'. It's more like 'spastic' - 5-7 years without any updates followed by stinky code drop from some obscure JSR group. Come on, Java6 is close to EOL while Java7 is not even close to release!

      Just remember the fail with type erasure in generics. Sun wanted to make backwards-compatible generics which mandated type erasure. But it turned out to be impossible, but they didn't have guts to do reified generics so we now have to live with this stinking pile of failure.

      "Technologies like LINQ/PLINQ are great, but very proprietary in a world that doesn't have to be tied to a specific platform. Why tie yourself down to proprietary extensions when perfectly viable alternatives exist? If MS were to open-source .Net and/or LINQ, then maybe they would stand a chance of being generally accepted"

      WTF? LINQ is open and is actually described in an ISO standard, it's a core language feature. And it's completely implemented by Mono, for example.

      "What better platform to develop in to take advantage of this vast array of pre-existing, pre-tested code than Java" .NET is better. Right now it has about as much of pre-existing software as Java.

      "(or one of it's offspring such as Scala)?"

      Scala is overcomplicated and perpetually in a state of flux. It's not possible to use it for large projects.

    3. Re:Hear, hear. by lehphyro · · Score: 1

      Where?

      Virtually, every single phone in the world... oh, and there is Android too.

    4. Re:Hear, hear. by Cyberax · · Score: 1

      "Virtually, every single phone in the world..."

      J2ME is dead.

      "oh, and there is Android too."

      Which is not Java(tm) and they also think about making Go language the first-class citizen.

    5. Re:Hear, hear. by mswhippingboy · · Score: 1

      Where? Java is pretty stable only in enterprise because of large volume of legacy code. All other usage areas are disappearing.

      Where? Everywhere. I don't know what enterprises you work in, but I've been in enterprise development for 35 years and I've never seen such a sea change in such a short time toward any particular platform. Java is in nearly every major enterprise application available on the market nowadays - EAI, ETL, CIS, HRM, ERM - you name it - the big vendors are either switching to or already using Java. Outside the enteprise, there's a burgeoning new development ecosystem building steam around Android - of which the development environment is core java with a customized (Delvek) JVM.

      langpop is rubbish. If you want to get real picture - try searching Monster.com or freelance sites. C# now dominates Java in nearly everything.

      Right. We should rely on your word rather than actual statistics.

      5-7 years without any updates

      What? Java 1.6.0 was released in 2006. We're now up to release 20. By my count that's better than one major release per quarter.

      LINQ is open

      On this point I stand corrected. You're correct that LINQ is now an open standard. Kudos to MS for getting this one right.

      Right now it has about as much of pre-existing software as Java.

      Sorry, not even close and most of what is available is closed source. Having to convince management to pony up money for third party .Net libraries all the time is tiring, which is why, if given the choice, I develop in java where I can get better quality and better tested libraries for no charge.

      Scala is overcomplicated

      Guess it depends on your cerebral capacity. BTW, you might be interested to know that apparently Scala 2.8 will support LINQ.

      --
      Sometimes the light at the end of the tunnel is the headlight of an oncoming train.
    6. Re:Hear, hear. by mswhippingboy · · Score: 1

      Which is not Java(tm)

      You're splitting hairs now. This is equivalent to saying Mono is not .Net, but in reality, they are slight variations of the same theme. True, the Delvik JVM is not officially the Java JVM, but it runs equivalent bytecode that has been directly translated to the dex format. The libraries are not the same as the Sun/Oracle reference libraries, but it is based on the Apache Harmony project which was an open source implementation of the Java libraries.

      --
      Sometimes the light at the end of the tunnel is the headlight of an oncoming train.
    7. Re:Hear, hear. by Cyberax · · Score: 1

      "Where? Everywhere. I don't know what enterprises you work in, but I've been in enterprise development for 35 years and I've never seen such a sea change..."

      Yeah, yeah. I know. And I'm absolutely not interested. The world of enterprise is a world of stale old tenchnologies, it's a world of hopeless legacy. Java gave it a brief time of excitement, but now it'll fall back on being soul-crushing boredom. Only now with Java instead of COBOL.

      While small and nimble companies will use good tools (.NET, Python, etc.) to leapfrog 'enterprisey' companies. I'm seeing this already.

      "Right. We should rely on your word rather than actual statistics."

      Which statistics? Number of Google searches? Don't make me laugh.

      "What? Java 1.6.0 was released in 2006. We're now up to release 20. By my count that's better than one major release per quarter."

      I'm speaking about major updates. Java 1.1 was released in 1997 with anonymous and inner class support. Java 5 was released in 2004 with generics (7 years). Java 7 is on track to be released in 2011 (7 years).

      "Sorry, not even close and most of what is available is closed source."

      Can you provide examples of Java projects absent in .NET?

      "Having to convince management to pony up money for third party .Net libraries all the time is tiring, which is why, if given the choice, I develop in java where I can get better quality and better tested libraries for no charge." .NET ecosphere is just different. A lot of projects are closed source, but are usually fairly cheap. Also, MS is quite friendly for small companies - it's possible to get everything required for development almost for free (using their BizSpark program).

      "Guess it depends on your cerebral capacity. BTW, you might be interested to know that apparently Scala 2.8 will support LINQ."

      Nope, it won't. I observe Scala development quite closely, and there's no infrastructure for LINQ. There's an interesting project http://ppl.stanford.edu/wiki/images/8/8f/Porting_LINQ_to_Scala.pdf but it is not open (I asked its author). There's also ScalaQL and other projects, but they are inadequate.

      Right now, I'm using QueryDSL as the most practical approach.

    8. Re:Hear, hear. by Cyberax · · Score: 1

      Actually, Mono is a certified CLR implementation...

      But I'm ready to concede the point about Android. It really is Java, but without most of Sun's UI cruft.

      However, Java was chosen there not because it's good, but because it's the only choice for real cross-platform development of reasonably fast code.

    9. Re:Hear, hear. by mswhippingboy · · Score: 1

      Yeah, yeah. I know. And I'm absolutely not interested. The world of enterprise is a world of stale old tenchnologies, it's a world of hopeless legacy. Java gave it a brief time of excitement, but now it'll fall back on being soul-crushing boredom. Only now with Java instead of COBOL.

      Wow, now you've really exposed your naivety and cluelessness. The world of enterprise is what drives all the significant developments. Small, nimble companies that are successful are inevitability consumed by "enterprisey" companies the moment they show potential for profit. Most are started with the dream of being successful enough to be bought out by a larger company. The technologies they possess are added to the portfolio of the consuming company so your argument doesn't hold water.
      You seem to want to trash enterprise class companies, while you shill for one of the biggest - MS.
      Have you ever worked in enterprise development? I don't find things like Advanced Metering Infrastructure (a project I'm currently working on) soul-crushing at all. It's quite cutting edge working with the latest in cell-phone technologies and energy delivery, monitoring and load management. Not to mention that the enterprise world has allowed me to put three kids through college and kept me employed when the small and nimble companies have been popping up and dying at incredible rates, taking with them the souls of the developers who really put their hearts and dreams on the line. No thanks. Been there, done that. To survive long term in software development one must stay current and be willing to change to what is in demand and the higher paying jobs are not C# nor java (nor python or anything else you might find on a freelance site). The higher paying jobs are the ones looking for broader skills in enterprise, web or mobile technologies - whether you know C# or Java or whatever is secondary and to really succeed, you need to know them all.

      --
      Sometimes the light at the end of the tunnel is the headlight of an oncoming train.
    10. Re:Hear, hear. by mswhippingboy · · Score: 1

      However, Java was chosen there not because it's good, but because it's the only choice for real cross-platform development of reasonably fast code.

      And because of the availability of thousands of skill Java developers.

      --
      Sometimes the light at the end of the tunnel is the headlight of an oncoming train.
    11. Re:Hear, hear. by Cyberax · · Score: 1

      "Wow, now you've really exposed your naivety and cluelessness. The world of enterprise is what drives all the significant developments."

      Actually, no. Enterprise world is where the money is, true. But significant developments rarely happen there, all recent major developments happened in the world of personal computing, mobile and distributed processing.

      "Most are started with the dream of being successful enough to be bought out by a larger company. The technologies they possess are added to the portfolio of the consuming company so your argument doesn't hold water."

      Yes, and that's how enterprise world is evolving.

      "You seem to want to trash enterprise class companies, while you shill for one of the biggest - MS.
      Have you ever worked in enterprise development?"

      My personal experiences are about as broad as it gets (from hardcore C++ to high-level enterprise software) my company (i.e. the company I own) writes software for enterprise clients. It pays well, sure. But it's a dead end.

      I also happen to know Java in extreme details (wrote my own JVM...) and hate Microsoft with passion and will touch .NET only under threat of starvation. But that doesn't mean I can't appreciate good technology in their software stack.

  23. Re:Java is already dead for new development. by SanityInAnarchy · · Score: 1

    Java in a browser is a much better environment for desktop like applications that need to handle large amounts of data without constantly calling the server than a simple HTML design that requires the browser to render all of that data.

    So what?

    An HTML page with a table that has 20,000 lines with 8 columns takes just under a minute to render (depends on a machine, but it's a good estimate) and it only takes a second (or less) to render in a Java applet with the same table.

    And I bet a Java applet which attempted to render 20,000 lines all at once would perform just as poorly. It really wouldn't take much JavaScript to replicate what Java is probably doing here -- render only the rows which are actually visible, and cache the rest in RAM.

    Your mention of "constantly calling the server" suggests that would be a bad thing, too. The browser's HTTP cache works with XHR, so I really don't get where that's an issue unless you need the data to be downloaded all at once.

    hundreds of times easier to do in a Java applet than in HTML, never-mind gwt or any other help you can get from any libraries, Java+Swing is still easier to write than anything in GWT

    And did you try anything other than GWT? Certainly, if you're going to claim this:

    it takes much less code to get the same functionality as well.

    Java, as a language, is verbose as hell, so I would guess that a Java library that outputs HTML is worse than a Java library that talks directly to a graphics system. But those aren't your only choices -- JavaScript is decent, and has its own libraries.

    You're also assuming that the functionality you get from Java is worth the functionality you lose. You're now requiring people to download a plugin -- no, not everyone has Java already, certainly not a recent version -- and your app is now rendered as an opaque blob, which means users can't script it with greasemonkey, it doesn't work with back/forward or bookmarking, it can't easily interact with other things on the page that want to behave like a webpage... Believe it or not, there are places where the Web beats a desktop app.

    You may be able to replicate that native web feel, but that's going to take a hell of a lot more code than it'll take me to develop a decent native web-based app.

    I'm not saying I agree with AC, but I really don't see much of a reason for doing browser-based Java -- though I do use it on the server side for other things.

    --
    Don't thank God, thank a doctor!
  24. Re:Java is already dead for new development. by SanityInAnarchy · · Score: 1

    If you're the same AC, that's a remarkable change of position -- you seemed to be claiming that Java wasn't seeing new development, and now you're claiming that it is, and it's just stupid.

    --
    Don't thank God, thank a doctor!
  25. Re:Java is already dead for new development. by mswhippingboy · · Score: 3, Insightful

    I have to agree with you here. I develop (for corporate environments) in a fairly large range of languages depending customer desires. The trend has been (for several years now) that more and more development is being done in Java, whether rewriting legacy systems or completely new development.
    The benefits that Java offers are more compelling than just about any alternatives. The arguments against its ability to "run anywhere" are old and most (if not all) are largely inconsequential to todays environments.
    A majority of development today is web-centric (intranet or internet) so issues with AWT or pathname incompatibility across systems are rarely encountered, and when they are, there are plenty of best-practices for dealing with them.
    The old line about Java performance being inferior is also largely a dead issue as it's be shown time and time again that the newer JIT enabled VMs allow byte code to perform on par with native C/C++.
    As far as being a dead language, I certainly don't see that happening any time soon. The language is under constant development and significant new features are being added with each major release, both to the platform (performance, concurrency, garbage collection, etc) as well as the language itself (modularization, closures,annotations, etc). The language is constantly evolving, but still, as much as possible, retaining backward compatibility.
    Even if the language itself is not able to keep up with advances in modern language design, there are spin-offs like Scala that can co-exist in the same JVM and are able to take advantage of the large java eco-system while providing a different programming paradigm.

    I gave up being an fan-boy for technologies many years ago when I got burned with OS/2, and have since decided to embrace whatever languages and technologies are in demand, be it MS tools (VB and C#), Apple (Objective-c) or non-proprietary (Perl, PHP, Java, etc.).
    Folks that are quick to declare Java dead are obviously naive and don't have a clue about the way the IT world works. They can line up with the folks that declared mainframes and COBOL dead twenty years ago, while (according to a recent Computerworld article) more than 200 million lines of COBOL are still in use and a COBOL gig is still considered the safest gig in IT today.

    --
    Sometimes the light at the end of the tunnel is the headlight of an oncoming train.
  26. Paying for Oracle Java? by esarjeant · · Score: 3, Insightful

    What about the prospect of having to pay for Oracle Java? The client would continue to be free (JRE) but if you want to compile code it will cost you. How would Java fair if there was a $100 developers license?

    Certainly the open source Java compilers would gain a significant foothold, but with Oracle steering the JCP it seems likely they would eventually corner the market...

    --

    Eric Sarjeant
    eric[@]sarjeant.com

    1. Re:Paying for Oracle Java? by RPoet · · Score: 1

      How could you "corner the market" like that? Java has an incredibly strong free software culture around it; making the compiler proprietary (it's free software today) and then even charging for it, would be Oracle Java's death knell and a free fork would take over.

      --
      "Oppression and harassment is a small price to pay to live in the land of the free." -- Montgomery Burns.
    2. Re:Paying for Oracle Java? by StormReaver · · Score: 1

      Certainly the open source Java compilers would gain a significant foothold, but with Oracle steering the JCP it seems likely they would eventually corner the market...

      Don't lose any sleep worrying about that, as it has a near-zero chance of being reality. Oracle certainly could try such a move (it's in the corporate culture), but it would have no teeth. When SUN open-sourced Java, the former assumed the role of steward, and surrendered the role of dictator. There is no way that Oracle can now force people to bow down to its will with Java.

      There would be short-term angst for developers, and short term profits for Oracle, but there would be an inevitable fork of not only the code, but of the name. Java (or whatever new name was given to the forked language) would continue under new management, and life would go on. The whole issue would fade away in a reasonably short period of time, and would become just minor background noise in the long run.

      Given that, Oracle is not run by complete idiots (much as it may seem from time to time). Doing what you propose would be product suicide.

    3. Re:Paying for Oracle Java? by grasshoppa · · Score: 1

      I would see something like that working like RHEL vs CENTOS.

      Some companies would pay the fee ( for extended support? ), while others would use the free alternative.

      And let's face it, there would be a free alternative. Within minutes of the announcement, a million forks would be created from the last release.

      --
      Mod me down with all of your hatred and your journey towards the dark side will be complete!
    4. Re:Paying for Oracle Java? by Anonymous Coward · · Score: 0

      I think you're taking IBM and the Eclipse Foundation too lightly. It's perfectly possible that javac is already a minority use compiler, and IBM would almost certainly provide the necessary resources to keep ecj up to date so as not to lose Websphere's market.

    5. Re:Paying for Oracle Java? by lehphyro · · Score: 1

      Don't forget the eclipse JDT compiler. It's even better than the oracle one in many ways.

    6. Re:Paying for Oracle Java? by shutdown+-p+now · · Score: 1

      Certainly the open source Java compilers would gain a significant foothold, but with Oracle steering the JCP it seems likely they would eventually corner the market...

      If that ever happens, I'd expect IBM and Google (and other interested parties) to set up their own process for Java design and development, and simply ignore everything that comes out of Oracle. Given that free development tools and servers are a big part of Java's attractiveness today, I'd also expect most developers to follow suit.

      Of course, Oracle understands that well, so they won't do such a silly thing. I'm sure they'd be happy to charge you for Java, but they know that practically no-one will pay.

    7. Re:Paying for Oracle Java? by Anonymous Coward · · Score: 0

      Well, you could always go with IBM Java instead...

    8. Re:Paying for Oracle Java? by esarjeant · · Score: 1

      Give Sun's Java a different name and abandon it. Start promoting the new Oracle Java (closed source) as Java(TM), maybe using the pre-existing Oracle Java together with JRocket as the basis for a new Java engine. Charge a modest licensing fee for the developer engine and then wait for corporate clients to start lining up.

      Honestly, I can't think of any large production Java shop that would just "wing it" with the open source Java "clone" -- they would want the commercially supported version.

      With that said, there is one sticking point -- the JCP. Oracle is already in talks to "streamline" the JCP methodologies, they would have to play this card very carefully if they really wanted a change like this to stick. Otherwise, you're right - a free fork would take over and the JCP would adopt that Java sans Oracle but with a different name...

      --

      Eric Sarjeant
      eric[@]sarjeant.com

  27. Re:Java is already dead for new development. by SanityInAnarchy · · Score: 1

    Yeah, I know, we've seen Scala and Clojure, but they're rather shitty and impractical for large-scale real-world software development.

    Be specific. How are they impractical? In particular:

    Clojure is just a reimplementation of one of the oldest programming languages around, Lisp.

    And what's impractical about Lisp, particularly a Lisp with STM?

    It's also funny that you mention this:

    Sun's lack of vision over the past decade has rendered Java far behind languages like C#, Python, Ruby, and even Perl.

    Here's the thing: For awhile, JRuby was faster than MRI, the main interpreter. YARV, the new MRI, is faster still, but JRuby seems to be catching up. And JRuby can do real threads, without a GIL, something MRI can't or won't. It runs all sorts of stuff Ruby people expect, including Rails. There are even a few examples of Java libraries which had Ruby equivalents, but the Java versions are the only ones still maintained -- for example, DataMapper supports Oracle just fine, but the only current low-level Oracle adapter that's supported is the JDBC one.

    Then there are the crazier things, like running Rails on Google App Engine. I don't necessarily like the JVM, but it does mean I can run any language I like so long as it fits into that Java container.

    I'm not sure how close Jython is to that kind of status, but I've been forced to develop stuff which runs on Oracle's WebLogic, and, surprisingly, the WebLogic Scripting Tool is written in Python, and runs on Jython.

    It's also funny you mention Perl. What's the #1 reason for using Perl? CPAN. There's tons of Java libraries out there, though not as nicely organized as CPAN last I checked. If I were to take one such library -- say, a nice, well-behaved, self-contained jar -- I could use it trivially from my Ruby app. The Perl concept of grabbing existing CPAN libraries, maybe some only thin wrappers around C libraries, and binding them together with a thin bit of scripting glue to make something cool, is definitely alive and well here -- except you don't have to write any glue, it's trivial to just use the Java APIs.

    So, I hate Java as a language. There are languages I merely dislike, or prefer not to use, like Python or Erlang, but I actually hate Java. But the JVM looks like it's turning into something cool.

    The JVM is an absolute mess compared to .NET, of all things.

    Except that .NET really isn't even to the point the JVM is for "write once, run anywhere." The main implementation is Microsoft's, and Mono is always two or three steps behind. You can either write stuff using Microsoft's APIs and hope Mono keeps up -- which would be like declaring your Windows app is "cross-platform" because it runs under Wine -- or you can stick to purely Mono stuff, which means you'll have to distribute native libraries (like GTK) with your app.

    I think I've given up looking for the perfect VM. I'm sure the JVM isn't it yet, and I would guess that some other VM will take over. After all, the JVM physically can't (and may never be able to, may never want to) do some of the tricks the Erlang VM does.

    But you're writing Scala and Clojure off as "shitty" without giving a real reason why, and you're either claiming people aren't using Java (or the JVM) for new development, or saying they're stupid for doing so. Where you're not factually wrong, you're just spouting opinions without backing them up.

    --
    Don't thank God, thank a doctor!
  28. Re:Java is already dead for new development. by Anonymous Coward · · Score: 0

    no, you are stupid!

  29. Android? by Anonymous Coward · · Score: 0

    Dalvik, and the language used are VERY similar to Java and the JVM. The libraries may be different, but Android appears to be a major platform. If nothing else, Android will be around, and can probably be coded into a very similar to Java platform.

  30. Re:Java is already dead for new development. by zzyzyx · · Score: 1

    Yeah, I know, we've seen Scala and Clojure, but they're rather shitty and impractical for large-scale real-world software development.

    Ever heard of Twitter? Their back-end is written in Scala. How's that for a large-scale real-world application?

  31. Re:Java is already dead for new development. by roman_mir · · Score: 2, Insightful

    So what?

    - for real, you are asking me 'so what' and that's your argument? My response is simple: I am recreating an application in a browser that my users have used in the past and that is now no longer supported that used to be a stand alone applications. Some of my users think that their 'computer is broken' when somebody re-sizes a window on their desktop, those are not the kind of people who will want to switch paradigms from a desktop application to a web based one that is purely running as HTML/Javascript, so those people need to have the same experience they are used to from a desktop app, however the new app will not be installed locally, it is now a web app for reasons varying from cost of maintenance to security to ease of deployment and availability.

    This single argument that you are giving: 'so what' completely dismisses actual reality.

    And I bet a Java applet which attempted to render 20,000 lines all at once would perform just as poorly. It really wouldn't take much JavaScript to replicate what Java is probably doing here -- render only the rows which are actually visible, and cache the rest in RAM.

    - and you would be wrong and it shows your ignorance on the issue. Rendering done by the Java applet is completely different from what a browser does. Browser needs to parse HTML out, it needs to create some form of a document (DOM) it needs to prepare for quirks, it needs to decide how to display this and then render it and THEN it also changes what it renders on the fly re-rendering it with styles etc.

    Java applet has none of those issues, it does not need to parse out any documents, there are no CSSs, no javascripts, it's a layout with a table with data that needs to translation and multiple rendering passes, so as a result it responds immediately. 1 second after I load the 20,000 rows into it I can scroll ALL THE WAY TO THE BOTTOM. At this point a browser rendered maybe 300-400 rows only that can be scrolled through and as you are scrolling you are making it work slower, it will modify the page and re-render what was done already.

    Your mention of "constantly calling the server" suggests that would be a bad thing, too. The browser's HTTP cache works with XHR, so I really don't get where that's an issue unless you need the data to be downloaded all at once. - precisely, I do need it to be downloaded all at once so that user can see all of it in a single table by immediate scrolling.

    And did you try anything other than GWT? Certainly, if you're going to claim this:

    - about 2 months worth of all kinds of things, from plain HTML, to GWT with paginating, incubators, Bulk Renderers, Javascripts, CSS all sorts of things. Absolutely NOTHING beats an applet.

    Java, as a language, is verbose as hell

    - I can see your bias from this.

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

    - for a compiled language it is not that much more verbose than C or C++, in fact less so depending on what you are doing.

    so I would guess that a Java library that outputs HTML is worse than a Java library

    - you have no idea what you are talking about. GWT is not a library. It is a full environment that allows writing CSS/XML (for layouts and configurations) + Java instead of using javascript, a compiler that does NOT include all of the features in Java or in GWT libraries, it creates the most dense code as far as javascripts go, but to your point, if GWT was written in C or C++ or PHP or whatever it still would have been as bad in terms of amount of code as GWT is with Java right now, not because of Java but because of what GWT is doing. GWT architecture requires much more code to be written that will have to be translated into Javascript/HTML

  32. What's the weather like on planet mars? by mswhippingboy · · Score: 2, Insightful

    Really? I don't know what planet you're on, but here on planet earth, much of the real work is being done in Java (by a very wide margin). (See http://www.langpop.com/ ).
    Haskell and Erlang are barely a blip on the radar. I like and use Python regularly and it has it positives, but I have a hard time recommending it to my corporate customers (for various reasons having to do with availability of trained developers, performance and or broad industry support). By and large most work I see getting done is being done in Java or .Net languages.
    I can see why you posted as AC since clearly this was intended as flamebait.

    --
    Sometimes the light at the end of the tunnel is the headlight of an oncoming train.
  33. Re:Java is already dead for new development. by roman_mir · · Score: 1

    By that argument, you might just as well write the entire thing in python/C++/ZoopedUpZuperLanguage++ and provide a download link.

    - sure, but JNLP makes the entire experience into a click and done, and you have an applet that looks like a desktop application running in the browser, it immediately is installed and connects to the server securely. It can be ran outside of the browser, but that fact is irrelevant, the applet is a complex application but it is still part of the business portal so it is a web app.

    The *point* of webbased apps is that there is no download involved

    - that is a very narrow minded view of what a web application is. Also once it is installed one time, it is cached and any new invocation is immediate. Besides, in corporate environments this is not an issue - a user will wait the extra 10 seconds, it's his job.

    and that the application integrates well with the browser.

    - to an applet the browser is just a delivery mechanism, but it can operate with the DOM and scripts on the page/windows anyway if that is a requirement, that's not a problem.

    Neither is very true for Java webapps.

    - actually neither of it is an issue. Applets download slower if they are huge, once loaded they are cached, they provide desktop-like experience, they are much faster at rendering any data, something browser + html - dom - css - javascript cannot boast. Desktop-like applications are often easier to use than web-apps actually, depends on the task.

    Besides, even the Java people tell me that applets are a deadend.

    - that's just not an argument. Some people would tell you anything until they themselves get on a project that requires that functionality. It's just not true, that's all I can say about it.

  34. Re:Java is already dead for new development. by Simmeh · · Score: 1

    To be fair I've only visited that site twice and both times I saw a fail whale =(

  35. Re:Java is already dead for new development. by Z00L00K · · Score: 1

    However, we're seeing absolutely no innovation coming out of the Java community. Sun's lack of vision over the past decade has rendered Java far behind languages like C#, Python, Ruby, and even Perl. The JVM is an absolute mess compared to .NET, of all things.

    And we all know that .NET are the solution to everything? Right?

    --
    If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
  36. Nobody owns java and nobody can kill it by Anonymous Coward · · Score: 0

    Nobody is owning java. Maybe oracle owns the java trademark. Java is owned/supported by millions and millions of java developers and supporters worldwide. If anybody thinks of killing or undermining is just making fool of themselves.

  37. Re:Java is already dead for new development. by EsbenMoseHansen · · Score: 1

    Well, substitute your "java applet" with "normal fat application", and you will get all the same advantages, except the fantasy about "1 click and it works" :) Sorry, 1 click will not even get you past the "please download the appropriate plugin" screen. Then the start is horrible slow --- I know, since I use one applet from my bank. We are talking 20-30 seconds, and the applet is very, very small (and probably cached, as you say). That is just not acceptable for a modern web application.

    Personally, I prefer fat apps. Dependable, quickly developed and the open source nature makes them less of a security issue. Such an app can then use a (restful?) web service to get all the advantages of being in a browser. The only price I get is that I have to install it. Last I checked I was not lacking for HD space.

    --
    Religion is regarded by the common people as true, by the wise as false, and by rulers as useful.
  38. Java's future not in the hands of any one company by SuperKendall · · Score: 1

    Java was never in the hands of any one company, not even Sun- because Java (both language and frameworks) is controlled and evolved using the JCP (Java Community Process).

    There are a variety of companies on the various panels so any one company cannot hijack (or kill) the language or platform.

    That was always part of the strength of Java, instead of going through a more hidebound standards body they created one specifically for Java, run by the people of the Java community.

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
  39. Re:Java is already dead for new development. by roman_mir · · Score: 1

    Do you understand what it means to work in a corporation with distributed clients? It means that every update to a fat app that needs to be pushed through is a new installation. This is just not the case with web applets. An update is transparent to the user and is immediate across all clients from administration perspective.

    I think you don't understand the use case.

  40. Re:Java is already dead for new development. by owlstead · · Score: 1

    Many of these new languages have very strong features, it's just not always the features that corporate environments want. If you want a well structured, understandable and *maintainable* language, Java is still a long way ahead on all those new languages. Even worse, most of all those new languages are worse.

    I'm also aching for a new language. A language that is even better supported by IDE's (refactoring, background compiling, static code checking and such). A language that has a better module system than Java. A language that takes all these things learned by Java and other OO languages and removes the awkwardness. I'm just not sure that functional languages provide these things.

    There are many languages that are easier to write than Java. There are few that are more easily read and maintained. Guess what a smart enterprise is waiting for?

  41. Re:Java is already dead for new development. by EsbenMoseHansen · · Score: 1

    Do you understand what it means to work in a corporation with distributed clients? It means that every update to a fat app that needs to be pushed through is a new installation. This is just not the case with web applets. An update is transparent to the user and is immediate across all clients from administration perspective.

    I think you don't understand the use case.

    Oh, point taken. My company is linux through and through, so we just update the repository and all apps are upgraded automatically. Naively, I thought windows could do the same. Even so, that usecase could be handled more generally by simply using self-updating apps, like e.g. online games do, without being restricted to Java.

    --
    Religion is regarded by the common people as true, by the wise as false, and by rulers as useful.
  42. The future of Java by steveha · · Score: 1

    I read TFA and I didn't see anything about "Java's Backup Plan". I'm not sure anyone really has a plan per se.

    But I will say that Java has enough momentum now that if Oracle really does a poor job of managing it, Java can and will be forked.

    The history of XFree86 shows that when the leadership of a project stop leading effectively, the community can and will fork the project and abandon the old leadership.

    In the case of XFree86, it was Keith Packard's X.org fork that made the original irrelevant. In the case of Java, I predict it would likely be Google that would lead the forking effort.

    Google likes Java and runs much of their business on it. When you do a Google search or use Google maps, you are using server-side Java code. When you run an app on an Android phone, you are running Java code.

    You might have heard that the VM in Android is called Dalvik. When Google made their plans for Java on Android, they made their own VM which is Java-compatible (in features, although not bytecode-compatible). They also provided a tool that can take a compiled Java program and swap the bytecodes around to make a Dalvik program. In this way, Google leveraged the development tools available for Java, while avoiding making any deals with Sun. Google paid nothing, promised nothing, and didn't even need to ask permission.

    Of course Dalvik was originally based on Apache Harmony, a free software project to make a Java VM. The Apache project felt that Java was insufficiently free, and you could call Harmony a fork. So far it is a fork intended to be feature-compatible, and nobody is talking about adding new features to Harmony that Java doesn't have. Yet.

    With James Gosling gone from Oracle, it may be already too late for Oracle to continue leading the direction of Java. Or it may not be quite too late. But if Oracle does anything that would displease the Java community in general or Google in particular, watch out.

    steveha

    --
    lf(1): it's like ls(1) but sorts filenames by extension, tersely
  43. Re:Java is already dead for new development. by marcello_dl · · Score: 1

    > However, we're seeing absolutely no innovation coming out of the Java community

    Funny, I have orientdb open in the other tab.

    --
    ---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
  44. Re:Java is already dead for new development. by roman_mir · · Score: 1

    I still didn't explain it right. It's not the same company, it's not the same environment, the users are across companies, we don't control their environments at all. But they are using the same application and that application is delivered over the web and it is a Java applet. I don't really know all of the possible client configurations, but they all have the necessary components, which are: a browser and a JVM plugin for the browser. Some our clients are definitely using GNU/Linux as their OS, some are definitely Windows something, there are even a few Macs AFAIK.

  45. Re:Java is already dead for new development. by Anonymous Coward · · Score: 0

    Most of the new Java code written is business software for banks, corporations etc... ~70% of the Java development as a whole is bug fixing and extending existing Java applications. Java is far, far, far behind in web development - Ruby On Rails, ASP.NET, PHP are pretty 4/5 of the market. Java is even loosing in shitty internal corporate apps. The only places were Java is winning are: - mobile space - smart phones - Android, most of mobile devices have some sort of Java on them - where portability is needed - but I have rarely seen a GUI app in Java. My 2 cents.

  46. Re:Java is already dead for new development. by roman_mir · · Score: 1

    Some see them more than others. I have developed a few over the past 10 years, one was a video-feed management application, built for Christie Digital through Alt Software that is used to monitor different video feeds and display them on a large video-wall (a stack of 70" rear-projection TVs) or with just projectors. Another applet written for the same company was a remote video-wall controlling piece, it was used as a remote control with VNC like capabilities to rearrange what is on the video-walls.

    For an electrical power distributor in Ontario (Ontario Hydro) I created a few applets that were used to visualize state machines (their development was based on state machines with states stored in databases but they didn't have anything to visualize and visually modify the states.) Another piece for the same company was tester software.

    Earlier I built something for International Financial Data Services, a proof of concept that they could move to Java + Oracle off of their Progress + 4GL language platform.

    Even earlier an online merchandise catalog with upload to the server capabilities.

    A few more I can't remember anymore, but currently I am working on a piece that is a desktop like replacement for a POS management app that they have for a desktop app they are running right now.

    Things are happening, just applets are definitely less common than simple HTML + CSS + Javascript and there is a good reason for that! Not ALL web applications need to be desktop-like. But the point is that for those that do need to be that way Applets are indispensable.

  47. Re:Java is already dead for new development. by swilver · · Score: 1

    Given the feature set of Twitter, I'm gonna assume it won't be bigger than some of the projects I wrote alone in my spare time.

  48. Re:Java is already dead for new development. by Anonymous Coward · · Score: 0

    to html+javascript addicted: please explain how to interact with the computer clipboard using proper mimetypes so that copypaste works trought different clients.

      - signed, an anonymous coward java applet developer.

    p.s. html scan all the table because it needs to computate column size based on the table content (stupid design decision), java has (could have, should I say) the column width defined beforehand.

  49. Re:Java is already dead for new development. by gparent · · Score: 1

    His point is that you still have to perform apt-get upgrade eventually. Or your admin does. Or a cronjob does. Something does. On the web app site, users load the page and they get the updated version. They don't even have a choice of going back to the previous version. There's no management of upgrades because there are no upgrades. Everything is just accessed from a central location with a web app.

  50. Re:Java is already dead for new development. by T-Ranger · · Score: 1

    But the reality is that with DEBs and a repository, RPMs, and a repository, or MSIs and a SMS or Zenworks server, things Just Work(TM).

    With Java, and "Java Web Start", any regular person runs such JWS programs so infrequently, that something working the last time is little guarantee that it will work this time. They upgrade their browsers between sessions, and break Java. Upgrade Firefox from 3.0.17 to 3.5.0 and *boom* everything gets faster, except Java applets, which break. For that matter, upgrade from 3.5.1 to 3.5.2, and things break. Go to java.sun.com and spend an hour finding the right JVM, JRE, JSE, JEE, JWTF, and click through licenses 3-4 times per, and you might get the right thing to make Java work again. Or give up trying.

    Java - Sun, Oracle, whatever - has shot themselves in the foot here, I grant. Their asinine redistribution policy's all but forbidding anyone else solving this really trivial problem for them. The Java technology (in the billion senses of that word) is passable.

    The Java politics is so mindbogglingly stupid that it managed to drag down a pretty good hardware company to scraps a software company bought up for pennies on the dollar.

    Personally, I deal with a bunch of things that run Java. The server stuff isn't that bad, it does generally Just Work (though, I'll point out that Atlassian generally encourages people to run their "bundled" apps, rather then trying to add a .war to an extant Tomcat install.... .WARs solve only self-imposed problems, but don't even bring one back to the normal of 1993, let alone making a sysadmins job easier then everything else in 2010). But the applet which was built inhouse, and the Cisco ASA tool just about never work when I try to run them after an arbitrary amount of time.

    I'll grant that JWS stuff works better then getting the unbathed masses to install a fat app. Is that a really high bar to get over? Has no one at Sun looked at management tools in the last 20 years?

    Comparing JWS to DEBs, RPMs, or MSIs with a reasonable and quite doable management infrastructure, Java isn't playing the same sport, let alone being in the same league.

  51. Re:Java is already dead for new development. by gparent · · Score: 1

    But the reality is that with DEBs and a repository, RPMs, and a repository, or MSIs and a SMS or Zenworks server, things Just Work(TM).

    They don't at all. Your admin may update the app faster than the other company's admin. MSIs don't make things happen the same everywhere, neither do repos. The action of updating isn't guaranteed to happen *everywhere at once* just because you really really want it to.

  52. Re:Java is already dead for new development. by Anonymous Coward · · Score: 0

    it's be shown time and time again that the newer JIT enabled VMs allow byte code to perform on par with native C/C++.

    No. It's been asserted time and time again, to the point that many people believe it must have been shown, or why would everyone be asserting it?

    The fact of the matter is that JITs do not, in practice, make the JVM as fast as C/C++. The tests that have actually been performed show that it can reach that level in artificial microbenchmarks, but in real-world applications it rarely gets close, and it requires much more memory in the process.

    It is also true that this is completely irrelevant, because it is fast enough for pretty much everything other than supercomputing and action games, and memory is cheap.

    significant new features are being added with each major release [...] (closures [...] etc).

    Hey, welcome to 2010, traveller! Do you have flying cars in the future?

  53. IBM would take it over by Ilgaz · · Score: 2, Interesting

    I keep wondering why people forget about Big Blue these days. Java and Linux support are the keys to their offerings and both are said to save mainframe/big server business of them.

    Eclipse is Java too. A lot of IBM applications, even client side stuff relies to Java.

    Lets not forget Google Android which is a huge success is enhanced J2ME/Java, billion cell phones have J2ME built in, the "winner" high definition format, Blu-Ray has J2ME/Java.

    Sorry to say the idea of Oracle wasting Java is really stupid to begin with. Perhaps Java will focus on the thing it does best is a better theory, I mean huge servers, databases, J2EE?

  54. Dead J2ME has Opera Mini by Ilgaz · · Score: 1

    If you ask the J2ME developers and game vendors, J2ME is doing pretty fine on billon devices.

    Seen the numbers released by Opera Asa every month? Now add "Gameloft", "EA Games" to it. That is your "dead" language.

    It will eventually merge with "real" Java and that time, it will be "dead".

  55. Perhaps it is the reason for Google by Ilgaz · · Score: 1

    I always wondered why didn't Google enhance the J2ME language to become undisputed app king on billion devices instead of going with their own unbranded J2ME.

    Now reading such posts from supposed to be clever "developers", I wonder if Google wnt with their own "Dalvik" Java just to convince these idiots that it is not Java they will be developing for?

    It is just like some Mono developers illusion that they aren't actually coding for Microsoft .NET framework.

    1. Re:Perhaps it is the reason for Google by mswhippingboy · · Score: 1

      First, J2ME isn't open-source (or at least it wasn't at the time Android was initially developed - it may be now) so Google would have had to license it. Second, while the Delvik JVM will run java bytecode that has been (automatically) converted to .dex file format, it is very different from a standard JVM implementation and specifically designed to run on devices with very little memory (and no page file) and slow (relatively) CPU, with battery conservation another major constraint. The Delvik JVM is register based rather than stack based and pays much more attention to memory usage than is required in a desktop/server JVM. Its designed to run in as little as 64M Ram with a CPU as slow 500Mhz.
      Of course, the internals of the Delvik JVM are largely transparent to the Java developer but it helps to understand, as a developer, that the devices the software will run on are equivalent to a desktop computer of about 7 years ago.

      --
      Sometimes the light at the end of the tunnel is the headlight of an oncoming train.
  56. Re:Java is already dead for new development. by T-Ranger · · Score: 1

    Lets grant your point then. Lets assume that the general problem of updating software hasn't been solved by your local admin, your OS or the universe in general. Lets assume that updating software is the responsibility of the software VM and the various miscellaneous politics and technology that surrounds it.

    Java imposes a set of problems *at least as bad* as just straight upgrading software.

    I'm faced with the problem of updating firewall rules on an ASA. So I fire up ASDM to do so. And it fails, because its been a couple of weeks since I did it last, and Java doesn't want to work any more. So I try to upgrade Java, and am faced with the decision of installing the Yahoo toolbar in my browser or not. Really? Are you fucking kidding me?

    Personally, I don't really care if the ASA OS is written in 6502 ASM, or in VB on an embedded 386. And I especially don't care if the fancy management tool is written in GWT (which actually does "just work", unlike JWS stuff), Java, or for that matter, even Flash. In this example, what I *want* to do is write a firewall rule. In dealing with this minor problem, I'm forced to deal with the insanity that is desktop Java - which is neither provided by SMS or a zypper repository, due to Suns apparent desire to annoy me.

    Unsatisfied with just making me think of Java and Sun when I just click on some link somewhere and upgrade, I'm force to go through a barrage of links and licenses before I can download the software. On Linux, I'm forced to agree to the license *again* before I'm allowed to create a symlink by-hand to get it to work. Under Windows I'm forced to uncheck someones desire to force the Yahoo toolbar on me.

    Again: Are you fucking kidding me? Faaaaahk! I don't have to jump through this many hoops to get MSDN software. Or trials from Novell, let alone shareware or OSS stuff.

    Has no one at Sun ever tried installing software from anywhere? Is installing Java easier then it was in 1994? Sure. What is the hardest desktop software to install in 2010? Java.

    Is building a JWS cheaper then paying for an Installshield license? I suppose. Is building a JWS easier then writing a .spec? It couldn't be harder, that I know. But I'm not a developer. I have 0 desire to have Java on any of my systems; it is a means to an end. Why must I think about it? Why is a developer tool trying to install a shitty search toolbar on my user centric web browser?

    Java may (or may not, I'm not really willing to grant that point) make life easier for developers. But Java makes everyone else life harder. And does so with pleasure.

    Of course, this is entirely beside the larger issue of "Java Web Start" that it not running in a browser (and this includes Flash), by definition, makes it not web based.

  57. The problem is you can't... by warrax_666 · · Score: 1

    The major problem with checked exceptions is that the variance rules for the "throws" clause are at odds with how subclassing and method overrides work (for sort-of-good reasons, mind.).

    When you override a method you typically expand the set of things it can do, and thereby also the set of things that can go wrong. Unfortunately you can only restrict (or just plainly keep) the set of declared exceptions. There are some ways around this using generic exception types, but I've yet to see a practical and moderately satisfying solution. (More advanced type systems/languages have things like "effect types" to handle these things in safer ways, but I don't see any of those languages becoming mainstream any time soon, unfortunately.)

    --
    HAND.
  58. Re:Java is already dead for new development. by gparent · · Score: 1

    I'm faced with the problem of updating firewall rules on an ASA. So I fire up ASDM to do so. And it fails, because its been a couple of weeks since I did it last,

    Honestly, I've heard horror stories about SDM. It's the only Java app that I've heard about that behaves like this (Don't take me wrong, I understand one of the parents' argument about Java web apps, but I don't use them a whole lot), so I believe you on that.

    I've always used the command-line to configure Cisco devices for that particular reason.

  59. Re:Java is already dead for new development. by durdur · · Score: 1

    Java in the browser has a lot of strong competitors now. Many modern apps are Javascript or Flash on the front end. Or HTML 5 if you want to live on the bleeding edge.

    But Java is still an excellent language for large server-side apps and is well supported by tools and a huge variety of open source apps and libraries. Leveraging this existing source base can cut a lot of time and effort out of app development.

    And, yes, it is still being used for new development. Oracle just for example were big internal users of Java before the acquisition and are still relying on Java for the bulk of their app development.

  60. you're missing a couple of things by yyxx · · Score: 1

    The Java software platform is a piece of software licensed as GPL. Anyone can take it, modify it and give it away to someone else.

    Not quite; there is a separate non-GPL version. That happens to be the version that people actually use.

    More importantly, Sun also had dozens of important patents related to Java that are now owned by Oracle. It is doubtful whether you can create a compliant Java implementation without infringing some of them.

    While the phenomenon known as Java may in theory be owned by Oracle it is in practive decoupled enough to be independent.

    I wouldn't be so sure about that.

    1. Re:you're missing a couple of things by dave87656 · · Score: 1

      Wasn't there a patent owned by xerox (I think) and maybe some others that Sun had to license for Java? My understanding was that there were are few patents that were licensed in the Sun version. The OpenJDK/JRE is free of those patents, AFAIK.

  61. that's not the problematic inconsistencies by yyxx · · Score: 1

    Besides Apple no one cares about consistency on the Desktop anymore. Have you looked at Microsoft apps lately?

    The main problem isn't with looks, it's functional incompatibilities: keyboards not being mapped properly, drag-and-drop not working, preferences not getting stored properly, etc.

  62. Re:Java is already dead for new development. by yyxx · · Score: 1

    An HTML page with a table that has 20,000 lines with 8 columns takes just under a minute to render (depends on a machine, but it's a good estimate) and it only takes a second (or less) to render in a Java applet with the same table.

    Well, the modern way of writing that is wit a mix of JavaScript and HTML; you can use the same tricks as you do in Java for incremental rendering, but it doesn't require the Java runtime.

  63. Re:Java is already dead for new development. by roman_mir · · Score: 1

    what 'tricks' do you do in Java?

    String[] columnNames = { "col1", "col2", "col3", "col4", "col5", "col6", "col7", "col8"};
    Object[][] data = new Object[20000][8];
    ... (get the data into the 'data' array)
    final JTable table = new JTable(data, columnNames);
    table.setSelectionMode(ListSelectionModel.SINGLE_SELECTION);
    table.setAutoResizeMode(JTable.AUTO_RESIZE_SUBSEQUENT_COLUMNS);
    table.getColumnModel().getColumn(0).setPreferredWidth(50);
    table.getColumnModel().getColumn(1).setPreferredWidth(250);
    table.setPreferredScrollableViewportSize(new Dimension(500, 300));
    table.setMaximumSize(new Dimension(2000, 1200));
    table.setMinimumSize(new Dimension(250, 150));
    table.setFillsViewportHeight(true);
    ... (create a listener)
    table.getSelectionModel().addListSelectionListener(tableSelectionListener);
    JScrollPane scrollPane = new JScrollPane(table);
     
    add scrollpane to your visible panel.
    Done.

    what tricks? The above code (I didn't include code for a ListSelectionListener) is all it takes to create a table in Java Swing that is immediately rendered, populated with all the data, you can immediately scroll to any part of the table, to the bottom, to the top, whatever, it all exists immediately.

    In HTML/CSS/Javascript you can't do that, you can't have the table created immediately that you can scroll around right away with no matter how you do it.

    In fact you are completely missing the point of BulkTableRenderer, which does exactly the opposite of what you are suggesting because the fastest way of creating a table in a browser is not with a javascript but with HTML text that only has pure HTML and by setting that as innerHTML to an element. That's the fastest way of doing that, go ahead, try making something work better or faster than the Google team could (and they have direct access to people working on WebKit engine.)

    Do it, put your money where your mouth is, talk is cheap.

  64. Re:Java is already dead for new development. by mswhippingboy · · Score: 1

    The fact of the matter is that JITs do not, in practice, make the JVM as fast as C/C++. The tests that have actually been performed show that it can reach that level in artificial microbenchmarks, but in real-world applications it rarely gets close, and it requires much more memory in the process.

    Actually I agree with you to some degree here. In most benchmarks that I've seen, Java does, at best, approach C++ but rarely surpasses it. But benchmarks are not real-world examples. In the real world developers are rarely given the opportunity to spend much time refining and optimizing their code (be it C++ or Java) and so once most programs are written and successfully pass unit/integration testing, they are thrown into production and not touched again except when additional functionality is desired (the "if it ain't broke don't fix it" mentality). This leads to a codebase that is naturally suboptimal.
    With C++, the native executable code is fixed and will continue to execute exactly the same instructions indefinitely until the code is recompiled.
    The same is not true of Java bytecode. With each interation of improvements in the JVM (especially the improvements in JIT in the last couple of years), the same bytecode will continue to improve in performance without the developers even having to touch it. With continued advances in garbage collection and JIT optimization, one can expect at some point, the bytecode (with the JIT's ability to optimize at runtime and make adjustments based on current conditions) that JVMs will surpass C++ performance for most real world examples.
    I know from my own anecdotal experience, whenever I've migrated a C++ application to Java, the results have been an order of magnitude higher performing and far more stable. Granted, many times this is due to my taking advantage of the built-in APIs in Java (such as collections), whereas the old C++ code might use simple sequential searches through arrays. But I guess that's my point. In general, expertly written C++ code will probably outperform Java for some time to come, but from my experience, a lot of C++ code is written by "less than expert" C++ programmers who do not write optimal code and no matter how good the C++ compiler's optimization capability is, it doesn't have the ability to rewrite a poorly conceived algorithm. While the same could be said for Java, the comprehensive APIs available are a lot more "in your face" when learning Java so they tend to be used more (at least that's been my experience, YMMV).

    --
    Sometimes the light at the end of the tunnel is the headlight of an oncoming train.
  65. Re:Java is already dead for new development. by SanityInAnarchy · · Score: 1

    for real, you are asking me 'so what' and that's your argument?

    I'm sorry, I could've been more specific:

    - Why is it important not to call the server as often, especially when HTTP caches will do the work for you?
    - Why are you comparing a complex Java app (or applet) with a "simple" HTML design?
    - What does "large" amounts of data have to do with it?

    Some of my users think that their 'computer is broken' when somebody re-sizes a window on their desktop,

    If your argument is that Java is a better environment for dealing with this particular class of users, I guess you win. That sounds like the same class of users who got bent out of shape when I attempted to migrate them from Outlook to Thunderbird, and Thunderbird didn't have their emails colored the way Outlook did. Seriously, they categorized emails by color.

    Those users are a lost cause for doing anything really interesting. There's a pervasive attitude in the non-IT world that even people who sit in front of a computer their entire day, whose entire job entails working with a computer, should somehow not have to be computer-literate, that it should be someone else's job to install antivirus, update their computer, keep it clean, and filter their Internet so they can't screw it up.

    I think the Web can do this, if not now, then soon. But I also think that recreating an existing app for such users isn't really an example of "new development" that the AC was talking about.

    Rendering done by the Java applet is completely different from what a browser does.

    I'm sure it is.

    Browser needs to parse HTML out, it needs to create some form of a document (DOM) it needs to prepare for quirks...

    So if you've got a fully compliant page (thus, you don't trigger quirksmode), you don't use InnerHTML, and you do create and update the table with JavaScript, you're not always triggering every stage of that, or even most of those stages. You can even avoid reflows.

    Java applet has none of those issues, it does not need to parse out any documents,

    Other than the document containing the Java applet, and you'll need to parse something to get at the data.

    as a result it responds immediately. 1 second after I load the 20,000 rows into it I can scroll ALL THE WAY TO THE BOTTOM. At this point a browser rendered maybe 300-400 rows only...

    ...if you rendered it as a simple HTML table. I'm fairly confident I can match what you've just described.

    Now, you're claiming that you can just render a 20k row table in Java, but what is that "rendering" actually doing? Do you have a pixmap of the entire table in memory? Or are you loading it into some Java library's concept of a "table", which draws only the relevant bits on the screen?

    But that's exactly the point -- I can draw only the relevant bits on the screen with a Javascript app. It may take a library to do it, but it takes a library for you to do the same thing.

    - for a compiled language it is not that much more verbose than C or C++, in fact less so depending on what you are doing.

    Define "compiled language" -- that's an implementation detail. Lisp is a compiled language.

    you have no idea what you are talking about. GWT is not a library.

    Why is this important?

    if GWT was written in C or C++ or PHP or whatever it still would have been as bad in terms of amount of code as GWT is with Java right now, not because of Java but because of what GWT is doing. GWT architecture requires much more code to be written that will have to be translated into Javascript/HTML

    It may be an issue with the architecture of GWT, but I don't see how it's at all related to any particular badness in HTML.

    You were the one who brought up GWT, to say that

    --
    Don't thank God, thank a doctor!
  66. Re:Java is already dead for new development. by yyxx · · Score: 1

    You have several options:

    (1) Render the table data in a canvas element. That's the direct equivalent of what Java does.

    (2) Use a small HTML table and change the content dynamically in response to moving a slider. This is simple but won't look that good.

    (3) Use a full HTML table but fill it in with empty, fixed size rows, then fill in the rows as they become visible. This is the least likely to work well on all browsers, but then Java isn't guaranteed to work well across browsers either.

  67. Why are you concerned that Oracle owns Java? by slashdot_commentator · · Score: 1

    So Gosling does not have confidence in Oracle's stewardship of java, and they part ways. So now the Java crowd feels unease.

    Where the HELL was Gosling when Java was under Sun's stewardship!??!?!?!? I sure as heck did NOT see a glowing future for Java a year ago!

    Oracle has owned Sun for barely a few months, and NOW they're supposed to have a magical future planned out for Java?!?!?!? HOW MUCH MONEY does Java produce for Oracle RIGHT NOW?

    The ONLY people who should be scrambling and thinking WTF? are people who have commercial Java product offerings. So, if you're IBM, or some Java tools vendor, you have a world of worry on your plate.

    But everyone else? I don't know. If you are INCAPABLE of learning another programming language besides Java, then I'd say you're screwed. But for the rest of the programmer industry (all 95% of it), it just means they will be implementing solutions in java for as long as it makes sense, THEN EVERYONE will move onto "THE NEXT NEW THING". Which, btw, has been the history of the programming industry. From assembler to FORTRAN to COBOL to C to DBASE to SQL to HTML to XML to ruby, etc. etc. etc. etc.

    Either Oracle gets it right or it doesn't. No one with a brain should give a damn. If you do, then you're some kind of retard who thinks java is the Alpha and Omega of programming languages. Its not. And even if it was, its extremely unlikely to be relevant in twenty years.

    --
    There is no America. There is no democracy. There is only IBM and AT&T and DuPont, Dow, General Electric, and Exxon