Slashdot Mirror


The "Return" of Java Discussed

An anonymous reader writes "Following on from the marvelous recent James Gosling interview highlighted in Slashdot last week, it would seem that a renewed momentum is building up for his cross-platform creation, if this editorial is anything to go by. It's called 'Java is Back!' But did it ever go anywhere?"

13 of 558 comments (clear)

  1. Embedded Java. by Vo0k · · Score: 3, Interesting


    Java is a nice choice for embedded platforms. It runs several times faster than on PCs (it's native for the hardware, not "emulated" through JRE), the hardware is inexpensive and can perform really sophisticated jobs. I think it may be one of major reasons for Java to take up so much.

    Java powered cryptographic iButton - a chip the size of your hand watch battery (stainless steel, shock-resistant, water-resistant and several other-resistant "iButton" package) with Java support.

    --
    Anagram("United States of America") == "Dine out, taste a Mac, fries"
  2. APIs and Libraries by tezza · · Score: 5, Interesting
    CPAN was a real winner for Perl back in the early days of the web. Want SMTP? Net::SMTP. Want to format that email response? Text::AutoFormat. Easy templates? Template::Toolkit.

    Java now has an astounding array of libraries to use these days. Look at for some good ones.

    --
    [% slash_sig_val.text %]
  3. And for anybody who doesn't believe... by RAMMS+EIN · · Score: 3, Interesting

    ``Java is slow, obeist, and heavy.''

    And anybody who doesn't believe this might want to take a look at why kast wasn't written in Java. People have been telling me that I am the only one experiencing these issues, that I simply don't have enough experience, or that I should take a look at modern JVMs - well, here's one example of people who tried Java and were disappointed. The same happened to many LimeWire users. The list goes on.

    --
    Please correct me if I got my facts wrong.
    1. Re:And for anybody who doesn't believe... by LizardKing · · Score: 5, Interesting

      java applications are difficult to install - many users do not already have a copy of the java virtual machine installed on their machine. For these users, installing a java application means downloading and installing the java runtime, which is quite large and can be difficult to configure.

      Well, you must be pretty hopeless not to be able to install the Java runtime. Last time I installed it on Windows, it took half a dozen mouse clicks and a couple of minutes tops.

      java applications start up slowly - even the smallest java applications can take several seconds to start up, since the virtual machine needs to be loaded first.

      I run Java on very low spec embedded PC's, and it's no slouch there. Even if there is a couple of seconds wait at startup, the JIT compiler means a well written app will run without being appreciably slower than a "native" app once the JVM is bootstrapped.

      java applications have slow, unresponsive user interfaces--- on slower machines, using java-based user interfaces can be frustrating (resizing the application window can mean taking a coffee break).

      That's strange, it must be their inability to code an interface and data models in an efficient manner. I write warehouse control software, where we are dealing with vasts amount of data that must be collated and displayed to the user. Very rarely do we have to resort to doing major grunt work on the server as opposed to doing it in the Java client.

      java applications use a lot of memory - on most platforms, the virtual machine itself requires several MiB of memory, even for small applications that use very little memory. For more complicated applications, such as konspire2b, the virtual machine adds a lot of memory overhead. For example, kast currently uses about 1 MiB of memory when it's up and running. konspire 1.0 server (written using java) uses about 12 MiB. The interesting point is that konspire2b is far more complex that konspire 1.0 server (for example, the server portion of konspire 1.0 doesn't even have a user interface).

      If this is really an issue for you, then you can tweak the runtimes environment. Yes, Java does requisition a lot of memeory when an untweaked JVM starts up, but the inmpact depends on the machine running the program.

      java applications leak memory

      This could be rephraed as "bad Java programmers leak memory". I have client-server Java applications that run 24x7 without leaking memory. Perhaps it's because I'm an unsually good Java programmer? Probably not, as I'm just an average one. What I don't do is immediately blame problems on the tools I use until I'm sure it isn't my lack of skill with the tools.

    2. Re:And for anybody who doesn't believe... by mcbevin · · Score: 5, Interesting

      I agree with what you write in general - that the article was unduly harsh / biased against Java. However, I differ on a few details ...

      Well, you must be pretty hopeless not to be able to install the Java runtime. Last time I installed it on Windows, it took half a dozen mouse clicks and a couple of minutes tops.

      We're talking about the average Joe here. The average Joe just wants to double-click the installer for a program, click OK a couple of times, and have it work. I know from experience that such a requirement can be a great hinderance to adoption of a software application. I released a program with a .NET frontend, and a large portion of end-users weren't interested in downloading the .NET framework (why this wasn't made part of XP or at least XP SP1 I don't know) and would quite happily write the program off as broken despite it having informed them they need to download the .NET framework for it to run.

      That's strange, it must be their inability to code an interface and data models in an efficient manner. I write warehouse control software, where we are dealing with vasts amount of data that must be collated and displayed to the user. Very rarely do we have to resort to doing major grunt work on the server as opposed to doing it in the Java client.

      Swing _is_ rather unresponsive and slow unfortunately, due to it using no native widgets. This is solved by SWT, which mixes platform independence with use of native widgets where they exist. For this reason for example the popular Java IDE Eclipse (written with SWT) is much more responsive than Sun's IDE NetBeans. Swing in general is one of Java's major weaknesses (and its not 'excused' on the basis of platform independence) - not only in terms of speed but its layout managers for example are also a joke - and is the main reason why Java is used far far more for websites than application programs.

      This could be rephraed as "bad Java programmers leak memory". I have client-server Java applications that run 24x7 without leaking memory.

      I agree with you there, and would also add that 'very bad java programmers leak memory' while 'even pretty good C/C++ programmers leak memory. While one can leak memory in any language, Java does make it a lot easier to avoid. I have C++ programs where I've never found leaks despite a fair bit of work trying, yet I can't recall testing a single Java program for memory leaks (and I've written and tested a lot) and ever actually finding such a leak.

      If this is really an issue for you, then you can tweak the runtimes environment. Yes, Java does requisition a lot of memeory when an untweaked JVM starts up, but the inmpact depends on the machine running the program.

      Unfortunately for the average user with 'just' 256/512mb RAM on their machine, thrashing is almost an unavoidable consequence of using any non-trivial Java application. For development I find 1 gig RAM is a minimum for devloping with Java, whereas for .NET development I have no problems using 'just' 512 megs.

      I might also add a thought relating to the actual editorial - comparing search results for 'NET' and 'Java' is hardly an accurate comparison, given that 'NET' is liable to find a lot more pages than just those relating to .NET. That said, .NET and its C# language _is_ a huge challenge for Java. I'm hoping that this competition will cause both languages to improve and thus benefit us developers. Java 1.5 (5.0) is a great start (incorporating many much needed features seen in .NET such as generics).

  4. Re:There has been some good alternatives by Coppertone · · Score: 3, Interesting

    Java is "slow" because Sun has give us a brain dead GUI components. If you are looking at server side running things like EJBs, JSPs and servlets it is just as competitive as .NET framework.

    There are a lot of pending improvement on Java GUI front, like Eclipse Rich Client Framework using SWT and hopefully it will not be "slow" anymore

  5. Java 1.5 should help things. by Anonymous Coward · · Score: 3, Interesting

    Java is a great language that people avoid because it's a pain in the ass.

    Java 1.5 goes a long way to help that, what with iterators, autoboxing and such.

  6. I'll called my platform ".COM" by Vo0k · · Score: 5, Interesting

    I'd win hands down. .NET
    (386 000 000 results)

    versus .COM
    (1940 000 000 results)

    --
    Anagram("United States of America") == "Dine out, taste a Mac, fries"
  7. Re:Java is not back. by Baki · · Score: 4, Interesting

    No it won't. Server-side programming (i.e. "enterprise") means backwards compatability is very important. MSFT cannot afford to break it in .NET either.

    SUN has done an amazing job in extending Java even to include generics without breaking backwards compatability. Yes it did not lead to the solution that is technically and internally the most efficient (it would have required changes to the JVM), but the developer is not affected. Internally it is solved by typecasts, but who cares? The compiler, it cares and verifies and tat is what matters. .NET is years behind and plans to bring similar features only in 2007 (generics). It remains to be seen if they can do it without breaking backwards compatability. They already have a very hard time to convince their current developers to switch to .NET, they cannot afford to make their developers have to migrate once more in the next 10 years. .NET being so poorly designed I truely wonder if they can improve it without disturbing compatability. I cannot see it being a threat.

    I work in a large company, and all new development is done 100% in Java (except the mainframe parts, in PL/1 but that is declining rapidly). .NET would only be considered for fat client GUI's which used to be done in MFC. So even if .NET becomes a success, it will only replace parts that were already done in MSFT technology before, it has zero chance on the server side.

  8. Re:It went to million servers and clients by dnoyeb · · Score: 4, Interesting

    "And thats the real big difference to mono. Java may run on any Computer since 92' till 2050, without need to take care of what Microsoft will change in 2 years."

    Let me correct you slightly. There is always the need to make changes to adapt to what MS does. Its just that with Java that responsibility falls to the JVM writers and not the application writers.

    A windows JVM is just another windows c/c++ program. Many people keep forgetting that.

  9. Mobile??? by Akimotos · · Score: 4, Interesting

    I never thought of Java as something worth following, because it was my personal experiece that: - it is slow - files are biiiiiig I mean, running some Java app makes the fan of my Powerbook spinning. Face it, only Photoshop and Imovie do that to me ...

    But in Europe Java is really strong in the mobile phone environment. I have this SE 900 and it always draws lots of attention and things that strike me most are remarks of non-technical people, like the 16 (or something) year old girl at some fast food joint: "Does it have Java?" Even my sister (30, knows shit about computers) has it on her wishlist: a Java enabled mobile phone...

    The fact alone that it is seen as some 'special' thing ... Sun (or Nokia, or whoever) has done a great job there.

  10. the J2EE market has been going strong for a while by sethg · · Score: 4, Interesting
    ...unfortunately.

    When I was unemployed, I had monster.com and dice.com send me a daily email with every new job posting that contained "Perl" or "Java". For those ten months, I saw virtually no Perl jobs, and almost every Java-related job required J2EE experience.

    So I took a basic class in J2EE, and said to myself, "No wonder there are so many openings for J2EE programmers: it takes a team of five J2EE programmers a month to put together what a good Perl hacker can make in a week." The hoops you have to jump through to get things to work in J2EE--most of which seem to involve working around Java's static typing and its object model--are absurd.

    I've been re-employed for almost a year, thank God, and the group I work with is writing a J2EE-based ERP application. I have seen nothing so far to refute my original impression of J2EE.

    But it still beats being unemployed.

    --
    send all spam to theotherwhitemeat@ropine.com
  11. Re:Stop moaning sweetheart by Undertaker43017 · · Score: 3, Interesting

    "And you JAVA peopel should get it into your head that applications need to fit in with the environment they are runnign on. Why the hell should that oen application look out of place?"

    I agree completely with this statement. This has become a much bigger frustration for me since I moved to OS X. I used to use NetBeans for developement. Netbeans looks fine on X11 and Linux, and OK on Windows, but looks horrible on OS X. So I switched to Eclipse, and it looks great. The Eclipse folks have shown that a little effort can make a Java GUI look good, and be integrated well into the native environment.