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?"

7 of 558 comments (clear)

  1. Stupid comparison by plumby · · Score: 4, Informative
    A "Googlefight" on, say, Java vs .NET tells us that all has not necessarily gone Java's way just recently. A "mere" 66 million "Java" hits...versus 388 million for "NET" - but that may all be about to change.

    Not that it really matters, but this is one of the most stupid comparisons ever. The .NET search pulls back just about every site with a .net extension. Out of the first 10 pages, only one seems to be directly related to the .NET framework (the 4th entry is php.net! ), whereas all of the first 10 Java searches is relevant.

  2. Re:Return of Java by latroM · · Score: 5, Informative

    The prepondereance of GNU fanboys means that Java gets dissed for not being Free(tm).

    The SUN's java implementation is non-free but there are other free implementations of the java standard, look at http://www.kaffe.org/ for one.

  3. Re:Java is not back. by LarsWestergren · · Score: 4, Informative

    Java language has stagnated in about 1999 with the release of J2SE 1.2 (dubbed Java 2)

    Oh, what BS. Like that is the only thing that has changed .Java has become big enough to come in three different version, enterprise, standard and micro edition. The micro edition is extremely common in mobile phones, enterprise very common in banking etc.

    Some of the new things in Java 1.3:
    Java Naming and Directory Interface (JNDI), 20% faster RMI serialization, improvements in AWT/Swing/JavaSound, security enhancements, HotSpot optimization of client and server VMs.

    In Java 1.4:
    Secure Sockets and HTTPS, IPv6, cryptography extensions, LinkedHashMap, NIO (FileChannel, Non blocking IO), builtin regexp and logging (though there are even better open source libraries for those), assertions, XML processing, hardware acceleration of Java2D, image I/O framework, java Web start, Unicode 3.0 Support, Currency class, Accessibility improvements, Math improvments, Itanium support

    In Java 1.5:
    Generics, enhanced for Loop (for each), autoboxing/unboxing, typesafe enums, varargs, metadata annotations, class data sharing (improved VM startup time), launching apps under inetd in unix/linux, loads of security enhancements, Unicode 4 support, hyperbolic transcendental functions (sinh, cosh, tanh), cube root, base 10 logarithm, AMD Opteron support....

    Sun is not letting MS win without a fight.

    --

    Being bitter is drinking poison and hoping someone else will die

  4. Re:And for anybody who doesn't believe... by Glock27 · · Score: 4, Informative
    And anybody who doesn't believe this might want to take a look at why kast wasn't written in Java.

    One doesn't have to look far to find claims there that are simply wrong. For instance:

    java applications leak memory--- java uses garbage collection to manage memory, which seems to imply that programmers don't need to think about memory management at all. However, garbage collection gives a false sense of security, and java applications can still have memory leaks unless programmers are very careful. In fact, many java applications that run for extended periods of time leak memory to the point of exhausting all system memory. These types of leaks are very difficult for programmers to isolate. In fact, memory management may be more difficult with a garbage collector than without one.
    In particular, the last sentence is nonsense. Memory leaks, once identified, aren't typically hard to find in Java - and let's not forget that Java eliminates several types of memory related errors common in C/C++ programs altogether. Array overruns, wild pointers, multiple deallocations - all things of the past. Thankfully.

    Some of the other objections there will go away with JDK 1.5, others might best be addressed with ahead-of-time compilation (small utilities for instance). Regardless, Java is certainly improving over time.

    All that said, of course, incompetent programmers will manage to screw up in any language they're given. ;-)

    --
    Galileo: "The Earth revolves around the Sun!"
    Score: -1 100% Flamebait
  5. Googlefight is a bit hmm by kahei · · Score: 4, Informative


    The article notes that a googlefight gives 66 million hits for java and 386 million for .NET (actually, those are the numbers I got just now, but they're similar).

    Thing is, the .NET hits include EVERYTHING IN THE WORLD THAT HAS A DOMAIN ENDING IN .NET, which makes it A BIT SILLY.

    The article is trying to make out like Java 'went away', just so it can build momentum for a comeback. I don't care for Java as a technology, but I'm pretty sure it never 'went away' at all -- and the fact that Java developers are cheap and common compared to almost every other kind is going to keep Java on the servers for a long long time.

    I wish Mono would hurry up.

    --
    Whence? Hence. Whither? Thither.
  6. Re:The Reason Java 'appears' slow, by nikster · · Score: 4, Informative

    can you elaborate on that? i don't quite understand... where exactly do you save time over MVC? where does the MVC paradigm say you need to copy anything? Example: the java TableModel. it's an interface, so my model can implement this interface and JTable will access the values directly, without doing any copying.

    i have written many MVC apps in Java, and they are performing quite well. The performance improvements i make usually start and end with one single thing: Remove unneccessary updates. Most Java programmers don't realize, but their screens get updated 10 times from all kinds of different updating mechanisms. E.g. user clicks button, update event is fired, sometimes two, a chain of update events from all sorts of components that change as a result triggers a chain of repaint events. Now, if you hold off with updating until all update events have settled down, you paint 10 (and i have seen up to 100 times) less.
    Result: what was sluggish is all of a sudden blazingly fast. Even though you "wait" for the event queue to clear.

    This is something that one would expect Java to do internally, esp. if you are familiar with the way updating works, but in reality, it's the bottleneck.

    The reason i usually adhere to MVC is that it allows you to have multiple views on one model and to easily add more views to one model.

  7. Re:The Reason Java 'appears' slow, by ragnar · · Score: 4, Informative

    I'm calling BS on this explanation. Unless your model and view are communicated via SOAP or the proverbial horse and carriage, there is little reason for in-process communication to be a bottle neck for applications.

    In my experience, the slowness of an application can usually be narrowed down to a few hot spots where the wrong data structure is in use, or database access is done poorly. None of this relates to MVC.

    --
    -- Solaris Central - http://w