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?"
Java now has an astounding array of libraries to use these days. Look at for some good ones.
[% slash_sig_val.text %]
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.
I'd win hands down. .NET
.COM
(386 000 000 results)
versus
(1940 000 000 results)
Anagram("United States of America") == "Dine out, taste a Mac, fries"
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.
.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.
.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.
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.
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).
"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.
I agree with what you write in general - that the article was unduly harsh / biased against Java. However, I differ on a few details ...
.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.
.NET development I have no problems using 'just' 512 megs.
.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).
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
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
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
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 ...
... Sun (or Nokia, or whoever) has done a great job there.
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
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