The "Return" of Java Discussed 558
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?"
Stupid comparison (Score:5, Informative)
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.
Re:And for anybody who doesn't believe... (Score:3, Informative)
If only everyone knows how to write Java properly....
For those who haven't been looking at Java lately (Score:2, Informative)
Eclipse project: http://www.eclipse.org
Re:Return of Java (Score:5, Informative)
The SUN's java implementation is non-free but there are other free implementations of the java standard, look at http://www.kaffe.org/ [kaffe.org] for one.
Re:Move along, nothing to see here.. (Score:3, Informative)
Re:Java is not back. (Score:5, Informative)
Oh, what BS. Like that is the only thing that has changed
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 [sun.com], 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.
Re:And for anybody who doesn't believe... (Score:4, Informative)
Top 4 processes on my XP Pro machine at the moment, according to "Mem Usage" column in Task Manager:
1) JBuilderW.exe at 173,700K
2) mozilla.exe at 84,480K
3) java.exe (JXplorer, an LDAP client app) at 37,252K
4) WINWORD.EXE at 33,636K
So, with the exception of JBuilder (which is very heavyweight, there's no denying), java by no means has a "huge" footprint compared with other typical applications I use. Of course, given that I have a gig of RAM in this machine, and that RAM goes for a little more per 512MB stick than I spend on a typical Saturday night out, it really doesn't matter to me at all. But then, I do server-side stuff in Java, not client side; for that, I'd probably use C#.
Difficult to install? Use Advanced Installer for J (Score:2, Informative)
1) Look for a JRE on the target machine.
2) Download and install one if necessary.
It will also create a native Java launcher, for quick splash screens, file associations, 32 bit icons, etc.
And best of all - it's a breeze to use.
http://www.advancedinstaller.com
Re:why bother arguing (Score:2, Informative)
One of my favs is Quarbon [quarbon.com] - which runs great on linux, BTW. This app allows you to make a flash presentation out of your screenshots and mouse clicks. In action using it resembles powerpoint - but its too cool for words!
Re:False arguments of past not valid (Score:3, Informative)
Really? What about gcj, TowerJ, Jet and other native Java compilers? There is nothing preventing Java from being compiled to straight machine code using traditional ahead-of-time compilation. The stricter semantics of Java compared to C++ permit further optimization, as is the case with Fortran also, for instance.
If a Fortran compiler were written in C++, would that still mean generated executables couldn't be faster than C++ at numeric code? No.
Runtime profiling/optimization is a more complex topic, but in principle (and apparently in practice) there are cases where it is faster than ahead-of-time compilation. I think both approaches have merit.
I usually like to make this point 2-3 times when it comes up on slashdot once per month.
Repetition doesn't make it any more correct.
Java vs ".net -site:.net" (Score:3, Informative)
Java vs
65.6 million for "Java"
22.4 million for ".net -site:.net"
-metric
Re:why bother arguing (Score:2, Informative)
Re:Java vs ".net -site:.net" (Score:3, Informative)
Nevermind.
Google ignores the initial period in
-metric
Re:And for anybody who doesn't believe... (Score:3, Informative)
This is the developers problem
- java applications start up slowly
As with any interpreted language, and has been an issue since Qbasic. Accept it.
- java applications use a lot of memory
As many applications do. 20 meg for Soundtool is ridiculous, but with a gig of ram, there is plenty left over.
- java applications leak memory
So do most other applications. If the programmer does not take heed. Again, a very broad statement having little to do with the language.
I like the portablility of Java - something most people forget about when whining and bitching about it. Think about the other applications you use, and how they suck too. The same people that wrote windows are the same ones that have an internal disgust for Java... keep that in mind as well.
java and linux rocks, .Net is like flakey VB/COM (Score:1, Informative)
Elipse is the best IDE and weblogic/tomcat best appserver.
Re:And for anybody who doesn't believe... (Score:5, Informative)
One doesn't have to look far to find claims there that are simply wrong. For instance:
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. ;-)
Re:Return of Java (Score:3, Informative)
Strings are something of a weak point with Java, IMO. I'm still not sure immutable Strings were a good idea, especially since it's become a common idiom to use StringBuffer instead for performance reasons. With the latest JDK there is a yet another new string class that's like StringBuffer without synchronization - since single-thread string manipulation is the most common usage.
All that said, if you know what you're doing, you can get fine string performance in Java. There are third party classes (see FastString) that may help as well. It is too bad that this area of the language wasn't better thought out in the first place, though.
(An interesting performance enhancer worth looking into is JADE [dautelle.com], which contains FastString. It also has interesting realtime stuff which eliminates garbage collection overhead and pauses if used properly. Lots of other good stuff too.)
Re:The Reason Java 'appears' slow, (Score:3, Informative)
The thing you're explaining has nothing to do with MVC, I'd call it "on-demand fetching".
Cocoa on Mac OS X uses on-demand fetching for tables and optionally popup buttons (and optionally menus since 10.3).
Googlefight is a bit hmm (Score:5, Informative)
The article notes that a googlefight gives 66 million hits for java and 386 million for
Thing is, the
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.
Re:The Reason Java 'appears' slow, (Score:5, Informative)
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.
Re:Return of Java (Score:3, Informative)
Well, problem #1 is using Tomcat on a "non-trivial" production application. If you have to go free, Resin and Jetty are both more performant.
Re:And for anybody who doesn't believe... (Score:2, Informative)
java applications are difficult to install
Absolutely. Everybody installs their own JVM, which means that Sun's concept of installing one JVM everywhere is a disastrous failure. Sun needs to fix this ASAP, starting with the licensing terms which don't allow anyone to ship an incomplete JVM with their app. Small apps are impossible because of this.
java applications start up slowly
Absolutely. Sun's failure since they could easily cache the binaries for the base classes and individual apps, too. Instead, Object.class gets translated into machine code every time i start the JVM, over and over again...
java applications have slow, unresponsive user interfaces
This isn't true anymore ever since Swing got seriously hardware accelerated [JDK 1.4.x]. It's not entirely trivial, but also not too hard to create fast Swing apps nowadays. Also, SWT has become a real alternative.
java applications use a lot of memory
Absolutely. Again, i can't write a small tool or even small utility app without using 30M of main memory. Bad.
java applications leak memory
No, they don't.
The assertion that programmers pay less attention when not having to do their own mem management is ridiculous. Sun is partially to blame though because all their documentation, from the very start, touts the garbage collector as "freeing you from having to think about memory" which is simply not true.
It was a bit of a pain before weak reference classes were introduced, but nowadays there is no excuse for a Java app to leak memory. Granted, there are some remaining problems in the Swing framework, but no framework is bug free.
Re:The Reason Java 'appears' slow, (Score:2, Informative)
The view is responsible for mapping graphics onto a device, to achieve this you don't need to copy any data from the model to the view, you can just access the model data directly whenever you recieve a change notification in the view.
And you certainly don't need to start storing model data in the view to achieve reasonable performance - that would be very poor data encapsulation.
If you want still better performance then eliminate unneccessary notification events or send different notification events for different types of model change. (non-pure mvc but easily support with observer/observable)
Sheesh, I can't believe this got modded so high. I reckon most of slashdot are sysadmins and not developers. (ducks)
Odd comment about realtime, C, and Java... (Score:3, Informative)
If you're doing hard realtime you don't call malloc and free: you use a buffer pool that's sized for the objects you're working on, and allocate objects from that. Not only do malloc and free make a hash of timing dependencies, they make a hash of memory itself. The fragmentation you get from malloc and free are fine for short-running programs or programs that can afford a small slow memory leak as locked-down allocations make chunks of the heap unusable, but for realtime that just doesn't cut it.
It's much the same as in the OS kernel or in file systems, you have pools of fixed size objects that you stick fixed size chunks of data into, your buffer cache and cylinder groups and clists and things. You can use some of the same tools to improve the behaviour of malloc and free, too, but you get a lot more memory overhead because you rarely have the kind of good sizing information that more or less automatically falls out in the process of designing your memory strategy without it.
Bringing up malloc and free as reasons why Java's not so bad for realtime is really a red herring. I don't know if Gosling's just not used to a hard realtime environment, or what, but he's definitely muddying the waters here.
Re:The Reason Java 'appears' slow, (Score:5, Informative)
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.
Re:There has been some good alternatives (Score:3, Informative)
With Mono now at version 1.0, then perhaps C# is in a position to threaten Javas cross platform crown, although perhaps not without Windows Forms support.
Doh! [slashdot.org]
Re:Return of Java (Score:3, Informative)
If you're restricted to 64M, your hosting solution is obviously for trivial web applications. RAM is cheaper than your paycheck, unless you live in a 3rd world country. Where I work, we have a pretty trivial web application, and I throw about 2Gig of RAM at it because I want to keep as much data in memory as possible for response times.
Re:And for anybody who doesn't believe... (Score:4, Informative)
For Windows perhaps. But if you're going to confine yourself to Windows, why bother with Java?
Java Web Start, atleast the one from Sun, is available on SPARC, Solaris X86, Linux, Mac OSX, and Windows.
You should compare a Java text editor to a native text editor
Well, if you take out the virtual machine Java would be about equal or better. Now you probably say thats not a fair comparison and I cant do that. But those Java crazy's are working on a single VM for multiple apps targetted for release 1.6. You can do this currently yourself too. I did this recently where I have two java apps launched from a single VM.
but, again, if you're going to tie yourself to a specific version of a VM on a specific platform, why use Java at all?
Are you talking end user or programmer? As a programmer, I can write in Java and know it will run on multiple platforms.
End users dont need to worry much about this. Recent versions of Suns java jvm updates itself. Since java is backwards compatible this means your incompatibility version issue is not really an issue.
I think that the fact that you felt the need to escape from Java and use an ActiveX control is all the proof that's required.
The activeX control was an Internet Explorer browser. Since I didnt feel like writing Internet Explorer again in Java it seemed like the smart thing to do. Your original argument was that Java apps did not play nicely with native ones which I proved incorrect.
Like COBOL, yes.
Yep. Only difference is Java apps are growing in numbers whereas theres often no new Cobol apps.
Re:Stop moaning sweetheart (Score:2, Informative)
The whole native OS interface thing, isn't a Java only problem. Open source native apps suffer the same problem, for instance OpenOffice doesn't take advantage of Carbon, and looks and works poorer on OS X. Unfortunately with native apps, this is a much harder problem.
It all comes down to a resource problem, if all OOS project's had the resources that Eclipse does, they could produce a native look and feel app for all the platforms they support too.
"If you are doing development for OS X, just use Objective-C... that is more fun anyway."
I'm not doing development for OS X, our target is any platform that has a Java VM. I just happen to develop on OS X, the rest of the team develops on *nix, and Win32.
Re:Embedded Java debunked (Score:3, Informative)
He's not talking about using Java on PPC, ARM, or AD Blackfin. He's talking about using it on machines designed for Java.
In these cases, most of the 'JVM' is implemented in hardware, so it's not slow. The included classes are scaled down to what you could conceivably use (none of the GUI stuff), so it's not really that bloated.
The GC is still non-deterministic so you wouldn't want to use it in an avionics system, but it would work fine in embedded systems without hard realtime constraints. And since most embedded systems don't have hard realtime constraints they would work fine in most embedded systems.
That being said, I wouldn't want to use one....(eee...Java....).
Re:Java is not back. (Score:3, Informative)
That is absurd... you seem to be arguing that increasing the syntax of a language is the only acceptable improvement. Why is that, adding to the language or adding to the libraries are both just ways to make it easier for programmers to accomplish things.
There are drawbacks to increasing syntax, though you get increased power, the language will take longer time to learn and programs risk being harder to read and harder to maintain, especially for junior programmers.
Also, if you add new symbols to a language you risk breaking old user code. That is why Sun have been very reluctant to add to the syntax of Java; and did not use foreach or for x in y, but rather for (String x: Collection y). People might have variables called foreach, but there is no variable called : anywhere.
You are correct in that improving the libraries and virtual machines is changing the Java platform rather than the language. However, that is no small feat in my opinion. If they improve the VM so that my program runs faster and becomes more secure without me having to change a line of code, that is an enormous increase in my productivity as a programmer. I take that before an increased syntax any day. I know, I'm lazy, I'm not hardcore, I don't have the hacker mentality, but I happen to think life is too short to be spending more time than necessary in front of a computer.
And J2SE 1.5 is just a frantic attempt to add some sugar into Java language.
Oh, so now increasing the syntax of a language is "just" syntactic sugar suddenly? I am very happy with the new improvements, since they finally get rid of many of the most annoying verbose things in Java that people have been complaining about for a long time. For instance, foreach and generics turns this:into this:Easier to read, and also removes a possible class cast bug since it prevents anyone at compile time from accidentally adding something other than TimerTasks to the collection.
1.5 has also taken the first steps to having one JVM for all java programs like in the MacOS JVM done by Apple. This will decrease loading times and memory footprints (for all programs except the first loaded) greatly. If they succeed in adding it to the platform that is....
Re:Return of Java (Score:3, Informative)
Not to be confused with scripting languages [c2.com], which is more about a language's environment than the language itself; you can make C into a scripting language with the right tools, but you're not going to make it into a dynamic one without changing the language itself.