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

Comments

Re:I agree with that

[Anonymous Coward]

Yes. It was shunned by many people who would have used it because it was too slow and lacked nice visual stuff (controls etc). Now PCs are generally faster it's worth looking into again.

There has been some good alternatives

[after]

wxWidgets (my favorite) and wx.NET
Mono
Cocoa# and Gtk# (recentely kn /.) .NET

Java is slow, obeist, and heavy.

Re:There has been some good alternatives

[LizardKing]

But how many companies do you see requiruing wxWidgets experience? Not to knock it as a cross platform development toolkit, but rightly or wrongly it's overlooked by virtually every company I've ever worked at. The exception is my current employer, where it was evaluate along with Qt and Java as a means to write cross platform GUIs. Java won, as C++ proved far too troublesome on a previous project.

.NET is actually a back handed compliment to Java. Java was so good that MicroSoft had to clone it. 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.

Re:There has been some good alternatives

[Coppertone]

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

Re:There has been some good alternatives

[Anonymous Coward]

Yawn. The 'Java is slow, obese and heavy' arguments are poor, out of date and largely inaccurate. Java's popularity on mobile phones suggests it is hardly a performance bottleneck, nor is it too demanding for memory.

When Java first came out, a large number of 'web hackers' and inexperienced programmers flocked to the language and produced applications that were often very weak. The easy access to such a flexible toolkit encouraged first time coders to undertake projects beyond their skills. Even experienced teams of developers found it took a while to get to grips with the issues involved in the new environment. The result was the inevitable disillusionment following the hype. Expect C# to go through a similar slump as people realise it doesn't solve all your problems.

However, Sun have done a stunning job in evolving Java, and developers who have taken the time to understand it have been producing impressive software for some time now. The latest version is powerful, fast and addresses an enormous range of requirements that make developing software very much more efficient.

There will be a lot more about Java in the news this year. Tools are being developed for everything from screensavers to MMORPGs, so why not take a second look before rehashing old predjudices?

Re:There has been some good alternatives

[Anonymous Coward]

"Java is slow, obeist, and heavy"

And Mono, plus wxWidgets, plus wx.NET is not?

I don't like Java any more than the next guy. However, you have to consider more than just speed and size when writing software. You have to consider what is already implelement and popular. .NET isn't there yet, Mono and all the add-ons needed to make it as good as .NET isn't there yet. With Longhorn, .NET will be a viable platform since it'll be bundled. Until then, if you want something cross-platform, Java is the only answer.

Now, even if you ignored what I said above. you still can't write all too cross-platformish applications with .NET or Mono, even with a GUI toolkit add-on and such.

With open source software, it's very different. You can use anything you want since you don't have to worry about profits.

Re:There has been some good alternatives

[tomee]

I used to think java was slow, but used it anyway. One day a java application (a game console emulator we wrote) was running too slow, so we ported it to c++ and optimized it. The result was maybe about 30% performance gain. I think for something that java is definetely not meant for (a virtual machine on a virtual machine) that is pretty impressive. And the main reason I think that the java version is slower is that java doesn't have unsigned variables so we had to use larger variables and & them with 0xFF in every single operation.

Re:There has been some good alternatives

[Anonymous Coward]

This is my experience, too. Java is great for server side and some networking applications, but terrible for GUI and large-scale string manipulation.

Re:There has been some good alternatives

[mcbevin]

Java's popularity on mobile phones suggests it is hardly a performance bottleneck, nor is it too demanding for memory.

No. Rather, mobile phones offer something PCs don't - a pre-defined fixed amount of memory. This allows the Java programmers to code and test knowing exactly what constraints the end environment will have. That said, a lot of the work that goes into programming Java for mobile phones goes into ensuring these memory limitations are met.

Also, Java applications for mobile phones don't use Swing, which is often the culprit in giving people the impression that Java as a language is slow.

Expect C# to go through a similar slump as people realise it doesn't solve all your problems.


I'm not sure that C# has been marketed as the do everything language in the way that Java was. Its also been able to learn from Java's mistakes and thus avoid many of them. Java's backward compatibility constraints (which C# avoids with its versioning mechanisms) make it very hard for it to continue to keep pace (i.e. see Java's somewhat crippled upcoming implementation of generics vs .NET's upcoming implementation of them).

Re:There has been some good alternatives

[redsolo]

Im amazed that MS (or other firms) have managed to let these rumors become facts. Java is not slow, at my last job we created an image viewer for professional photographers which was running on Java. The system had no problem showing 2000 thumbs (not at the same time, but scrolling was instant), zooming into 10mbs images was a breeze, you could play with the mouse buttons and it would instantly zoom to the 1:1 layer and back again. And this is something that Java has been known to be very bad with GUI and images. But we managed to pull it of anyway, and it was even quicker than the defacto industry standard application, which was written in C++.

So, please dont come with those crap arguments, because they are not true.

But what is true; c++ will always be faster than java, .Net might be (but thats because of the infamous shortcuts than only MS ppl know of). But is that the really point, when you are creating desktop applications? If you want speed, try develop a desktop app in Assembler. Now it will be the fastest around, but probably look like crap.

What must be really annoying, is that .NET has borrowed so many classes from Java so they should call it J--.

Re:There has been some good alternatives

[Junichiro Koizumi]

Except those Java phone apps are slow as all fuck. Compare them to stuff on the GBA, where even C++ is often seen as too heavy (nobody ever uses virtual functions on the GBA, and you can't not use virtual functions in Java), and you'll see what a horrible mess Java is on this shit.

Re:There has been some good alternatives

[Anonymous Coward]

"Java is slow, obeist, and heavy"

One thing I've found in common in all the VM's is their inability to cope with apps requiring large amounts of RAM. Once the RAM needed exceeds what the OS can give and swapping occurs, the apps grind to a halt. The generation mechanism helps, but in an app that is more than 30% or so swapped out, things quickly grind to a crawl.

Traversing an object graph in paged based OS is not the greatest thing in the world even when it's only a portion of the objects.

If you really want to see this exagerated, take a look at any .Net database application that allocates a lot of RAM. The ADO .Net lib's seem to really agressively invoke GC, which really magnifies the problem.

I'm still not convinced that garbage collection is all that great. While it has allowed me to create more complex object relationships, I'm not sure that's really a good thing in general either. Had I been faced with dealing with ownership the object relationships would probably have been simpler.

Re:There has been some good alternatives

[Coppertone]

String Manipulation is okay - nowadays the java compiler optimises those pretty well - what problem do you have?

Re:There has been some good alternatives

[no soup for you]

What must be really annoying, is that .NET has borrowed so many classes from Java so they should call it J--.

Well I don't think Microsoft has ever denied it --- but they do what they do. They hired the then head of Borland's Delphi devision, and molded Delphi, C++, and Java. And I think it put together an excellent language, platform independence

Re:There has been some good alternatives

[bmj]

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!

Re:There has been some good alternatives

[StarfishOne]

wxWidgets:
wxPython + Python + Boa Constructor.. works as a charm! \o/

Re:There has been some good alternatives

[Randolpho]

.NET is actually a back handed compliment to Java. Java was so good that MicroSoft had to clone it. 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.

Where C# is most threatening to Java, Windows Forms not as relevant: C# frankly makes Java look stupid with its properties syntax. Properties are like portions of the EJB properties specifications, only without all the silly get/set coding conventions... it's built right into the syntax and the engine takes care of mapping methods for you. This makes it easier to build and maintain COM/Bean like persistent property-bearing objects. *That* is where C# will beat Java. Alas that Java 1.5 -- er... Java 5.0 -- doesn't address this issue.

Re:There has been some good alternatives

[Eudial]

Java is slow, obeist, and heavy.

That was true with = Java 1.4, but not any more. Java 1.5 is fast. VERY fast. My experience with it swooches straight past both C++ and C.

Re:There has been some good alternatives

[darcybrown]

Yawn. The 'Java is slow, obese and heavy' arguments are poor, out of date and largely inaccurate. Java's popularity on mobile phones suggests it is hardly a performance bottleneck, nor is it too demanding for memory. I understand you argument, but it sure doesn't apply to phones. Maybe for a simple Java business application, but thats about it. Find one book, one article about making apps on j2me that doesn't explain how to use obfuscation. Thats not because of all the pirates trying to steal your code, its because Java is big. In order to make a sophisticated app, you basically have to throw out everything you have come to love about Java to make it work on a phone, namely OO.... Its not the amount of code thats the problem, that's inheirent in any language, clearly. It's the fact that adding classes, or doing anything that the language is built for or suggests you do costs alot. The Jar footprint and class size comes straight from how many methods, variables, extends, implements, packages, etc.. You would crazy to try to run an app on a phone that have tons of getters and setters - classloader loads that and then whoop, there went 80% of your memory. For sophisticated apps, this makes Java on a phone is basically procedural code, large case statements, public variables for direct access and maybe 3 or 4 classes tops. At that point, I have a hard time calling it Java, but also at that point, its not obese. Its popular on phones because there are 2 options, that or BREW.

Re:There has been some good alternatives

[chez69]

with java you just use a good ide like eclipse that generates the getters/setters for you. that doesn't seem to hard to maintain

Re:There has been some good alternatives

[Anonymous Coward]

While I really doubt your claims I also hope they are true.

Re:There has been some good alternatives

[tacocat]

How the F!! can something like Java "swoosh" past C/C++?

I seriously doubt that your experiences are based on anything which does not include a heavy contribution of fine Ale.

If Java 1.5 swooshes then why not just write the entire OS in Java, or better yet, embed the Java Machine onto a chip! Oh wait... they tried that once.

Re:There has been some good alternatives

[Anonymous Coward]

But how many companies do you see requiruing wxWidgets experience?

How many companies do you see requiring JFC experience, or AWT experience, or SWT experience, or for loop experience, or Linked List experience?

Your employer doesn't care at all about the implementation details at this level.

Re:There has been some good alternatives

[KillerCow]

But what is true; c++ will always be faster than java

Ignoring arguments about programmer ability and design issues, that statement is not necessarily true. There are advantages to compiling an app to byte-code over machine code.

The byte-code can be recompiled to the machine code of the machine that it is running on at runtime to take advantages of the instruction set on that machine. The native compiled first code has to be compiled for the lowest common denominator of machines that it will be running on. If you want to run on most machines, you compile to a Pentium MMX (for example.) When the native code is run on a machine with SSE2 extensions, it still runs as MMX. The byte-code can be recompiled at runtime to use the SSE2.

The second advantage is that the statically compiled code is compiled with a static analyser, profiler and optimizer. The byte-code can be recompiled using a dynamic profiler and optimizer. So the machine code from the byte-code can be re-optimized to favour execution paths that are occurring at runtime, based on data collected at runtime.

Most of the "Java is too slow" arguments are based on observations from programmers who were using it in the 1.0 and 1.1 era, when there were performance problems and the optimizers weren't up to snuff. C# compiles to bytecode, and uses a similar basic class library, but you don't hear people crying "C# is too slow" from the hilltops.

Re:There has been some good alternatives

[LizardKing]

I guess you're referring to Gtk# as an alternative to Windows.Forms. That's not really going to help, as the majority of C#/.NET coding is going to be targetted primarily at Windows, where Gtk# is not going to be the first choice.

I did notice in the comments for the linked article, that Miguel mentions work is underway on Windows.Forms support for Mono. That would be quite an achievement, and one that would *really* make Mono a viable cross platform alternative to Java.

Re:There has been some good alternatives

[Anonymous Coward]

Your ignorance is amazing. Java from 1997 was slow; get in touch with the present times S**T FOR BRAINS.

Re:There has been some good alternatives

[Anonymous Coward]

"Java is slow, obeist, and heavy."

Recent benchmarks show that Java outperforms .Net on most of the tests and outperforms Mono on practically every test.

Google for it.

Re:There has been some good alternatives

[Anonymous Coward]

But how many companies do you see requiruing wxWidgets experience?

A lot fewer than I see unemployed Java programmers.

Re:There has been some good alternatives

[LeftOfCentre]

But what is true; c++ will always be faster than java, .Net might be (but thats because of the infamous shortcuts than only MS ppl know of)

Please elaborate on this. What are these shortcuts you speak of? How do you even know they exist?

Re:There has been some good alternatives

[daem0n1x]

Actually I prefer Java, because it's more simple. Most of the time, syntactic sugar just annoys me.
Of course I hate writing getters and setters. All the major IDEs do that for you. I haven't written a getter or setter in ages.

Re:There has been some good alternatives

[Anonymous Coward]

Uhh.... M-x jde-wiz-get-set-methods.

Re:There has been some good alternatives

[Anonymous Coward]

It outperforms mono..... So what? Mono's still a half-arsed incomplete implementation of .NET, its performance shouldn't even be a consideration yet.

Re:There has been some good alternatives

[iwadasn]

Is it really that hard to type the parrentheses?

The problem with properties (and granted, they do save you those two keystrokes for the parrentheses) is that you can't tell the difference between a member, and some arbitrarily complex block of code. Granted, if you made getters and setters for everything you'd have the same problem, but at least people would be reminded by the presence of the parentheses to maybe not call it over and over again in a tight loop if it can be helped.

Re:There has been some good alternatives

[Randolpho]

Well, for the most part, I agree. There are features in C# that are just unnecessary tack-ons. Most of those Java has actually picked up in 5.0 -- generics and autoboxing to name a few. One Java hasn't picked up (and one I hope Java *never* picks up, frankly) is delegates. I prefer Java's simpler interface-oriented means of generating callbacks.

In the case of properties syntax, I honestly prefer C#'s method. It's a much simpler means of organizing a property-oriented object (like a Bean).

Re:There has been some good alternatives

[Anonymous Coward]

should have used gqview

Re:There has been some good alternatives

[redsolo]

Yes, it is nice but there are some key properties that I dont get why they added those. About Exceptions, you can as an API maker easily force the API user to handle errors/exceptions when they occur in the API. In Java you will just add "throws YadaYadaException" and the API user must handle it. In .NET the developer can ignore it if he wants it, and it will probably have loads of troubles further down when they are trying to use API methods that are unavailable because of the state of the API. When you force the developer to handle exceptions, he/she will also think about the ramifications of the exception. Why did it occur, what should I do to clean up, was there something wrong in my call, etc? Letting the developer to produce sloppy code, will lead to *gasp* sloppy code.

Anyhow, hasnt development progressed since C's geterror() approach?

My suspicion is that they choosed to do this, so the VB developers wouldnt have to learn a new thing. WHy learn when you can stall?

BTW, try to have different access rights on Properties in .NET? If you have a property that has public get method, the set method must be public as well. Why put such a limit? I will stay with Get and Set methods...

Re:There has been some good alternatives

[Anonymous Coward]

Don't think WinForms is really that important since it's going away with Longhorn. Jump ahead to Avalon/XAML and you'll really have something.

Return of Java

[LizardKing]

It's strange how so many people say "Java is dying" or now that it patently isn't, they're saying "Java's back". If you go to any of the recruitment websites in the UK, the most popular requirement is Java Enterprise experience, hardly the mark of a development system that's been in decline ... The only explanations for this misrepresentation of Java that I encounter on sites like Slashdot and Linux Today is the following:

• A large part of the readership are students, and therefore don't really know what's going on in the software industry.
• The prepondereance of GNU fanboys means that Java gets dissed for not being Free(tm).

Discuss ...

Re:Return of Java

[Tim C]

You forgot a couple:

• despite entry level PCs now having specs along the lines of 2.5GHz processor and 256MB of RAM, lots of people on such sites are obssessed with perceived bloat
• lots of (but by no means all) people dissing Java are actually sysadmins, rather than programmers, and do all of the coding that they do do in perl, shell script, and similar

It always amuses me when I read "Java is teh suck because it's so slow and bloated!" comments. I've been doing server-side Java development for a little over 4 years now, and we've never had a performance problem. I use a number of client-side Java apps everyday, too, and they're perfectly responsive and usable. Sure, the same thing written in C or C++ probably would be faster - but when you literally can't tell the difference, who cares? A modern PC spends almost all its time waiting on user input or IO bound anyway.

Re:Return of Java

[LarsWestergren]

It's strange how so many people say "Java is dying" or now that it patently isn't, they're saying "Java's back".

I think a lot of the people who keep saying that Java is dying say it because they wish it was true.

And of course, if you keep repeating a lie often enough, the sheep begin to believe it. Just like on CNN, turn it on and watch a "reporter" frown in mock gravitas and ask things like "A lot of people are saying that the Kerry campaign is floundering and the Democrats are beginning to feel desperate, we ask the experts 'can anything be done, or is it already too late?'"

No one had said any of those things, but since CNN keeps saying that people say it, it becomes truth...

Re:Return of Java

[Anonymous Coward]

I wholehartedly agree. The amount of job offers for Java programmers is overwhelming. I focus primarily on programming Java now as an independent contractor. I run though lengthy contracts and get frequent calls for new assignments.

But there will always be a turf war. Everywhere I go it's the same thing: Java vs. Perl, Java vs. PHP, Java vs. Python, Java vs. C#... yet nobody seems the realise that you should select your language after understanding your requirements first. All of these languages have a place and time. Java is already very successful in the area of business automation applications, and more recently gained industry acceptance for embedded systems (Java phones). It is regaining ground again where desktop applications are concerned.

Trust me that this technology is very much alive. The improvements keep on coming, both in terms of speed and memory usage.

Re:Return of Java

[Anonymous Coward]

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

Plus Linux Fanboys and the fact that Sun was very late in getting a porting a working Java implementation to Linux. (2001?)

Plus the the fact that System V and Sun Solaris has always been GNU/Linux's Primary Target from a competitive standpoint.

Plus the UNIX Graybeard Taliban (young and old) who just want everything in C or maybe C++ and hate everything invented after 1985.

Re:Return of Java

[gnovos]

Sure, the same thing written in C or C++ probably would be faster - but when you literally can't tell the difference, who cares? A modern PC spends almost all its time waiting on user input or IO bound anyway.

For a long running enterprise application, it would probably be SLOWER in c/c++. No matter how good you are at programming c/c++ you can't anticipate every little bottleneck and write it in perfect assembler... but the hotspot compiler can do that rathar well.

Re:Return of Java

[Anonymous Coward]

I know of a company that bought 128MB RAM laptops for their field stuff and they can't use it because the Java application needs 130MB+ and starts to swap like crazy!! It's a simple Webbanking application.

Re:Return of Java

[16K Ram Pack]

Often, bloat just doesn't matter. It's something I wish most programmers would learn. Code has to run as fast as the job needs it to.

To generalise, a main functions of an online system needs to be optimised. But things like offline processing often doesn't. Higher priorities are maintainable and reliable code.

And what you say is right about IO. When I used to work on mainframes, our senior tech guy used to tell us to not worry about the code speed except for IO. PCs are heading that way.

Re:Return of Java

[latroM]

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.

Re:Return of Java

[droleary]

despite entry level PCs now having specs along the lines of 2.5GHz processor and 256MB of RAM, lots of people on such sites are obssessed with perceived bloat

That's a bad argument. Firstly, you can't claim the bloat is perceived if at the same time you list relatively hefty machine requirements. Computer resources are finite. Yeah, there are more now than before, but what does Java really give you that is worth tossing all your resources into a glorified emulator?

lots of (but by no means all) people dissing Java are actually sysadmins, rather than programmers, and do all of the coding that they do do in perl, shell script, and similar

As a programmer, I can tell you you're dead wrong. A developer with any depth will look at Java and then look at the languages before (and after) it and properly judge it on what new benefits it brings to the table. Java really brings nothing new or technically interesting; you've been duped the Sun marketing department.

A modern PC spends almost all its time waiting on user input or IO bound anyway.

And yet the user also spends almost all their time waiting for computer to operate on their input. It can't go both ways. The reality is that people do burst processing. When the user is sitting idle, the machine is usually sitting idle; when the user is doing something, the machine can't finish fast enough! For what it does, Java is still a big pig and the users know it. A developer that gives a damn about their users won't force them to use a Java app. Java is not "back" because it never fulfilled the promises it originally made.

Re:Return of Java

[isorox]

the most popular requirement is Java Enterprise experience

Yeah, and 15 years of it

Re:Return of Java

[Anonymous Coward]

Are we really supposed to feel sorry for this company that is too stupid to size their hardware to their application requirements? It's only another $50 or RAM or so.

Also, you won't be seeing me trying to run Mozilla or OpenOffice on a 128MB machine .. and those apps are C++, not Java.

Re:Return of Java

[Threni]

For a long running enterprise application, it would probably be SLOWER in c/c++. No matter how good you are at programming c/c++ you can't anticipate every little bottleneck and write it in perfect assembler... but the hotspot compiler can do that rathar well.

The optimizing compilers for modern C/C++ compilers are pretty good. Optimized native code is likely to beat Java's JIT compilation, or has this changed in the last couple of years? I've not been keeping up with Java, not having had any need for it, though I might do soon. Care to recommend a good Java book for experienced C/VB coders?

Re:Return of Java

[quigonn]

> but the hotspot compiler can do that rathar well.

Unless it shows some bugs on "obsure" platforms like AIX. A sequence of a.foo(); a.bar(); a.baz(); executed foo() and baz() but not bar(). It turned out to be a serious defect of the hotspot optimizer, which simply optimized away the call to bar(). Another bug was that sometimes, threads simply disappeared into nowhere. So, we decided that, instead of letting Java drop threads, we would drop Java on AIX.

Re:Return of Java

[ph1ll]

I just started working at a company where user Web sessions in Orion were reaching 1 MB each.

Further investigation revealed that the code sucked. It was nothing to do with Java. A re-write brought the Web sessions down to about 100 bytes each. It is now a happy app.

Moral of the story: there is good code and bad code in any language.

(Having said that, the JVM does take an awfully long time to bootstrap...)

:-P

Re:Return of Java

[MemoryDragon]

You cant even run a modern os with a decent gui on those machines... 128 MB gimme a break, have you seen the hardware requirements of modern applications. You can be glad if you can start windows on those machines.

Re:Return of Java

[Neo's Nemesis]

I toally agree. I have never heard that Java is dying. It is still a part of almost all the professional computer courses. And the best thing about Java is that its simple to understand, hence you can have groups of people to code the same branch. I have never heard from someone that Java is dying. Simply bcoz its widespread.

Other than that, what else do you have for the purpose? Phython, sure is language of hackers, but its not that easy to grasp it as whole, plus the lack of teachers for language. Other than that, Perl, which I have never seen mentioned as part of any course. So what would be the use when the fresh people out from college don't know single thing abt the language. To code massive programs, you need something thats already widely accepted and practiced.

One could start introducing the "new" languages as an experiment in college, and after that when it takes more space, and is widely documented, companies can start adopting it in huge projects.

Re:Return of Java

[mcbevin]

despite entry level PCs now having specs along the lines of 2.5GHz processor and 256MB of RAM, lots of people on such sites are obssessed with perceived bloat

Well 256MB of RAM is barely adequate for most Java apps or development in my experience.

I've been doing server-side Java development for a little over 4 years now, and we've never had a performance problem.

Geez. I guess you've never tried running a non-trivial web application on a webserver where your Tomcat only gets allocated 64mb RAM (and where every extra mb costs you $$$ per month). Admittedly the idea that Java is slow usually comes from people using Swing which isn't an issue for server-side applications.

Re:Return of Java

[Anonymous Coward]

For a long running enterprise application, it would probably be SLOWER in c/c++. No matter how good you are at programming c/c++ you can't anticipate every little bottleneck and write it in perfect assembler... but the hotspot compiler can do that rathar well.

In theory. In practice, while Java advocates have been making this claim for years, nobody has yet shown me a single piece of evidence that supports it.

Re:Return of Java

[mcbevin]

For a long running enterprise application, it would probably be SLOWER in c/c++. No matter how good you are at programming c/c++ you can't anticipate every little bottleneck and write it in perfect assembler... but the hotspot compiler can do that rathar well.

Sounds nice in theory. In practice for most Java enterprise applications the memory usage is by far the biggest bottleneck. The hotspot compiler can't change this.

For example, I did a fair few speed tests working with strings in Java. For example, comparing various search and replace algorithms. The entire difference between the faster algorithms and the slower ones was how they handled the memory usage.

Strings are only a simple construct, but even with these Java is horribly inefficient unless great care is taken by the programmer to use them efficiently. In contrast, when programming C++ I can use strings paying scant regard to efficiency and know my code will virtually always be faster than any Java program doing the same thing.

Re:Return of Java

[Anonymous Coward]

For a long running enterprise application, it would probably be SLOWER in c/c++. No matter how good you are at programming c/c++ you can't anticipate every little bottleneck and write it in perfect assembler... but the hotspot compiler can do that rathar well.

Your statement is as correct as saying that Java is slow.

Java is not slow, but it's slower than a good C++ code; consider these words from Stroustrup:

When you get to percents, 10%, 50%, and such, you start arguing whether efficiency matters, whether next year's machine will be the right solution rather than optimization. But in terms of dynamic versus static, we're talking factors: times 3, times 5, times 10, times 50. I think a fair bit about real-time problems that have to be done on big computers, where a factor of 10 or even a factor of 2 times is the difference between success and failure. (http://www.artima.com/intv/abstreffi2.html)

So yes, the average C++ programmer will write not the most efficient code (as Stroustrup compares differences in a factor of 50 between bad and good codes), and the Java's Hot Spot will then easily be faster than the average code. But remember that the Hot Spot can only guess what you are trying to accomplish; a C++ compiler can actually see what you are trying to accomplish. C++ compilers are not dumb, they can do really good optimizations (when you write good code, of course).

PS: using "C/C++" in a sentence comparing them to Java will make you look like you can't differentiate C from C++. Don't be so incautious unless you wanna be flamed by the "C++ is not the same as C" crowd.

Re:Return of Java

[Xyrus]

Java is fine as long as you use it for what it was defined for.

You probably wouldn't want to use it for high-performance graphics for example, but it's great for developing most standard apps.

If you really need to eek out the last nanosecond of performance, do not use java. Java will never be able to match the speed of writing to the metal. But I don't see why you wouldn't want to use it for a client-server app where nanosecond performance isn't critical.

Java is a programming tool just like any other. Only a fool throws out a tool merely on the basis of not knowing how to use it.

~X~

Re:Return of Java

[Spoing]

You forgot;

With Microsoft pushing .Net/c#/..., Java is doomed.

Not that I believe that...though that's a popular idea since with .Net/c#/... being funded so heavily by Microsoft in schools so that's all the new people see or hear.

Re:Return of Java

[Anonymous Coward]

Bruce Eckel's "Thinking in Java". You can download it from mindview.net (I think that is the site).

Re:Return of Java

[Paradise Pete]

I've been doing server-side Java development for a little over 4 years now

See. that's the thing. If you'd have used perl you'd have finished in less than three.

Re:Return of Java

[Glock27]

Strings are only a simple construct, but even with these Java is horribly inefficient unless great care is taken by the programmer to use them efficiently. In contrast, when programming C++ I can use strings paying scant regard to efficiency and know my code will virtually always be faster than any Java program doing the same thing.

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, 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:Return of Java

[Paradise Pete]

I know of a company that bought 128MB RAM laptops for their field stuff and they can't use it

I'd say that company has more problems than just Java.

Re:Return of Java

[Xugumad]

I have to disagree here. There are certainly cases where Java is faster, but they're relatively few. Lets just go through that infamous benchmark again:

Java faster than C++ benchmark

Point 1 - "I was sick of hearing people say Java was slow, when I know it's pretty fast".
Baaaad start to any analysis - always keep an open mind about the results.

Point 2 - He used G++. So this is only valid for G++, not necessarily any other C++ compiler. Which is fair, I just feel this is worth emphasising.

Point 3 - It's rapidly determined that G++ takes much longer to execute a method call, than Java does. Given this, it shouldn't be a significant suprise that benchmarks relying heavily on recursion will be slow in C++.

For example, rewriting the Fibonnaci benchmark to use a for loop instead of recursion give a 600-times speed increase:

http://developers.slashdot.org/comments.pl?sid=111 205&cid=9436176

Rewriting it into constant-space gave an almost 10 times increase over that:

http://developers.slashdot.org/comments.pl?sid=111 205&pid=9438782#9439949

Moral of the story? Java is great for method calls , but I'm not so convinced about everything else...

Re:Return of Java

[Saint Stephen]

I find the GLib class libraries with their implementations of hashtables, safe strings, auto-growing arrays, data sets, and memory chunks to be more than sufficient for "safe, don't fuck it up, poindexter" programming that makes most people feel safe in Java, but lets me get all the C goodness as well, for client apps. Not to mention GTK.

It's pretty hard to beat glib+gtk in C for client apps. It's the new VB.

Re:Return of Java

[bkocik]

lots of (but by no means all) people dissing Java are actually sysadmins, rather than programmers, and do all of the coding that they do do in perl, shell script, and similar

I think you've nailed an important point. I went from SA, to engineer, to SA, back to engineer (long story). Net result is that I spent a lot of time as an SA who knew how to write Java code (along with other languages), working amongst other SA's who really didn't have a clue about development. That's not to say that they were dumb; on the contrary, these were very talented people. But in general it's not an SA's job to know the ins and outs of higher languages, so for the most part, they didn't.

Every time the word "Java" was mentioned, many of them would wrinkle their noses, and regurgitate the same tired stereotypes, accurate or not. For a while I began to wonder if it was an autonomous thing with them, like your heartbeat or the functioning of your thyroid gland. Although I have to admit that some complaints are valid, or at least used to be, mostly what they said only exposed their own lack of understanding. Eventually you learn to stop arguing with them, and instead just employ the smile-and-nod approach.

They also bagged on me (good naturedly, I think) for writing stuff in Java. I responded by calling them "knuckle-dragging Perl programmers". I was quite popular. =)

Re:Return of Java

[Glock27]

You probably wouldn't want to use it for high-performance graphics for example, but it's great for developing most standard apps.

If you really need to eek out the last nanosecond of performance, do not use java. Java will never be able to match the speed of writing to the metal.

Yah, just like one wouldn't want to use a platform-independent lib like OpenGL to write high-performance graphics, you'd want to go straight to the metal...oh wait... (You should take a look at JOGL by the way.)

In the same vein, one would never want to use C++ for high-performance code, one would rather write straight C, or better yet assembler...ooops...

Your argument has two fallacies - one is that Java can never be as fast as C or FORTRAN (not true).

The second is that it is worth any amount of effort to pry the last few percent of performance out of a system (not true either, unless said lack of performance is a fatal error, i.e. hard realtime).

Hope that helped...

Re:Return of Java

[Anonymous Coward]

As a programmer, I can tell you you're dead wrong.

Well you know most of the people writing in Java are programmers too.

Re:Return of Java

[aaronl]

What is with you people? NO, IT IS NOT SLOWER IN C/C++. You are running code through a glorified interpreter running through an emulated codepath, all of which is written in C/C++. Java always will be slower, because it's always more steps from the hardware and always running in a VM.

Java code just isn't the hideously slow crap it was when it first because popular. Once the VM is up, it runs quite snappy save for some of the older and trashier widget toolkits. BUT, it still takes some time to load the VM on my 2GHz+ machine, and still takes too much memory (>16MB for the VM), and that's still no good.

The C/C++ code you've worked with is either just plain bad, or you don't know what to look for. I can always optimize my code to be faster than equivalent Java.

Write your Java code because it's the best choice, not because for the sake of being a language bigot. Java has it's uses, C/C++ has it's uses, and so does Assembly.

Re:Return of Java

[LizardKing]

I have to second your enthusiasm for the Glib library. On the one occasion that I haven't been able to shoehorn a JVM onto an emebedded PC, I used Glib and GTK+ instead. This was a crane controller with a touchscreen, and the app had to fit (along with a stripped down Linux distro) into 32Mb of flash RAM. As well as GTK+, I also got ORBit onto the machine, which meant I was able to duplicate pretty much everything I'd have done in Java. I did have to write a C replacement for Java's resource bundles, but that was no great hardship.

Re:Return of Java

[CaptnMArk]

In batch processing this is all true.

In interactive/desktop/realtime systems it is not.

It's just like bandwidth vs. latency.

Re:Return of Java

[Fweeky]

"Higher priorities are maintainable and reliable code."

Which is why so many people develop with dynamic languages. Bloat isn't just at the runtime side of things; it's at development time too.

Re:Return of Java

[YetAnotherAnonymousC]

Geez. I guess you've never tried running a non-trivial web application on a webserver where your Tomcat only gets allocated 64mb RAM (and where every extra mb costs you $$$ per month). Admittedly the idea that Java is slow usually comes from people using Swing which isn't an issue for server-side applications.

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:Return of Java

[Tim C]

Geez. I guess you've never tried running a non-trivial web application on a webserver where your Tomcat only gets allocated 64mb RAM (and where every extra mb costs you $$$ per month).

No, I haven't - why would I? The company I work for charges by the box, not the megabyte. If a client buys a server, that's exactly what they get.

If RAM was really that tight, then I'd look at using something other than Java if possible (I've done web development in C, C++, perl and ASP as well); the right tool for the right job, and all that.

Re:Return of Java

[mcbevin]

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.

Exactly. I've read Joshua Bloch's book and his justification for making strings immutable makes some sense, but if every speed conscious program has to avoid them then you have to wonder. Interesting however that this FastString you mention is also somehow immutable.

An interesting performance enhancer worth looking into is JADE, 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

That actually looks worth trying out thanks.

Re:Return of Java

[j3110]

If you want to go back to "char*", no one is stopping you. "char string[]=new char[80];" works just fine. Then you can convert to a String, put it in a StringBuffer, or use low-level array copying (array copy functions in System).

I think the other classes cover all the common cases though. Don't build everything in Strings when you are getting ready to put it on the network! Use a BufferedOutputStream and let Java handle it, and dont do stuff like:

out.writeln("Cheese is "+ (good?"good":"bad")+"!");

Doesn't it just make more sense to:

out.write("Cheese is ");
out.write((good?"good":"bad");
out.write("!\ n");

My point being that concatonating strings with + forces the creation of a StringBuffer, which is useless considering that the output stream is buffered.

That's just my pet peeve on poor String usage in Java. There are easily 20 silly things that the average programmer will do when not thinking. The String API isn't too shabby. It's much better than being forced into writting your own routines, or having to include 3rd party libraries to achieve the desired effect, which is the case with most compiled languages.

Re:Return of Java

[Xyrus]

OpenGL and other graphics api's are what I was refering to, i.e I never said write to the metal doing modern PC graphics. On consoles, possibly but you have to weigh the costs of doing so. Writing to the metal with modern graphics cards is difficult if not impossible due to the lack of low-level docs. I have looked at JOGL, and many other GL to java bindings in the past. The fundamental problem with these are that they are what the are: Bindings. Underneath they are still using a JNI bridge to the native DLL which carries a not-so-insignificant overhead. I've had to deal with JNI performance issues on several projects. But you don't need to take my word for it, there is plenty of information regarding JNI and performance on the web. You're also taking my words out of context. There is a trade-off for speed vs. maintainability. In most cases, you can write a good 90% of your project using C++/Java/C#/ whatever because objects like GUI interfaces aren't usually speed critical. I'm refering to the last 10% that usually is speed critical. RTOS's and 3-D games have such "performance-critical" components and in that case you want native speed. So to counter your two arguments. 1. An INTERPERATED instruction will never match the speed of a machine code instruction on a PC, unless there is a hardware JVM. Therefore, in raw cycles, the same code written in java will be slower than the equivalent code in a compiled language. With JIT, some code may perform at the same level, but overall the compiled language will always get ahead. In most cases though, no one is going to notice a millisecond of difference. 2. There are a number of instances where you do want every last cycle of performance. RTOS's, video games (console and PC), video card drivers (in fact, just about any hardware drivers), satellite communication software, space probes, guidance systems, flight navigational systems, etc. etc. etc. . Direct access to hardware is not one of Java's strong suits. I'm not saying java is a slow bloated pile. I've used java many times in projects. It does have it's place, especially if you need to run the same program on various OS's. I've found it quite useful, and the mass of libraries out there make it very convenient for prototyping. For a large portion of projects, java is just as good (and in some cases better) than any language. But like all tools, it has it's advantages and disadvantages. Java has its place, but there are certain projects I would not use it for. There are reasons why Doom 3 was not written in java. ~X~

Re:Return of Java

[Tim C]

Firstly, you can't claim the bloat is perceived if at the same time you list relatively hefty machine requirements.

I didn't list requirements, I listed typical specs of an entry level machine. By which, I mean the sort of machine that you can walk into a high street shop and buy off the shelf, spending relatively little compared to the price of the computers on offer.

I've done web-based Java development using JBuilder on a 400MHz machine with 512meg of RAM. It was slow, but doable, and that includes running the servlet container (resin).

Java really brings nothing new or technically interesting; you've been duped the Sun marketing department.

Clearly your experience differs from mine. I came to Java from C/C++. What Java gave me over my previous environment was a proper IDE, interactive debugging, much reduced compile times, no complicated makefiles, etc. The first project I used it on quite literally would not have gone live on time had we done it in C++.

Now, sure, none of that is unique to Java or necessarily missing from C/C++, but my current preference for Java is based on my experience, not on anything Sun's marketing department may have spewed out.

Re:Return of Java

[16K Ram Pack]

dynamic languages? I've not heard the expression before, so you could you name some?

Re:Return of Java

[Chanc_Gorkon]

Java is still bloated. Case in point....take simple contact logging program I have on my Mac called jLog. Whenever that program or any Java program for that matter runs on my Mac, the CPU is maxed out the whole time until I quit the Java Application. Now this just may be Apple's implementation sucking, but for a simple app like jLog, it should not spike the CPU like that. I just checked and it appears that that bug has been squished, but it was like that for a long time.

At work, I have a few Java apps that I need to run to do my job. Each of them requires a different JRE. I had to have 3 JRE's installed jsut so I could use all the apps. That's unacceptable. Sun or IBM or someone needs to make a jre that will run them all so to speak.

With all that said, I still think Java is pretty damn cool in what it can do. It's not the run everywhere panacea that SUn made it out to be though. It can run almost everywhere though and that is the cool thing. It IS getting better which is why I think some people say it is coming back although web game players like my brother will say it has not gone anywhere as game desingers have been writing gams in Java all along.

Re:Return of Java

[Threni]

> Bruce Eckel's "Thinking in Java". You can download it from mindview.net (I
> think that is the site).

Cheers!

Re:Return of Java

[j3110]

And you just tell me what kind of graphical development environment works better in 256M of ram. X+Gnome+Daemons+kernel eat up most of my memory. I've done tests limiting Eclipse's memory with -Xmx. You can usually get it to run in 5M. AIM uses more memory than that, and Eclipse is an IDE. Set up the VM properly. JNLP/WebStart has tags for this. Most of the VM gets put in swap after JIT, which leaves pretty much only the heap and code to consume memory.

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:Return of Java

[StarfishOne]

If you'd used Python you'd have finished in less than three months ;o)

Re:Return of Java

[Matt Perry]

if you keep repeating a lie often enough, the sheep begin to believe it

That's like when people use a push poll to change public opinion.

Re:Return of Java

[Anonymous Coward]

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.

Until GNU Classpath is complete, the Java standard is *not* free.

In order to really be a Java "implementation", you need all the runtime classes (java.awt.*, java.io.*, etc.) in java.* . Most enterprise Java developers will also need the runtime classes in javax.* to meet the J2EE specification.

Remember, the Java runtime is both the JVM and the classes/interfaces. The former has been freed, the latter is only about half done.

Re:Return of Java

[gnu-generation-one]

Judging java by it's cover:

"So far, Java seems like a stinker to me. I've never written a Java program, never more than glanced over reference books about it, but I have a hunch that it won't be a very successful language. I may turn out to be mistaken; making predictions about technology is a dangerous business. But for what it's worth, as a sort of time capsule, here's why I don't like the look of Java:

"1. It has been so energetically hyped. Real standards don't have to be promoted. No one had to promote C, or Unix, or HTML. A real standard tends to be already established by the time most people hear about it. On the hacker radar screen, Perl is as big as Java, or bigger, just on the strength of its own merits.

"2. It's aimed low. In the original Java white paper, Gosling explicitly says Java was designed not to be too difficult for programmers used to C. It was designed to be another C++: C plus a few ideas taken from more advanced languages. Like the creators of sitcoms or junk food or package tours, Java's designers were consciously designing a product for people not as smart as them. Historically, languages designed for other people to use have been bad: Cobol, PL/I, Pascal, Ada, C++. The good languages have been those that were designed for their own creators: C, Perl, Smalltalk, Lisp.

"3. It has ulterior motives. Someone once said that the world would be a better place if people only wrote books because they had something to say, rather than because they wanted to write a book. Likewise, the reason we hear about Java all the time is not because it has something to say about programming languages. We hear about Java as part of a plan by Sun to undermine Microsoft.

"4. No one loves it. C, Perl, Python, Smalltalk, and Lisp programmers love their languages. I've never heard anyone say that they loved Java.

"5. People are forced to use it. A lot of the people I know using Java are using it because they feel they have to. Either it's something they felt they had to do to get funded, or something they thought customers would want, or something they were told to do by management. These are smart people; if the technology was good, they'd have used it voluntarily.

"6. It has too many cooks. The best programming languages have been developed by small groups. Java seems to be run by a committee. If it turns out to be a good language, it will be the first time in history that a committee has designed a good language.

"7. It's bureaucratic. From what little I know about Java, there seem to be a lot of protocols for doing things. Really good languages aren't like that. They let you do what you want and get out of the way.

"8. It's pseudo-hip. Sun now pretends that Java is a grassroots, open-source language effort like Perl or Python. This one just happens to be controlled by a giant company. So the language is likely to have the same drab clunkiness as anything else that comes out of a big company.

"9. It's designed for large organizations. Large organizations have different aims from hackers. They want languages that are (believed to be) suitable for use by large teams of mediocre programmers-- languages with features that, like the speed limiters in U-Haul trucks, prevent fools from doing too much damage. Hackers don't like a language that talks down to them. Hackers just want power. Historically, languages designed for large organizations (PL/I, Ada) have lost, while hacker languages (C, Perl) have won. The reason: today's teenage hacker is tomorrow's CTO.

"10. The wrong people like it. The programmers I admire most are not, on the whole, captivated by Java. Who does like Java? Suits, who don't know one language from another, but know that they keep hearing about Java in the press; programmers at big companies, who are amazed to find that there is something even better than C++; and plug-and-chug undergrads, who are ready to like anything that might get them a job (will this be on the test?). These people's opin

Re:Return of Java

[Glock27]

OpenGL and other graphics api's are what I was refering to, i.e I never said write to the metal doing modern PC graphics.

Right. What you did say is that for "writing to the metal" you wouldn't use Java since it (presumably) isn't efficient enough due to its higher abstraction and cross-platform nature. My point is that OpenGL is also more abstract and cross-platform than "writing to the metal", but it is widely accepted as "good enough" performance wise, and of course the advantages of being card and platform independent outweigh the small performance advantage you'd gain "writing to the metal" anyhow.

This is analogous to the issue of whether "Java inneficiencies" outweigh the advantages it provides.

On consoles, possibly but you have to weigh the costs of doing so. Writing to the metal with modern graphics cards is difficult if not impossible due to the lack of low-level docs.

To be fair, the cards are designed so that OpenGL maps well to the underlying hardware. The idea of OpenGL is to provide a very thin API layer over the underlying hardware.

I have looked at JOGL, and many other GL to java bindings in the past. The fundamental problem with these are that they are what the are: Bindings. Underneath they are still using a JNI bridge to the native DLL which carries a not-so-insignificant overhead. I've had to deal with JNI performance issues on several projects. But you don't need to take my word for it, there is plenty of information regarding JNI and performance on the web.

There are altenatives, such as CNI in gcj (very little more overhead than a C to C call). There is an effort underway right now to port JOGL to gcj. That should be quite interesting, and I personally plan to use it for game development.

You're also taking my words out of context. There is a trade-off for speed vs. maintainability.

Not necessarily. Look at Ada, for instance. It produces very fast, yet very maintainable code. Again, to be fair, Ada provided easy access "to the metal". It is kind of sad that for all intents and purposes, Ada is dead - though it was also kind of ugly and cumbersome. ;-)

In most cases, you can write a good 90% of your project using C++/Java/C#/ whatever because objects like GUI interfaces aren't usually speed critical. I'm refering to the last 10% that usually is speed critical. RTOS's and 3-D games have such "performance-critical" components and in that case you want native speed. So to counter your two arguments. 1. An INTERPERATED instruction will never match the speed of a machine code instruction on a PC, unless there is a hardware JVM. Therefore, in raw cycles, the same code written in java will be slower than the equivalent code in a compiled language.

Java can be natively compiled. See my other posts regarding gcj, TowerJ, Jet etc. So the entire interpreted vs. compiled argument is moot. I won't argue that the VMs can be as fast (though I'm also not convinced they can't) because I don't like the non-determinism of adaptive compilation in soft or hard realtime settings.

With JIT, some code may perform at the same level, but overall the compiled language will always get ahead. In most cases though, no one is going to notice a millisecond of difference. 2. There are a number of instances where you do want every last cycle of performance. RTOS's, video games (console and PC), video card drivers (in fact, just about any hardware drivers), satellite communication software, space probes, guidance systems, flight navigational systems, etc. etc. etc.

There is quite a bit of activity in the hard realtime Java area. Do some searching.

Direct access to hardware is not one of Java's strong suits.

Direct access to hardware isn't necessary, just an efficient C calling mechanism, for instance CNI.

I'm not saying java is a slow bloated pile. I've used java many times in projects. It does have it's place, especially if you need to run the same

Re:Return of Java

[ratboy666]

Um... no, the C/C++ (and, yes, I am combining them -- I mean "lower level language/intermediate language that translates to machine code") does NOT see what your program is doing. It can only guess.

On the other hand, a re-compiler can watch what is happening, and generate better code.

As an example:

if (condition) { ...simple code...
} ... more code...

When compiled, I cannot tell C (or C++) that "condition" is an error that will occur.. well, should never occur..

So, the optimal sequence would be: ...evaluate condition ...branch if true to exception ...more code

Now, if the "simple code" is small, it may be part of the same cache-line occupied by the condition. Wasting resources.

A re-compiler could tell that this is happening (hey, "condition" hasn't been true for the last 100K iterations! let's optimize for that case!).

This is only a small example; I am sure that you can come up with your own.

Ratboy.

Re:Return of Java

[angel'o'sphere]

Optimized native code is likely to beat Java's JIT compilation, or has this changed in the last couple of years?


Yes, it has changed some yeas ago :D google for Hot Spot or dynamic jit compilation ... plenty of research from SUN and HP on that topic.

On any modern hardware a solid Java server program (lots of IO, DB access and network access with 1000nds of users) will outperform a similar solid C++ solution.

You have to chose perfect suiting examples (like array/matrix multiplications) to find areas where C++ etc. have a clear advantage.

angel'o'sphere

Re:Return of Java

[mcbevin]

And you just tell me what kind of graphical development environment works better in 256M of ram.

Visual Studio .NET for one.

I've done tests limiting Eclipse's memory with -Xmx. You can usually get it to run in 5M.

You can't be serious. It uses 100-200mb after I start it, open a decent sized project, and write say one line of code to get the code completion stuff all loaded into memory. This then just typically continually increases with every ant build until it throws an out-of-memory error at some point. If I were to tweak its startup parameters to use anything less that 128mb it would likely throw that out-of-memory error before it could even load the project.

If you're restricted to 64M, your hosting solution is obviously for trivial web applications.

The point is, 64M should also be sufficient for non-trivial websites. Theres some pretty non-trivial PHP websites which don't get near 64M memory usage (for that reason, hosts don't typically restrict memory usage for PHP-based sites).

Re:Return of Java

[Anonymous Coward]

I think a good compiler would be able to transform your "bad" code example into the "right" example but Java compilers are known to be flakey. Kind of interesting that C and C++ don't have that problem.

Re:Return of Java

[Anonymous Coward]

First of all, I can write a recursive fibonnaci function in C++ that essentially has no runtime cost.

Second of all, there is a closed form to fibonnaci numbers so any recursive function used to compute fibonnaci numbers is either a meaningless benchmark or something that should be frowned upon.

Re:Return of Java

[mcbevin]

The point is that in C++ and most other languages I can use the standard string class quite happily and its efficient and does all I need. In Java this simply isn't the case.

Isn't it rather pathetic that something like your example of

out.writeln("Cheese is "+good?"good":"bad")+"!");

is a 'bad thing' to do in Java? Personally I find it the natural way to do things, and much nicer than your second example. I hardly think I'm alone in this. Virtually all languages use the former idiom as opposed to the latter (or have an even nicer syntax). If you find the former not nice, I could suggest:

String cheeseType = (good?"good":"bad);
out.writeln("Cheese is " + cheeseType + "\n");

The String API isn't too shabby. It's much better than being forced into writting your own routines, or having to include 3rd party libraries to achieve the desired effect, which is the case with most compiled languages.

Huh???? C# provides a nice string class. So does C++. They're essentially Java's competitors, so no idea where you're coming from there.

Re:Return of Java

[Anonymous Coward]

I just don't see when Java is the best choice. The only time you could argue for Java is when a portability is a must and people are starting to realize that Java's portability claims are not entirely true. What does Java offer that C++ really does not? To a real programmer nothing.

Re:Return of Java

[Anonymous Coward]

"lots of (but by no means all) people dissing Java are actually sysadmins, rather than programmers, and do all of the coding that they do do in perl, shell script, and similar"

Agreed. Most of the people I know that are against Java are all system admins who only write simple shell scripts and simple perl scripts. They have absolutely no clue on how to make an enterprise level application and since Java is hard for them to understand they hate it. They are truly clueless and useless in terms of programming knowledge. Furthermore, like Paul Graham, they have never actually sat down and learned the language.

Re:Return of Java

[Torne]

Java can, in some conditions, be *faster* than compiled native code because of optimisations that can only be performed at runtime (insufficient information available at compile-time). Nothing I use that's written in Java runs slower than equivalent native-code software (and I'm talking about total CPU cycles used, not perceived user speeds). The fantastic optimisation abililities of HotSpot do come at a significant cost in memory and a small cost in startup time, but I only start my IDE once a day and have six gigabytes of ram, so it doesn't bother me. =)

Java runs fine on my cellphone with 4MB of memory too, and is still speedy enough not to seem any slower than native Symbian apps.

Re:Return of Java

[Threni]

> You have to chose perfect suiting examples (like array/matrix multiplications)
> to find areas where C++ etc. have a clear advantage.

You have a point - that'll be my game coding background then (Games in Java are a joke, though pleasantly cross-platform) I've not done any internet coding.

Re:Return of Java

[Anonymous Coward]

For a long running enterprise application, it would probably be SLOWER in c/c++. No matter how good you are at programming c/c++ you can't anticipate every little bottleneck and write it in perfect assembler... but the hotspot compiler can do that rathar well.

That's what profiling is for. Anyway if this were true, Transmeta would be the speed king. Still waiting on that one.

Writing in assembly is not usually the correct optimization any more. Usually all you can do is to improve the algorithm. The easiest method is to find out what's taking the most time and do less of it. Trying to figure out the best way to do it in assembly by hand given all the complexities of modern architecture is not an easy task at all.

With profile guided optimization (supposedly to become available in MS's compilers next year), the compiler can choose between different representations along the size-speed tradeoff line, which gives you another layer of goodness.

Re:Return of Java

[Anonymous Coward]

Usually all you can do is to improve the algorithm. The easiest method is to find out what's taking the most time and do less of it.

Oh, and btw, let's see how your hotspot compiler does there. If it can redesign your algorithm then I guess programming is gonna be a pretty worthless skill before long.

Re:Return of Java

[j3110]

If you're just doing the stuff typically done with PHP, you aren't ever going to need more than 64M. The problem comes in when you are like me, with Gigabytes of data in tables, and there is no way of setting up any key on a table that can help, you can at least keep around common information in memory. Or if you are generating charts/graphics on the fly, you'll probably want to keep those around too. If all you are doing is querying a DB and returning HTML, you are never going to need more than the 64M that you'll get. In fact, you should be fine in probably 8-16 depending on how large your query results are and if you are running any kind of persistance layer other than JDBC. For the same features, Java isn't going to consume much more memory than PHP. You may want to check out something like Jetty. The advantages you get are complete user/process isolation (IE security and stability). That's going to cost you in memory, because you need several copies of libraries and VMs open. That's why people don't bill you on PHP memory usage, because it's not possible to isolate your runtime without you running apache yourself. You go run your local copy of Apache and PHP to isolate yourself from other users, then come back to complain on a level playing field.

Eclipse will run just fine on 32M, with all the completion loaded on any pretty much any sized project. Eclipse seems to have memory management built in. When I run out of memory, it tries to unload editor pages and perspectives that aren't being actively used. You can run ANT externally if you think there is a memory leak, but I've had Eclipse open for weeks on the default setting. Several builds, about 50+ edited files, CVS sync every few hours, and debugging. WebSphere Studio is pretty bad because it runs WebSphere right in the same VM, and that eats up the memory fast.

I have VS.Net installed, and it's definately slow on my computer in comparison with Eclipse. Eclipse has a little longer start-up time, but after it's loaded, I can create projects, compile, test, etc. very snappy. Eclipse indexes every single file you have, and parses them in real time. It compiles on save. VS.Net requires you to actually build the "solution" every time, and it still doesn't feel as quick doing general editing.

By default, the last time I checked, all Java applications are restricted to a 64M heap. All the java objects in Eclipse fit into 64M. Anything more than that is probably going to be JIT compiled code and the VM.

Re:Return of Java

[Anonymous Coward]

No one had said any of those things, but since CNN keeps saying that people say it, it becomes truth.

I believe that you're refering to FOX.

Re:Return of Java

[j3110]

Well... the C++ way to have done it would have been:

out "Cheese is "(good?"good":"bad")"!"endl;

Which would be like the second. If you are doing:

CString cs=new CString("Cheese is ");
CString goodcs=new CString("good");
CString badcs=new CString("bad");
CString exclimation=new CString("!\n");

out cs+(good?goodcs:badcs)+exclimation; ... then you deserve to be shot anyhow. I think it's nice that Java's String class is integrated directly into the language, not the more arcaic char* format.

Use streams the way they were intended to be used. You can equally screw up any language's strings. Just because "a"+"b" works in Java, or any other language, doesn't mean you should do it. If you are using JSP, the correct form is done for you.

It seems to me that you are looking for a Holy Grail String class, which to me, is a very bad idea. Small classes that do only what they have to is a pretty common quality amongst well designed systems. Knowing which class to use and how to use it is very basic knowledge about a language. If you want to complain about Java's syntax, feel free to. I'm all about that. There's a lot of things I would like to go back and change about Java's syntax, I wished it was more like Python, but instead, it was based on C++, because that was what was popular at the time. I also would like to see the GUI handled as an abstract model, like XUL, that could be altered with DOM in realtime, and used message passing for events, thus removing all the whole threading and layout issues that we have now. (If anyone is up for creating the second, I'm willing to dedicate some time to it.)

My theory is that people complain about how the Strings in Java aren't "intuitive" because they are too lazy to learn the language, and they can't very well say "Java has too rich of a class library". It's very unlike C/C++ in that it actually comes with all the functions you usually have to have libraries for. Java's 16M JRE probably comes with more functionality than your 200M /usr/lib.

Re:Return of Java

[Javagator]

What does Java offer that C++ really does not?

I program in C++ at work and do some recreational programming at home (yes, I'm a dork). At home I develop in Java on Linux. Why? Java offers a huge, integrated, well documented class library that saves me months of mundane programming. Also, I occasionally develop something that I want to run in the windows environment. On rare occasions I have had to tweak a GUI component, but basically Java ports with no effort. Not even a recompile. I pay about a 30% performance penalty for using Java (IBM's JVM) rather than using g++, but I can live with that.

Java is not the best choice for every situation, but in some instances it does make sense.

Re:Return of Java

[coopaq]

I believe that you're refering to FOX.

I'll back this up. It's FOX News that says Kerry's campaign is floundering.

But it's it's CNN who keep talking about doing all of there programming in Java... oh wait... that's a different kind of programming :)

Re:Return of Java

[clambake]

The optimizing compilers for modern C/C++ compilers are pretty good. Optimized native code is likely to beat Java's JIT compilation, or has this changed in the last couple of years?

I'm not up on optomizing C compilers, so I don't know if what I am about to say is completely true... The difference between c++ and Java optomozation is that in c++ it all has to happen based on what you THINK will be bottlenecks, since it's all compiled in from the get-go. In the HotSpot case, new execution code can be dumped in place as it is running, even going so far as unrolling a loop midway through it's operation, replacing bits and pieces exactly when they become bottlenecks.

However, you don't really get to see the speed unless your application is a fairly long-running thing, like most enterprise applications. It will be able to maximally compile down all the hot spots into assembly and has the option to recompile them in different ways if the needs of the system change.

Re:Return of Java

[clambake]

Java always will be slower, because it's always more steps from the hardware and always running in a VM.

You don't understand what the hotspot compiler does... when it sees a bottleneck it recompiled the code into NATIVE machine code. It's as close to the hardware as you can get at that point. And since the hotspot compiler can see all the bottlenecks, no matter how obscure it is in code, it's going to be faster in many cases.

Re:Return of Java

[Anonymous Coward]

Usually all you can do is to improve the algorithm. The easiest method is to find out what's taking the most time and do less of it.

Oh, and btw, let's see how your hotspot compiler does there. If it can redesign your algorithm then I guess programming is gonna be a pretty worthless skill before long.

From what I have read, it's getting closer and closer to this. It watches how bits of code run and watches teh result, and if it sees there is only a set number of paths that the application can go through, it'll optomize away everything not being used.

Re:Return of Java

[clambake]

But remember that the Hot Spot can only guess what you are trying to accomplish; a C++ compiler can actually see what you are trying to accomplish. C++ compilers are not dumb, they can do really good optimizations (when you write good code, of course).

Actually, it's quite the opposite. A c++ compiler can't know exactly how a system will react in real life. Imagine you have some input from a user that decides code paths. How will the c++ optomizer know that users will pick option B 99% of the time and optomize that section first? Hotspot can watch the code as it runs and watch what it's doing and decide which pieces to optomize based on where the problem areas are.

Re:Return of Java

[MarkCollette]

So far, Java seems like a stinker to me. I've never written a Java program, never more than glanced over reference books about it, but I have a hunch that it won't be a very successful language. I may turn out to be mistaken; making predictions about technology is a dangerous business. But for what it's worth, as a sort of time capsule, here's why I don't like the look of Java:

Err, it already is very successful. The real question is, how successful will it be in two or three decades.

1. It has been so energetically hyped. Real standards don't have to be promoted. No one had to promote C, or Unix, or HTML. A real standard tends to be already established by the time most people hear about it. On the hacker radar screen, Perl is as big as Java, or bigger, just on the strength of its own merits.

C, UNIX and HTML became so popular due to their low cost, ie some implementations being free. Sun probably was hoping to make some money off of it, and so felt some marketing was in order. Plus, since they're up against Microsoft, I'm sure they preferred overkill to underkill.

2. It's aimed low. In the original Java white paper, Gosling explicitly says Java was designed not to be too difficult for programmers used to C. It was designed to be another C++: C plus a few ideas taken from more advanced languages. Like the creators of sitcoms or junk food or package tours, Java's designers were consciously designing a product for people not as smart as them. Historically, languages designed for other people to use have been bad: Cobol, PL/I, Pascal, Ada, C++. The good languages have been those that were designed for their own creators: C, Perl, Smalltalk, Lisp.

I agree. But, I think you're use of the word "good" is misplaced. All of those "good" languages have proven themselves useful to the advanced programmers, and dangerous to the, shall we say, introductory level programmers. To me, how good a language is, depends on its theoretical capabilities, such as the potential is has for usefulness, as well as its emperically expressed capabilities, such as how people actually use it. If an elite cabal of programmers can spin webs of logic with magic language X, yet the average programmer can only crash busloads of screaming people into their doom with language X, then I'd say their damn sure is a market for language Y which is aimed at these regular programmers.

I can't count the hours of my life I've lost to debugging programs others wrote in C++, where they've hung themselves from the tallest tree, but those same people have made no such mistakes in their Java programs.

So, since most programs are made by the less skilled, then something that gives them the capability to work without error, is "gooder", in my opinion.

3. It has ulterior motives. Someone once said that the world would be a better place if people only wrote books because they had something to say, rather than because they wanted to write a book. Likewise, the reason we hear about Java all the time is not because it has something to say about programming languages. We hear about Java as part of a plan by Sun to undermine Microsoft.

Yes, the real world has politics. Ideas flourish or fail, irregardless of their technical merits, due to the corrupting nature of politics. But since everything is touched by politics, it's not really a reason to be against something, merely because some side is overt in its politics.

4. No one loves it. C, Perl, Python, Smalltalk, and Lisp programmers love their languages. I've never heard anyone say that they loved Java.

I love Java :) I'd prefer programmers to adhere to the best tool for the job mentality, rather than some blind love for their perceived one hammer fits all language.

One thing I do know, is that I hate weakly typed languages, which covers most of the "loved" languages you list.

5. People are forced to use it. A lot of the people I know using Java

Re:Return of Java

[Fweeky]

Sure; Ruby, Python, LISP, SmallTalk, even Perl and PHP; these are dynamically typed languages, although they may also be dynamic in other ways (like with regard to run-time code generation and modification).

Not to be confused with scripting languages, 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.

Re:Return of Java

[Anonymous Coward]

A modern PC spends almost all its time waiting on user input or IO bound anyway.

and the fact that it takes a Java UI 100x more effort (at least the sluggishness feels that way) to process such input doesn't do it any favors

Re:Return of Java

[clambake]

Unless it shows some bugs on "obsure" platforms like AIX.

I'm not sure that's particularly fair... C++ compiles don't have strange platform bugs!?

Re:Return of Java

[Electric Monk]

I'd hardly call Resin free. Have you seen this or this?

Unless of course you're talking about some sort of bizarre tree/java server combo that I'm not aware of...

Re:Return of Java

[16K Ram Pack]

Personally, I quite like strong typed, but they're only good if people take full advantage and allow types to also aid in the documentation and understanding process.

One thing I am keen on is compile-time languages like PHP. I spent about 2 days a couple of weeks ago dealing with a fault that was basically because the coder had released a different source and executable version but not changed the version number that the program printed. With PHP, there is no visible executable.

Re:Return of Java

[Iffy Bonzoolie]

Yeah, if you have a thread with a tight main loop that isn't blocked on IO or some other blocking resource, it's gonna use up as much CPU as possible. A solution I've found to make programs like that "nicer" is to just put a Thread.sleep(1) somewhere in the main loop. It doesn't seem to have too much runtime performance impact, but CPU utilization drops dramatically.

When developing for Java mobile phones, we found that the schedulers on some handsets were just terrible, so we often had to do sleeping tricks to ensure that other thread(s) would get enough CPU time.

-If

Re:Return of Java

[Anonymous Coward]

Sorry Bud. Maybe the guy who modded it troll will get meta modded. It's obviously just a (silly) joke. I thought it was funny, anyway.

Re:Return of Java

[YetAnotherAnonymousC]

I stand corrected. Shows you I was never dealing with the licensing the place where I used Resin. Do I win back any nerd points by pointing out is *is* fairly cheap compared to products by two certain three-letter-initial companies? =)

Re:Return of Java

[bill_kress]

As usual, it's the programmer that's the problem.

You NEVER replace within strings. If you know you're going to be using serious string manipulation, you use string buffers.

The problem is that Java is easy enough to use that you get every programmer out there thinking he's an expert.

In general, he's not.

Re:Return of Java

[Anonymous Coward]

You didn't get what I meant. The Hotspot only gets info from assembly instructions. The C++ compiler gets info from a high-level code. Remember the classic comparition between qsort() and sort(). In Java, qsort() could benefit from the Hotspot because it would optimize the function calls; but the sort() (C++) doesn't even need any function call inside. Which one you think is faster? An optimized function call or none? The only code faster than the fastest code is no code.

So what I said is that the Hotspost can only optimize the flow of the low-level bytecode. The C++ compiler can use the abstractions provided by the language to generate a far better code.

As another poster pointed, even in that biased benchmark that "proved that Java is faster than C++" the C++ code was so poorly written that it made it run 600 times slower.

Re:Return of Java

[Fweeky]

Careful there; static and dynamic typing are different from strong and weak typing. Compare and contrast: Strongly Typed/Weakly Typed, Statically Typed/Dynamically Typed.

Ruby is dynamic but strongly typed; PHP is also dynamic, but is weakly typed, i.e:

-% ruby -e 'puts "5" + 6'
-e:1:in `+': cannot convert Fixnum into String (TypeError)
-% php -r 'print "5" + 6;'
11

Re:Return of Java

[Electric Monk]

Fair play - never said it was the suxorz. It just ain't free man. Oh - and boy those WebXXX products certainly ain't even close. :)

Re:Return of Java

[kaoshin]

I started off in support at this one company and used to think our developers and admins were all morons. I moved into their ranks and they all think the support people are morons, while the wisest of us have come to realise that it's the guys in the ties that cause the biggest problems. IMHO bigotry is not at all exclusive to Java in this regard. Often, a certain tool or type of technology gets a bad wrap in many organizations because of poor applications that are a pain to implement, extend, maintain and support.

Heres an example... In my own environment, one of our bad words is Acrobat. Management got us into the mess by not enforcing standards and you have half the company using one version, another using an entirely different version. This has become a nightmare for many groups involved. This is hardly the fault of Adobe, but you can bet our employees think that "the stupid program sucks", and that "PDF files never work right". Sometimes you can smile and nod, and sometimes you wish you just never got into the IT field to begin with when you get berated by some heartless meanie who doesn't understand that it wasn't your incompetence that caused the problem.

Re:Return of Java

[Nevyn]

On the other hand, a re-compiler can watch what is happening, and generate better code. As an example: if (condition) { ...simple code... } ... more code... When compiled, I cannot tell C (or C++) that "condition" is an error that will occur.. well, should never occur..

Yes, in gcc, you can. See builtin_expect().

Re:Return of Java

[droleary]

I didn't list requirements, I listed typical specs of an entry level machine.

Like it or not, if you assume a person has that to throw at Java, that's a requirement list. More importantly, every app developer can list an entry level machine, but the minute the user actually tries to run a significant number of "entry level" apps at the same time, suddenly their entry level machine doesn't quite live up to the requirements. I want something that runs well with 500MHz CPU and 64MB of memory because I usually want to run 6 apps like that at the same time without having to endlessly wait for the computer.

Clearly your experience differs from mine. I came to Java from C/C++.

Yes, my experience clearly differs: I have some! It doesn't take a genius to see that Java is better than C++, but that just means that C++ is that much worse than the languages that came before it, too! That you can only count those two among your OO experience means you have a very great deal to learn. Get back to me when you've at least used Smalltalk, which pre-dates Java by decades.

Now, sure, none of that is unique to Java or necessarily missing from C/C++, but my current preference for Java is based on my experience, not on anything Sun's marketing department may have spewed out.

I'm sure you fully believe that, but the truth is you just switched from one language du jour to another, both pushed based on where they came from and not what they offered. As a developer, you would greatly benefit by looking at languages that don't get a lot of press releases. In them, you might just find something that better solves your problems.

Re:Return of Java

[Anonymous Coward]

You're ignoring the fact that there's many quite capable profilers available for C/C++. If you properly profile a C/C++ application, its quite easy to get far better than java performance.

Re:Return of Java

[clambake]

I don't think I am... A profiler can show you problem spots, but unless you want to spend months profiling every possible execution path, you have to make guesses as to which code paths are more important to clean up. If you have a hundred different possible directions you can go, but your users tend to go down only two or three, then it's a waste of time to work on cleaning up the other 97. If your guesses are right, then good, you god a fast program, but if you are wrong and your users go down different code paths than you expected, then you've wasted your work. Hotspot, on the other hand, can clean up just the paths that are used most because it doesn't have to guess, it KNOWS what is executed most.

Re:Return of Java

[Qui-Gon]

"Premature optimization is the root of all evil."

Re:Return of Java

[ArbitraryConstant]

"Amusingly enough those type of people that you describe, who change their minds like the wind, who are inexperienced, tend to be the ones that I've met who prefer languages like perl, python, etc."

Ouch, man. That hurts.

Re:Return of Java

[MarkCollette]

I give you the benefit of the doubt :)

Re:Return of Java

[gbjbaanb]

I see job adverts that require you to have 4 years of .NET experience... or 'must have x of the following skills , , , GUI, ' ... what is this GUI skill they talk of? I've never quite figured it out.

In all, skill requirements in job adverts mean more about what they think will entice you to apply, than what they actually require.

Re:Return of Java

[iwadasn]

Never say never.

There are techniques to dramatically reduce memory use and garbage collection for VM based languages like Java.

One of them is escape analysis. Simply put, everything that can go on the stack is detected and placed there. You can then drop any synchronization as well. This is an excellent improvement essentially for free, once the compiler supports it.

A second technique is object inlining. Sometimes an object is always contained within another object, so you can just inline its data inside the bigger object, throw out anything you know you won't need, and have one less object floating around. You couldd even do this speculatively (and recover if an assumption proves bad) in a VM. These sorts of things are very hard to do in languages like C, and hard to do in statically compiled languages in general.

The advantage of going with a VM is linear in program difficulty (compiler optimizations tend to be in % terms), but the overhead is generally constant (10 MB for the VM, for instance), so at some point any program that could actually stress a computer will be far enough out that a VM will help rather than hurt it. That day has been approaching for awhile. Another half a dozen good optimizations (like the above two), combined with full VM sharing, and it might be here.

Re:Return of Java

[sjames]

I've been doing server-side Java development for a little over 4 years now, and we've never had a performance problem.

Perhaps you're just used to it after 4 years. Personally, I find that Java manages to drag even on a dual Xeon system.

Though quite rusty at it,I do know Java. When it came out, I *wanted* to like it since though it wasn't nearly as innovative as the market hype wanted me to believe, it might have had enough hype to actually catch on and make cross platform apps.

Unfortunatly, It has a hard enough time being compatible with itself (I have many times seen apps that specified an exact minor version number they HAD to have), much less actually being cross platform.

In spite of JIT compiling, and everything else, it remains slow and a memory hog from hell.

So, it doesn't do anything that can't be accomplished in other ways, it's slow, and it's a shifting target. I'll pass.

Re:Return of Java

[mcbevin]

The advantage of going with a VM is linear in program difficulty (compiler optimizations tend to be in % terms), but the overhead is generally constant (10 MB for the VM, for instance), so at some point any program that could actually stress a computer will be far enough out that a VM will help rather than hurt it. That day has been approaching for awhile. Another half a dozen good optimizations (like the above two), combined with full VM sharing, and it might be here.

Again, the theory is nice, but I'll believe it when I see it. Personally, I think theres a good reason why Transmeta chips aren't faster than AMD/Intel chips, and why despite being around and improved for years Java apps are still never used for really performance critical application cores.

In any case, if any VM language were to reach this theoretical line where it starts beating compiled languages (which I doubt in the near future, though one should never say never), I'd say C# is _probably_ likelier, as Java has some inbuilt inefficiencies due to early design decisions which have to be stuck to due to backward compatability which its very hard to hotspot out, which C# has somewhat avoided.

Perhaps the day you say is approaching is the same day that Linux takes over the desktop? :) We should really have included it in this poll - http://polls.slashdot.org/pollBooth.pl?qid=1158 :).

Re:Return of Java

[agentforsythe]

Ho ho ho

it gets funnier with repetition

If you'd used Rebol, you'd be done in a couple of hours.

Re:Return of Java

[Duhavid]

Shouldnt the tool get out of your way rather than in your way?

Re:I agree with that

[Anonymous Coward]

it goes to my brain every morning. mmmm coffee!

Request for interview

[Anonymous Coward]

Do a user driven (10 questions, you know) with James Gosling. Java/Sun takes a lot of flak these days, it would be genuinely interesting to get Gosling respond to some good questions.

Re:Request for interview

[Miamicanes]

You mean, like:

* What were they smoking when they decided to make "byte" a signed primitive type?

* Signed hexadecimal?!? OK, let's take a vote: what do you REALLY want byte foo = Byte.parseByte("80",16); to do? a) throw a NumberFormatException because '80' is larger than 127 and isn't negative b)Realize that if you're handing it a hex value, you want it to just shut up and set the bits to "10000000". At the very least, the various Number-implementing classes should have a .parseLiteral("value", radix) method that just sets bits without trying to second-guess the setter's motives.

* Would it have REALLY killed them to have made the JVM step in when somebody tries to call the .equals(Object) method of an object the JVM knows to be null and simply return "true" if the argument object is null, and false if it's not instead of throwing a NullPointerException?

* Likewise, would it have REALLY killed Gosling to acknowledge that String DESERVES special treatment relative to other Object types and overloaded "==" to test for semantic equality instead of literal equality when applied to Strings? I challenge him to think of one single instance where ANYONE has ever genuinely cared whether two semantically equivalent strings do or don't literally point to the same sequence of bytes in memory.

Re:Request for interview

[Miamicanes]

eek. uneditable typo... ...just shut up and set the bits to "0001000".

Re:Request for interview

[Miamicanes]

aaaaa...aaargh. Hurricane stress is driving me crazy. It wasn't a typo after all.

Re:Request for interview

[Enonu]

What were they smoking when they decided to make "byte" a signed primitive type?

All integral types are signed. This keeps things simple, otherwise you need ushort, uint, and ulong as well. Your second point basically the first, except expressed via a complaint about the API.

Would it have REALLY killed them to have made the JVM step in when somebody tries to call the .equals(Object) method of an object the JVM knows to be null and simply return "true" if the argument object is null, and false if it's not instead of throwing a NullPointerException?

Equals is an *instance* method with all the properties of such a method. You need an *instance* of an object in order to call the method. If you make an exception, you go down a slippery path of making more exceptions, and a slow, clunky JVM would most likely result.

Likewise, would it have REALLY killed Gosling to acknowledge that String DESERVES special treatment relative to other Object types and overloaded "==" to test for semantic equality instead of literal equality when applied to Strings? I challenge him to think of one single instance where ANYONE has ever genuinely cared whether two semantically equivalent strings do or don't literally point to the same sequence of bytes in memory.

I've seen == used for speed purposes. I've also used the same technique from time-to-time, but not that often. I could see this concession being made, as it often confuses beginning programmers.

Re:Request for interview

[Miamicanes]

That's basically my complaint -- Gosling basically forced the Java team to check their sensibilities at the door and blindly enforce rules that contravene just about every conceivable real-world scenario JUST TO BE CONSISTENT.

Actually, I've thought of a few more... like the way you're forced to explicitly try/catch UnsupportedEncodingException even when the encoding is UTF8 -- an encoding that BY DEFINITION must be supported by any remotely compliant JVM. At the VERY LEAST, the core libraries should offer two methods: a flexible one that supports any encoding and requires try/catch for UnsupportedEncodingException, and a rigid one that's hardwired to UTF8 for the other 99.99999% of the time when you just don't want to be bothered by pointless ceremony.

And don't even GET ME STARTED on HTML in javadocs. Yeah, embedding bulleted lists with html might be consistent, but it's BUTT UGLY and UNPLEASANT TO READ by the very people who depend upon it the most -- the people who actually have to maintain the classes themselves.

Now, if javadoc offered a way to preprocess javadoc bodies to allow wiki-ish shortcuts, I'd be happy: /** Some method documentation...
* This is ***bold***.
* This ***whole phrase*** is bold.
* This is ---italicized---.
* This has ---multiple italicized words--- in it.
*
* ===[This is the heading for a list:]
* ===This is an item in the list.
* ======This is a sub-item in the list.
* ======This is the second sub-item in the list.
* This continues the second sub-item in the list.
*
* ======This is the third sub-item in the list. Notice the blank line?
* ===This is the second item in the big list.
*
* and so on...
*/

Ultimately, it comes down to the ideological battle between those who believe everyone should be forced to do things the One Right Way(TM) vs those who'd rather give everyone maximum flexibility to do things the way they happen to like the best.

It might be politically incorrect to say anything good about Microsoft on /., but I'd bet lots of money there's an experimental version of VisualSourceSafe floating around at Microsoft that treats VB.NET and C# as nothing more than different presentations of the same underlying code and allows developers to work on code checked out from the repository using whichever language they happen to like better (the only hard part would be dealing with attempts to check in invalid code which can't be tokenized at all).

Re:Request for interview

[Trinition]

I've always wanted to see...

public class Object { // ...
public static boolean equals(Object o1, Object o2) {
if(o1 == null) {
return (o2 == null);
}
else {
return o1.equals(o2);
}
} // ...
}

Then we could to this...

Object a = null;
Object b = null;
if(Object.equals(a, b)) { // ...
}

Embedded Java.

[Vo0k]

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.

Re:Embedded Java.

[Vo0k]

One more interesting notice... Java as a development platform. Quite often recently I've seen Java as the language for development kits for different embedded devices. The choice is obvious: Write the kit for Windows and get yelled at by Linux community for supporting the monopoly. Write it only for Linux, you lose at least 60% of customer base. Write for both, not only you have two source trees to maintain, all the others are neglected. Write in Java - one size fits all. The speed isn't so critical in this application (how long could it take to compile 80K of C or Assembly source for a microcontroller?) and cross-platform compatibility is essential.

APIs and Libraries

[tezza]

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.

Re:APIs and Libraries

[roman_mir]

java-source.net is part of the problem. Google will equally give one hit to each side in a fight between java and .net

Stupid comparison

[plumby]

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.

Re:Stupid comparison

[uid0mako]

Still a stupid comparison, but:

+microsoft +.net = 6,810,000
+sun +java = 5,360,000

Re:Stupid comparison

[KontinMonet]

Yep, reminds me of the argument Fox News used to 'prove' the BBC was anti-American. 'We did a Google search with: BBC anti American,' they said, 'and it came back with 44702 hits. That proves it!'

I wrote to Fox stating that I had entered 'BBC not anti American' and Google came back with ... 44702 hits. No reply, of course. Nuff said.

Re:Stupid comparison

[slasho81]

Google treats ".net" the same as "net". The googlefight between "java" and ".net" is the same as the googlefight between "java" and "net".

Re:Stupid comparison

[mr_sas]

obviously that doesn't take into account microsoft branding everything as .net

Re:Stupid comparison

[Anonymous Coward]

... which they've stopped doing. You might get some hits for the beta version of Win2003, but not much else.

Re:Stupid comparison

[zarr]

java: 65,300,000
c#: 4,340,000
vb.net: 2,500,000

Re:Stupid comparison

[joshmccormack]

so it's Java the beverage and island vs. .NET the URL extension... and perhaps the fish catching tool. Perhaps a more semantic search would be in order to bring this back to only be silly instead of useless.

Re:Stupid comparison

[r.jimenezz]

Not to mention that if you used terms like J2EE, J2SE and J2ME you'd probably get an awful lot more hits for the Java side.

I got this SysCon editorial on my inbox this morning and thought it was one of the most stupid things I've read from them in months.

Re:Stupid comparison

[Brandybuck]

Was that Fox News, or a Fox commentary show like O'R or H&C?

Re:Stupid comparison

[Anonymous Coward]

For the sake of accuracy:

java -coffee

Gets you only 10,800,000 ;)

-Jesse

really?

[raffe]

Yeah, CxO talks about own technology, journalist writes about technology and VCs are investing in technology. Does it qualify as first page news?

Java and Linux is the next thing.
Come on, this isnt news.
No, we didnt read it at JDJ first. We knew it long a go.

Not intended as flame but this is just stupid.

Re:really?

[raffe]

This is much more interesting:
Run .NET-Based Applications "On Any Java Platform"

Java has more company now

[Eberlin]

It's not that Java left, it's all the attention it's now getting from the .NET crowds. I'm sure Mono has a few things to do with it, too. Oh, and that whole Eclipse project thing -- I must admit all the talk of Eclipse made me take another look at Java.

Maybe it's also the improvements (and lower price) of hardware that makes Java attractive again. That may compensate for any speed loss in the desktop java apps.

Then again, maybe we're just falling victim to the Sun Microsystems re-hype.

Re:Java has more company now

[sn0wman3030]

Unfortunatly for us, what's on /. is not representative of what's actually going on in the tech world.

Re:Java has more company now

[BarryNorton]

I must admit all the talk of Eclipse made me take another look at Java

I'd also admit that despite being saddened to have to work with Java again - on a new project and despite having worked with a modern language (Haskell) for a long time - one thing that's impressed me has been Eclipse.

Move along, nothing to see here..

[CountBrass]

Seriously, this was a 100% fluff article. The foundation for the article was based entirely on the assertion that a Google for "Java" brought back far fewer hits than "NET": well no shit Sherlock- perhaps if you'd tried ".NET" instead?

The major problem Java has is EJBs: everyone in Java-land seems to think that their problem requires solving using this pile of crap. A web application with persistence- ooh we'd better use EJBs then!

A secondary issue for Java is the barrier to entry is extremely high: sure you can learn the language quickly but it's Java's libraries that add the real value. And there are an awful lot of them. I've been using Java for 10 years (yeah I developed using the AWT and cursed it every day: if it hadn't been for the AWT being so awful I'd never have thought Swing was any good). Anyway, I've been using Java for 10 years and I would hate to have to learn it from scratch today.

Re:Move along, nothing to see here..

[Anonymous Coward]

The major problem Java has is EJBs

For a while, "Java Culture" went totally apeshit with over-engineering everything and ridiclous focus on 'patterns' even when they failed to meet real world requirements. They understood the "entrprise" part, they just failed to make the environment accessible to the every day hacks (both business and programming) out there.

It seems that they're finally getting past this, and have finally realized that you don't need 7 layers, a 100K app server, two architects and 50 Indians to splat some database values on a webpage (when a single $25/hr ASP|PHP guy can do it in an hour). So now you're see realistic Java data layers and web tools coming out.

OTOH, you see some crazy stuff like integrating PHP -- its almost as if they don't want to sully Java's perfection-oriented system, but someone has to mush the HTML tags together, so let the scripting boys do it.

Re:Move along, nothing to see here..

[Anonymous Coward]

odd, I was of the opinion that the only advantage java has is EJBs.

and you don't need to 'know' all the libraries to be productive in java and the libraries you do know. and the ones you don't know often come with these handy things called documentation.

Re:Move along, nothing to see here..

[rmohr02]

Seriously, this was a 100% fluff article. The foundation for the article was based entirely on the assertion that a Google for "Java" brought back far fewer hits than "NET": well no shit Sherlock- perhaps if you'd tried ".NET" instead?

You'd get the same results. The '.', used in a Google search, is a shortcut for searching for a string--you can either use '"i want to find this string"' or 'i.want.to.find.this.string'. Hence, ".NET" will search for a string consisting of the word "NET" and should return the exact same results as a search for "NET".

Re:Move along, nothing to see here..

[Anonymous Coward]

The major problem Java has is EJBs: everyone in Java-land seems to think that their problem requires solving using this pile of crap. A web application with persistence- ooh we'd better use EJBs then!

So help us change that perception, switch to Spring and tell everyone about it.

Re:Move along, nothing to see here..

[Pastis]

10 years Java development? I tought that the first release of Java was in March 1995...

Re:Move along, nothing to see here..

[asb]

Yes. Unlike Rome, Java was built in one day.

Re:Move along, nothing to see here..

[a_n_d_e_r_s]

Well some programmers had to make that release so there a a very small group of people who has 10+ years of java experience.

Myself I only started in early -96

Re:Move along, nothing to see here..

[CountBrass]

If you're going to nitpick at least get your facts straight !

23 May 1995 Sun announced Java and HotJava at Sun Con.

Re:Move along, nothing to see here..

[g0at]

In a related article, it was reported that a Google search for "apple" returned significantly more results related to fruit and vegetables than did a search for "microsoft". Analysts were at a loss to explain the discrepancy, but were investigating collusion between one California-based firm and the agricultural lobby, sources say.

Re:Move along, nothing to see here..

[CountBrass]

I have, I am doing and I do.

And here's that link again spring framework from a non-AC poster so this should be more visible here ;-)

Re:Move along, nothing to see here..

[fijimf]

The major problem Java has is EJBs: everyone in Java-land seems to think that their problem requires solving using this pile of crap. A web application with persistence- ooh we'd better use EJBs then!

That's soooooo 2002!

Re:Move along, nothing to see here..

[Pastis]

My bad :)

It's been a long time and I don't remind that well. I just know that it was during that part of the year, because it was my first year with Internet access, and it was a big thing even at that time.

We had Solaris workstations, and Netscape was big.
Aahhh the old days.

So my comment is even more valid now: 10 years java experience is almost impossible. Except that many people require that on job descriptions :)

Thanks for the fix.

And for anybody who doesn't believe...

[RAMMS EIN]

``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.

Re:And for anybody who doesn't believe...

[Coppertone]

Well... but the number 2 most-active project on sourceforge, Azureus BitTorrent client, is written in Java and it looks real good.

If only everyone knows how to write Java properly....

Re:And for anybody who doesn't believe...

[LizardKing]

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.

Re:And for anybody who doesn't believe...

[after]

It doesnt "look" good at all. I don't know why someone would say that. The GUI is poorly _emulated_ and does not even use the complete Win32 GUI subset, instead creates it's own litle API that you can apply themese to.

Sorry, but Azureus is pretty slow. Just try resizing it and look at all the GUI inconsistencies.

Re:And for anybody who doesn't believe...

[Anonymous Coward]

Ham? Is that you? Good seeing ya here, but don't misguide people about java based on your limited application of swing interfaces. We both know most of your warehouse is controlled by siemens PLCs, you just use the swing interfaces to send some quick messages to these PLCs.

Re:And for anybody who doesn't believe...

[groomed]

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.

Everything is easy when you approach it from the point of view that it doesn't actually have to work.

There are many versions of the Java environment, from different vendors, all with subtly different behaviors and ways of integrating into the environment. Not to mention that the user may be running other Java applications which depend on a particular version of the Java environment, which further complicates matters. This makes it a pain if you want to deliver an application to the user with minimal hassle.

Or, you can just mandate that the user run such-and-such version of the Java enviroment on such-and-such platform, but then you lose a large part of the write-once, run-everywhere appeal.

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's "slowness" has at least three components: startup time, garbage collection delays, and the huge footprint which triggers swap activity.

For server applications, none of these matter much. For interactive client applications, these factors conspire to make Java apps look very bad when compared to "native" competitors. The exception here are applications like Eclipse, which you start when you get in from work and don't quit until you're done. But for most other apps, e.g. utility apps which you just want to quickly use and close, or workflows where you switch between multiple apps frequently, Java is just not suited.

Very rarely do we have to resort to doing major grunt work on the server as opposed to doing it in the Java client.

You're missing the point royally. Java isn't slow at doing grunt work. Few people would contest that. But as a platform to write desktop applications, it is a pig. The Swing UI is slow and prone to memory leaks, data interchange facilities are poor (even the clipboard functionality integrates poorly with the surrounding environment), memory requirements are completely uncontrollable.

Yes, Java does requisition a lot of memeory when an untweaked JVM starts up, but the inmpact depends on the machine running the program.

Indeed, and that's why most Java shops pretty much only run one application on their servers.

This could be rephraed as "bad Java programmers leak memory".

The fundamental problem is that you cannot control how memory gets used. For example: the JVM allocates memory from the underlying OS in chunks which it then doles out to your app as necessary. Then at garbage collection time, the memory is reclaimed from your app and returned to the JVM. But then the JVM may or may not ever return this memory to the underlying OS. This means that even if you have a tiny application, when the user opens a mammoth 100MB document just once, the application will continue using 100MB even after the user has closed the document.

Yes, this is sort of tunable through commandline options and other properties, but then only for some versions of some implementations of the JVM. Which brings us back to the first point, that it's a hassle to deliver hassle-free Java applications. It's so troublesome in fact that some programmers choose to simply distribute a JVM along with their apps.

The bottomline is this: Java is a cool language, but it just doesn't play nice with others. It insists on reinventing everything, it insists on abstracting everything, and it insists on total control over the environment. That's fine for in-house apps or web apps, but it limits Java's adoption on the desktop.

And ultimately, I think it condemns Java to a perpetual "behind the scenes" existance, growing ever more baroque appendages in its invisible niche, until its burdensome legacy is swept away by something more open.

Re:And for anybody who doesn't believe...

[Anonymous Coward]

Good for you. I tried yesterday on a fresh XP SP1, and Sun's JRE 1.4.2 failed.

Re:And for anybody who doesn't believe...

[RAMMS EIN]

I am almost at the point that I'll promise not to engage in this discussion again. Ok, one more time:

``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.''

And a 20 MB download that takes dog knows how many megabytes after installation. Also, the whole process will have to be repeated at the next release, as chances are software developed on a newer version won't run on an older one.

``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.''

Most applications don't need a lot of speed once up and running, anyway. Startup time is a huge annoyance, to me anyway. Is it really that hard to save the compiled code, so next time the JIT doesn't have to work again?

``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 don't know about your systems, but on any system I have used in the past years, user interfaces in Java apps are noticeably more sluggish than in native ones. Perhaps this is perceived performance, but arguably it's the perceived performance that matters for user interfaces.

``java applications leak memory

This could be rephraed as "bad Java programmers leak memory".''

Yes, but isn't it symptomatic of defects in the language if many programs written in it leak memory? Besides, isn't Java's garbage collection supposed to take care of things? Personally, I believe that there was an issue with old JVMs (at least on Linux) leaking memory, that has now been solved. At any rate, I think that kast's author is being more bitter than rational when he says things might be better without gc. Gc is a Good Thing, after all, memory allocation and deallocation is excactly the sort of task that machines are good at and humans are not. It can even speed up programs under some circumstances.

Re:And for anybody who doesn't believe...

[Tim C]

the huge footprint which triggers swap activity

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#.

Re:And for anybody who doesn't believe...

[groomed]

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.

It's nice to know you're so well disposed, other than that I fail to see the point of your reply.

Re:And for anybody who doesn't believe...

[downbad]

activity != popularity

Re:And for anybody who doesn't believe...

[mcbevin]

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).

Re:And for anybody who doesn't believe...

[Anonymous Coward]

Lets assume that he's well disposed because he's a software developer ... Now would you prefer to pay him for more hours or just buy some cheap RAM?

Re:And for anybody who doesn't believe...

[isdfnmo]

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.

That is SO not the point. Why the hell should a, for example, 55 year old occasional computer user need to even know WHAT Java is, let alone UNDERSTAND why they need to install it?
Surely the uppermost aim for any software engineer / developer / designer is to hide complexity from the user?
I have two roles at my work: the first is as an IT Project Manager and the second is in a Procurement role for 3rd-party software development effort (i.e. a Client). If the technical-lead on a project or a supplier ever told me that "all the user needs to do" is to "just" download and install anything (including Java) to run their application I would throw them out the door / off the project!
This is as absurd as priming your fuel pump everytime you want to drive somewhere, or calibrating your derailleur gears before you can use your bicycle.

Not acceptable!!

Re:And for anybody who doesn't believe...

[Anonymous Coward]

I have noticed some Java based GUIs (and some from big brand names) to be so slow as to be unresponsive. Others have been fine. Perhaps there are traps in java that allow sluggish programs to be written, but it does appear that it is possible to write responsive ones as well. It also seems to depend on the machine - e.g. Eclipse may run badly on one machine, well on another, even with about the same machine spec and same JVM.

On the whole native interfaces tend to run less sluggishly. However, if you want to write the source code once (although compile many times) you are required to use a cross-platform wrapper (if not using Mono/C#) and that puts you back into the same sort of version dependencies that you have for the JVM versions. Thus is performance (speed and memory) is acceptable with Java then Java will be less of a hassle as you at least don't have to provide a version of the code for every possible target platform.

With regard to memory leakage, unless you actually write the code carefully and check it appropriately then C and C++ have greater scope for creating memory leaks. I remember back in the day, for example, when netscape used to leak memory like it was going out of fashion, and that certainly wasn't a java application. On the other hand I've seen various JVM/Java app instances leak memory too, but then the memory leaks are more likely to be an interaction with the infrastructure (JVM and supporting code) than the language itself per se.

Re:And for anybody who doesn't believe...

[Anonymous Coward]

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.

It's certainly possible to wrap java applications up such that it doesn't require much more than this, even with the installation of the JVM. It requires a well-written installer, and I think too often in the past installers have been written by programmers, not people versed in HCI skills. These days, though, more and more installers come with a series of simple options - a 'default' button and a 'custom' button. Apart from accepting licences, and the like, there often isn't much more too it than that.

Re:And for anybody who doesn't believe...

[groomed]

The point is that you can't tell users who complain about the memory use of your app that Tim C thinks it's alright.

Re:And for anybody who doesn't believe...

[bl8n8r]

- java applications are difficult to install
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.

Re:And for anybody who doesn't believe...

[arivanov]

You missed a few:

1. Java does not have support for DNS in its main classes as recent as 1.4.x (need to look at 1.5). As such it is not suitable for any more complex network software period

2. Java network interface support is not platform independent. As a result any application that needs to bind to a specific interface on a multihomed machine needs to have external config or to be platform dependant which largely defeats the idea of using java in first place.

So on, so fourth.

Re:And for anybody who doesn't believe...

[sbrown123]

If resizing a window is "slow" you probably just have a crappy computer. Azureus uses SWT which uses native widgets. In other words, if Azureus resizes slowly that would mean the rest of your apps not written in java do the same.

Re:And for anybody who doesn't believe...

[Glock27]

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. ;-)

Re:And for anybody who doesn't believe...

[osgeek]

Well that fucking proves it, I guess. Case closed... we can all go home now that you have proven Java's light weightedness, leaving no room for doubt.

Re:And for anybody who doesn't believe...

[bkocik]

Personally, I believe that there was an issue with old JVMs (at least on Linux) leaking memory, that has now been solved.

You would be correct. I make my living writing server side Java code, and I love it. Several months ago, though, we discovered that there was a massive memory leak on several of our Linux servers running JDK 1.4 (which actually isn't old at all). An upgrade to glibc corrected the issue.

I can't really assign blame to either the JDK or the libraries for it, I think it was just an unfortunate interaction. These things happen.

Sorry that I don't remember the precise version numbers involved.

Re:And for anybody who doesn't believe...

[mcbevin]

It is of course possible to include the JRE with your program, if you don't mind the added size to your installer. However we were discussing the particular situation where you require the user to additionally download and install the JRE themselves.

Regarding creating installers, I like to use NSIS personally.

Re:And for anybody who doesn't believe...

[sbrown123]

This makes it a pain if you want to deliver an application to the user with minimal hassle.


Not really. There is Java WebStart which solves this issue. Commericial products like InstallAnywhere solved this also. Old issue.


Java's "slowness" has at least three components: startup time, garbage collection delays, and the huge footprint which triggers swap activity.


Start up time is slow. It takes approx a couple seconds. Ofcourse this is a one time cost that interpreted languages go through. C# has the same problem.

Garbage collection delays? Ive never seen this as a big problem. With good coding practice (create fewer objects, reuse etc) this becomes invisible.

Memory swapping? You must have a mighty large java app or very little memory. As for java being a memory pig that is questionable since IE, mozilla, and about a dozen other apps I run on my computer consume more memory than my java apps like Azurues. Go figure.


It insists on reinventing everything, it insists on abstracting everything, and it insists on total control over the environment.


I just wrote a java app the other day that embeds an activeX control within it. Worked great. Ive written C++ apps that use Java (gcj) and it worked great. I think youll have a hard job trying to prove that strange view.


I think it condemns Java to a perpetual "behind the scenes" existance, growing ever more baroque appendages in its invisible niche, until its burdensome legacy is swept away by something more open


Java is already open. Go look at projects like GNU classpath or Kaffe. Javas invisible niche is kinda hard to miss since it covers most IT departments here in the United States and abroad. A bit hard to miss. You can go to SourceForge and see that it is currently almost exceeded the number of C and C++ apps.

Your example more fits C# at its ilk which has had very slow adoption.

Re:And for anybody who doesn't believe...

[Zardoz44]

Maybe someone should work on fixing those things that encourages most people to write java improperly. If most people are using it incorrectly, then that points to issues with the language that need to be resolved.

Re:And for anybody who doesn't believe...

[BattleTroll]

"Yes, but isn't it symptomatic of defects in the language if many programs written in it leak memory? "

No, it's not symtomatic of a bad language, but that a lot of programmers don't know how to properly manage their objects. Whenever I'm called over to look at a java memory leak it's one of two things - people put hard references in static containers that never get cleared, or they initialize objects with circular reference that don't unwind properly. Blaming Java for bad programming is just wrong.

People often use garbage collection as an excuse to be lazy. "I don't have to worry about it, the garbage collector will take care of it". I'm sorry to say, garbage collectors are not not the silver bullet to bad programming.

Re:And for anybody who doesn't believe...

[Myolp]

You actually use JBuilder to write Java code? I thought that it was something students were forced upon during their first Java programming-course today. A more bloated, feature-lacking and ugly Java IDE is probably hard to find. If you can afford more RAM, why not but a proper IDE, like IntelliJ IDEA, or use Eclipse or NetBeans which at least provide most of the functionality one would expect from an IDE and are free.

Re:And for anybody who doesn't believe...

[halowolf]

I personally do use Azureus and am a Java programmer and I use Eclipse, the best use of SWT so far, but Azureus is a hog. It runs perfectly well on my system but I have never been a fan of using Java for GUI apps because I don't think that Java is a good language for GUI apps.

duck

Using Java for Azureus makes perfect sense as it does for Eclipse, but Java based GUIs do end up using more resources than what a native app would. However you do receive the advantages of cross platform deployment with a minimum of fuss.

Re:And for anybody who doesn't believe...

[Saint Stephen]

I find it utterly hilarious that people say that Swing proves Java is fast, because the really fast parts aren't written in Java.

Re:And for anybody who doesn't believe...

[groomed]

Not really. There is Java WebStart which solves this issue. Commericial products like InstallAnywhere solved this also. Old issue.

For Windows perhaps. But if you're going to confine yourself to Windows, why bother with Java?

Memory swapping? You must have a mighty large java app or very little memory. As for java being a memory pig that is questionable since IE, mozilla, and about a dozen other apps I run on my computer consume more memory than my java apps like Azurues. Go figure.

It's kind of pointless comparing different kinds of apps. You should compare a Java text editor to a native text editor, or a Java browser to a native browser.

Anyway, the point isn't how many bytes any particular Java program uses -- the point is that so many of them are wasted from the OS perspective. Some VMs can be tuned to somewhat mitigate this problem, 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?

I just wrote a java app the other day that embeds an activeX control within it. Worked great. Ive written C++ apps that use Java (gcj) and it worked great. I think youll have a hard job trying to prove that strange view.

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.

Javas invisible niche is kinda hard to miss since it covers most IT departments here in the United States and abroad.

Like COBOL, yes.

Re:And for anybody who doesn't believe...

[argent]

Mozilla and Word are two of the largest programs I use routinely. If an "LDAP client app" in Java is larger than Word, the logical conclusion is that Java has way too much overhead. If you had a significant number of your applications with a 37M working set instead of the existing native apps using hundreds of kilobytes to a few megabytes, I suspect your gig of RAM wouldn't go as far as you like.

I suspect that this comparison is actually unfair to Java... after all, I was able to run small Java apps on my Visor, with only 8M of RAM and 7M of that dedicated to code and file storage. They were small apps, and the startup time was significantly higher than any native application, and it was using the embedded model, but they *did* run.

Re:And for anybody who doesn't believe...

[Tim C]

Yeah - it's what my company has standardised on, and as we've recently been bought JB X Enterprise, the chances of them springing for anything else are remote. Not that we *wanted* X, of course, we were fine with 7, and would have prefered to wait at least until JDK 1.5 is out.

As for using Eclipse, a friend swears by (and ocassionally, at) it, but I've not had time to really look at it. The deadline on my current project is such that I can't afford to waste time learning a new IDE (heh - or posting to slashdot...)

Re:And for anybody who doesn't believe...

[Tim C]

Oh, I proved nothing, I just presented some real-world numbers, which is a hell of a lot more than most people spouting about Java's RAM footprint usually do.

Re:And for anybody who doesn't believe...

[mr breakfast]

Also, if you have memory leaks in java, the worst they can do is knock the jre over. I would much rather an application failed in that kind of way than have it fall over and take the OS with it.

Re:And for anybody who doesn't believe...

[nikster]

some comments on the kast people's criticism on Java:

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:And for anybody who doesn't believe...

[Tim C]

My point was that my web browser is using 2.5 times as much RAM as my Java LDAP explorer app.

So, we have a memory-hogging Java app and a memory-hogging C/C++ app, both running on a machine that is nowhere near having to swap due to memory usage. Also, RAM is cheap, especially compared to the price of a lot of software.

I was both disputing your apparent claim that Java apps necesarily force excessive swapping, and pointing out that even when that is the case, adding RAM is generally very cheap.

Re:And for anybody who doesn't believe...

[Anonymous Coward]

Like hell it's possible. Unless you're writing your own JRE, Sun's JRE most certainly can NOT be distributed and you'd be opening yourself up to a world of hurt if you even tried.

If it was possible, every slightly popular application like Azureus and Eclipse would offer a bundled version to save themselves a lot of trouble, since 20MB is nothing these days. But it's not so the task is showed upon the users.

Re:And for anybody who doesn't believe...

[Anonymous Coward]

For Windows perhaps. But if you're going to confine yourself to Windows, why bother with Java?

Because it's a solid, safe language with loads of high-quality libraries?

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.

I think you're coming very close to trolling. ActiveX controls prove nothing.

Re:And for anybody who doesn't believe...

[bay43270]

That is SO not the point. Why the hell should a, for example, 55 year old occasional computer user need to even know WHAT Java is, let alone UNDERSTAND why they need to install it?

You're assuming the software is targeted at the mass market. In that case, you would have wrapped everything up with an installer which would have taken care of the jvm issues for you (Try installing intellij idea on Windows for an example). Java isn't the only platform with dependencies. Most programs have dependencies on other libraries, and their installers take care of those for you. What makes you think Java is any different? You can't look at a handful of programs on sourceforge and think you understand the platform they were written on based on that limited experience. Those programs weren't written for joe blow. They were written for us.

Re:And for anybody who doesn't believe...

[groomed]

My point was that my web browser is using 2.5 times as much RAM as my Java LDAP explorer app.

And JBuilder is using more memory that all the other apps combined...

Compare apples with apples. Compare the memory use of HotJava with Mozilla. Compare the memory use of jEdit with TextPad.

It's not about the number of bytes used. It's about the number of bytes wasted. Java wastes memory because it reimplements code that exists as a shared library. Java wastes memory by not sharing memory between applications. Java wastes memory by not returning memory to the OS once it's no longer used by the application.

adding RAM is generally very cheap.

In general, yes, but it depends. It becomes quite expensive once you need more than 4 GB, since at that point you need to move to a different, and still expensive, architecture.

Re:And for anybody who doesn't believe...

[zarr]

Like hell it's possible. Unless you're writing your own JRE, Sun's JRE most certainly can NOT be distributed and you'd be opening yourself up to a world of hurt if you even tried.

Bzzzt!!! Go back and read the license for the JRE. It explicitly states that you can distribute it. You can even do some very limited modifications to it.

Re:And for anybody who doesn't believe...

[sbrown123]

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:And for anybody who doesn't believe...

[Anonymous Coward]

You forgot the runtime.

If you count the libraries needed to run Word and Mozilla and then compair that to the overhead for your LDAP app...you could get different results.

Re:And for anybody who doesn't believe...

[sbrown123]

I find it utterly hilarious that people say that Swing proves Java is fast, because the really fast parts aren't written in Java.


Swing is called a light-weight gui since it has no native peers. This means there are no native widgets in otherwords. Whoever said Swing is fast?

Azurues uses SWT. SWT is not Swing. SWT uses native widgets. SWT is generally faster than swing because of this.

BUT what people dont get is why Swing exists. SWT, although faster, operates differently on different platforms and looks different. Windows widgets look different than GTK or Qt based ones. SWT problems is the same as any other cross-platform gui like WxWindows. Swing though always looks the same no matter what the platform is. This means Swing apps look and operate the same no matter what the platform.

Re:And for anybody who doesn't believe...

[Anonymous Coward]

you mean so on, so Forth, right?

Re:And for anybody who doesn't believe...

[JPS]

Oh well... Does anyone know a GOOD url where all these myths regarding java are debunked ?

We have a codebase of + 1000000 loc in java, and they all run server side, client side (applets) and in mobile phones. The generated bytecode is small and efficient. Bad programmers will write slow, obeist and heavy code no matter the language, and Java is actually probably much more tolerant to bad programming than many other languages ...

Re:And for anybody who doesn't believe...

[fijimf]

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.

But Intellij's IDEA is much more responsive than both NetBeans and Eclipse, and it's written with Swing. So it doesn't seem to me that Swing is necessarily the bottleneck.

The real problem with Swing is that you can get 80% of your functionality and user experience with VB-level effort. The remaining 20% can be so excruciating, that many developers just choose to ignore it.

Re:And for anybody who doesn't believe...

[ak3ldama]

I absolutely hate the basics of that argument, it is not within the time allowed a programmer to write new stuff that is his own for his application. Occasionally there just has to be third party tools/modules used by applications. If every app had to reinvent, rewrite, retest, reharden every useful feature just to get in his 10% or 5% of the equation, software would have gotten no where. So maybe a 55 year old occasional computer user should just install the damn Java, he's probably sent there by the installer application anyways. God forbid he have to read the Readme.txt

Re:And for anybody who doesn't believe...

[danharan]

Hey, not disagreeing with you- just curious: how the heck does a Java programmer manage to leak memory?

(I write server-side java that runs without problems in between release cycles of a few weeks, and I've never actually seen any problems)

Re:And for anybody who doesn't believe...

[alcmena]

No offense, but someone who makes a statement like this, "In fact, many java applications that run for extended periods of time leak memory to the point of exhausting all system memory." kind of proves that they do not know what they are talking about.

The VM in Java limits the amount of memory a particular application is allowed to use. If the program has a memory leak, it will hit the VM limit and throw OutOfMemoryErrors. It cannot use all of the system memory unless the user specifically told the VM that it can (which is not likely to happen often).

Re:And for anybody who doesn't believe...

[Anonymous Coward]

A more bloated, feature-lacking and ugly Java IDE is probably hard to find

I agree with the parent.. It must really suck to be using JBuilderX. We switched to JBuilder X because one or two useful features, but within a few weeks (before the trial ran out) we had switched to Eclipse and have been happy ever since. We had actually tried out JDeveloper before that, though it is not as bad as JBuilderX, it is in the same league since it is actually based on the codebase of an older JBuilder version Borland had licensed to Oracle.

JBuilder X Enterprise is completely pathetic featurewise (refactoring features are a joke, as are most of the features). The web service designer is nice for someone who has not done web services before, but totally unnecessary once you figure out how, and the generated files are kinda messy in retrospect. The real kick in the balls would be the $3000+ price tag for a product that would've been worth $50 to us.

Eclipse + MyEclipse plugin (a $30 commercial product) is a much better option to get a J2EE app up and running fast. I've heard good stuff about IDEA, but haven't given it a serious try yet; I hear its a bit more flexible about things than Eclipse.

I don't know how attached your project is to JBuilderX, but for us it only took me less than an hour to migrate our project over to Eclipse, and only a few days to get accostumed to the new environment. It was like getting a new toy, Eclipse has so many great features that you will gain that $3000+ back in productivity easilly and your developers will probably be a lot happier and enthusiastic. That was my experience anyhow. Give it a try when you have time. Borland has made some great products before, but this most certainly isn't one of them.

Re:And for anybody who doesn't believe...

[jeffshaddix]

Agreed...it has been proven...and is told to me by every comp sci prof i've had...java is 4 to 6 times SLOWER than c++. The compile at runtime environment is abhorrently slow. Last semester i had the honor of taking a CS course from Bjorne Stroustrup, the inventor of C++. Stroustrup is currently working on a new C based language that will blow Java out of the water. Seriously guys...keep javascript...trash Java!

Re:And for anybody who doesn't believe...

[Anonymous Coward]

activity and popularity have nothing to do with quality. Think about windows

Re:And for anybody who doesn't believe...

[Lodragandraoidh]

Java garbage collection doesn't work in all cases. If a programmer instantiates multiple objects inside of a loop - and doesn't exit the loop or explicitly destruct the objects, a pseudo-memory leak will occur (basically the amount of ram allocated to java will be reached, and the application will lock up; I suppose you could effect the operating system if you set the high water mark large enough).

If you avoid this, then java is not a problem.

However, other 4GLs - like python and perl don't have that problem at all... and both are just as portable as java.

Re:And for anybody who doesn't believe...

[vadim_t]

Hey. I programmed in QBASIC quite a lot when I was about 13, so I feel I'm knowledgeable enough about this.

Well, QBASIC started up pretty much instantly (less than a second) on my 386 DX 40 with 4 MB RAM, and no disk cache. There was no delay for executing anything. That was the cool thing of it, you could execute code instantly. You could stop it at any point, make small corrections and continue.

In contrast, now sometimes I start Java apps on my dual Athlon 2000+ with 1 GB RAM. It takes *several seconds*. And it's simply unacceptable that while my computer is probably at least 100x more powerful than my first one, the startup time of programs that don't do that much is still awfully slow.

Re:And for anybody who doesn't believe...

[bmj]

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.

That, and if you're running a questionable VM (especially under Linux).

Re:And for anybody who doesn't believe...

[bwy]

As a side note, OS X always ships with the latest version of Java and updates are had easily thru software update. So, no problems with "Joe User" not knowing how to get a JVM.

So, none of this is an issue there. Really makes you wonder where Java could be if the same were true on Win32.

Re:And for anybody who doesn't believe...

[upsidedown_duck]

Instead, Object.class gets translated into machine code every time i start the JVM, over and over again...

I'm fairly convinced the JIT doesn't incur much overhead, because it appears that start-up times with and without the -Xint option are about the same (run time performance is dramatically different, though). The long start up times must be more related to loading lots and lots of dynamic libraries and classes. In fact, the start up times of Mozilla and OpenOffice.org--C++ apps--aren't very swift at all, either.

Re:And for anybody who doesn't believe...

[angel'o'sphere]

Java garbage collection doesn't work in all cases. If a programmer instantiates multiple objects inside of a loop - and doesn't exit the loop or explicitly destruct the objects, a pseudo-memory leak will occur (basically the amount of ram allocated to java will be reached, and the application will lock up; I suppose you could effect the operating system if you set the high water mark large enough).

Sorry, but this is nonesence. That loop gets interrupted by the GC just like any non loop gets interrupted.
angel'o'sphere

Re:And for anybody who doesn't believe...

[Anonymous Coward]

Well I do realize that you can leak memory in Java (or any gc-ed language) but I find it hard to believe the claim about exhausting memory and it being more difficult to isolate. Given I am sure the kast people could provide examples but such examples are just examples of bad java programs.

It is kind of cheap to say that java eliminates the memory errors associated with C and C++. I can count on one hand the number of times I have had problems with array overruns, wild pointers, or multiple deallocations combined. The reason is good technique and style- two things that seem to be missing in most java programmers toolbox.

As far as not allowing multiple deallocations you hit the nail on the head. In fact, Java does not even allow multiple finalizations of an object! This might sound silly but realize that it is possible to resurrect an object once it has been collected. Given it is considered bad form to resurrect objects but I want the finalize method to be called each time its object is collected.

Java is coming to the age where it should be stablizing and not improving. There is a lot of exciting stuff happening in C++ but not because they are improving the language but rather people are learning to use it in different ways. Given, I do not think people will discover new exciting ways to use Java (it is too similar to known established languages) but if the language was frozen the benefit could be better Java literature and a much injection of good technique and style.

As far incompetent programmers go they can screw up anywhere. Part of the problem is that anyone can learn some fraction of a language and be called a programmer. I think the problem is even more rampant in Java because it is considered a user friendly language. There are too many bad Java books out there. It is hard to learn good technique and style in Java with no prior programming experience.

Re:And for anybody who doesn't believe...

[mcbevin]

Say for example you have a static HashMap in some class, and you keep on adding stuff to it without ever removing old stuff when its no longer in use.

Note that I said _very bad java programmers_ leak memory :).

Re:And for anybody who doesn't believe...

[furball]

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.

This is the reason for the Java certification. If your JVM meets the requirements then it can be called Java compliant. If someone goes off and install an uncertified JVM they gamble on it working according to the spec.

If it only walks like a duck but doesn't quack like a duck it's probably not a duck to begin with.

Re:And for anybody who doesn't believe...

[tigersha]

> For Windows perhaps. But if you're going to > confine yourself to Windows, why bother with Java?

Get friggin real. I have an app that I wrote that uses JWS and it works out of the box, without any problems on Linux, MacOSX and Solaris. I develop on Linux and it just works on Wiondows.

And the really cool thing is the program installs on the client's desktop and when I publish it on our server, the desktop app automatically updates itself. On all of the above OS'es.

Re:And for anybody who doesn't believe...

[Anonymous Coward]

The fundamental problem is that you cannot control how memory gets used. For example: the JVM allocates memory from the underlying OS in chunks which it then doles out to your app as necessary. Then at garbage collection time, the memory is reclaimed from your app and returned to the JVM. But then the JVM may or may not ever return this memory to the underlying OS. This means that even if you have a tiny application, when the user opens a mammoth 100MB document just once, the application will continue using 100MB even after the user has closed the document.

*psst* This is true for any memory allocation routines that you may happen to use, regardless of language.

Re:And for anybody who doesn't believe...

[danharan]

lmao... thanks, that makes sense now!

That is pretty damned clueless, though I've seen some frightful stuff in some teams, so I believe some people would do such a thing. Ironically, those that would might be the most likely to protest about garbage collection not letting them control what's going on... :)

Re:And for anybody who doesn't believe...

[Lodragandraoidh]

We have seen the garbage collector not work under these conditions. We presume it has to do with the GC not being able to access whether a particular instance will be accessed, and thus does not collect it. The application is a service that is continually running (for all intents and purposes the loop is endless).

In all cases the application eventually locks up, and we see out of memory errors in the logs. We tried enlarging the memory allocated to the application - but this only postphoned the inevitable.

I will concede there could be something else going on inside of the loop that defeats the GC algorithm - but I am not sure what it is (could be a linked list that points to the objects etc...). All I know is something inside of the loop is defeating the GC - hence my statement.

Re:And for anybody who doesn't believe...

[groomed]

Java Web Start, atleast the one from Sun, is available on SPARC, Solaris X86, Linux, Mac OSX, and Windows.

Did you ever actually use it?

Java Web Start "works only if the client machine has version 1.3 or later of the Java Runtime Environment installed."

In other words, it's a Java app installer that requires that you have Java installed.

As a programmer, I can write in Java and know it will run on multiple platforms.

That was never contested. The issue is that most classes of desktop applications run poorly in cross-platform fashion, due to deployment issues, GUI and UI issues, and/or the use by the app of technology that exists isn't cross-platform, because Pure Java doesn't cut it (which .

Since java is backwards compatible this means your incompatibility version issue is not really an issue.

It's not really an issue until something breaks, yes. Even if Java itself remains backwards compatible, that doesn't mean there won't be versioning issues between the OS/environment and the Java runtime, leading to application problems. The LD_ASSUME_KERNEL mess on GNU/Linux comes to mind.

Regardless, even Sun itself recommends that you deploy applications using the Java runtime that you tested the application on. After all, the backwards compatibility is a best-effort thing, hardly a guarantee.

Re:And for anybody who doesn't believe...

[KillerCow]

Personally, I believe that there was an issue with old JVMs (at least on Linux) leaking memory, that has now been solved

There was. Very old JVMs used to have problems GCing objects that circularly referenced each other. At least I was told so by some job interviewer once when I looked at him funy after being asked the question.

Re:And for anybody who doesn't believe...

[Torne]

The standard Sun JVM has a 'perfect' garbage collector; in this context, perfect means 'always collects exactly what is garbage'. It doesn't miss anything. If you are finding something not being collected, then you have a reference to it. Probably a conveniently invisible one. ;)

The GC doesn't care whether you're looping or not; in fact, there is an asynchronous GC (one which runs simultaneously to your program) now available for experimentation...

Re:And for anybody who doesn't believe...

[Big Boss]

DNS?? What support do you feel is missing? I've never wanted for anything more than to be able to connect to a name as well as an IP. I can connect to named machines just fine...

Network interface support could use some help. But it's not that big a deal. I recently ran into an issue with this for an FTP app I wrote. I simply added a config option to specify which interface (by IP address) to use as "localhost" for things like the PORT command and binding sockets to. Not so different from how I've seen it done in Linux with C or C++ apps. Works perfectly.

Not to say Java is perfect, but it works well for what we do around here. Mostly server side DB backed apps. We also have a few client apps being written in Java that show no major performance issues.

Re:And for anybody who doesn't believe...

[Anonymous Coward]

It's about the number of bytes wasted. Java wastes memory because it reimplements code that exists as a shared library.

You're funny. You could just as well say C++ wastes memory because it reimpmlements code that exists as a shared library. So does C. So does Fortran. All languages have their core libraries.

Java wastes memory by not sharing memory between applications.

Not true since 1.5/5.0 or whatever's currently in beta

Java wastes memory by not returning memory to the OS once it's no longer used by the application.

Not true since a long long time. 4-5 years.

Re:And for anybody who doesn't believe...

[Mybrid]

My experience as someone who works with enterprise Java is as follows:

1. Impeadance mismatch. In electronics hooking a 4 ohm speaker to an 8 ohm amplifier output results in a power loss because of the impeadance mismatch. Same is true in software. Hooking a virtual OS into a real OS results in a power loss because of different underlying assumptions. The result is not just a performance loss but a performance fragility. A change in the load on the parent OS can have dramatic penalizing performance degradation for a JVM. Especially when real memory is exhausted the swapping occurs. The JVM with its constant garbage collection defeats the paging algorthm of the OS. They work against each other.
2. Multiple JVMs. The JVMs don't play well with each other with regards to performance and interfer with each other's performance. Our company often has to have a minimum of two JVMs, one with secure and another with non-secure data.
3. Application servers. So, the JVM is insufficient and cannot be run directly from web server invocation. The deficiencies inccur a penalty called a web application server making web application server a misnomer. It is not an application server. It is yet another layer of OS abastraction to provide long running transactions for web usage. The right answer would've been to augment the Unix operating system to provide C/CGI with a security model and memory system for web services. Instead, Sun sold out Solaris with Java and paid the price. Sun has virtually none of the web application server market.

Just my opinion of course!
Cheers!

Re:And for anybody who doesn't believe...

[Anonymous Coward]

But that is the two-edged sword. All Java apps look and function like Java apps - no matter the underlying OS. My Windows' users want apps that function like all other Windows apps they use - same for the MacOS crowd. Swing only ensures that we can put a pretty somewhat native-face on the code.

The Windows users should not care that its a Java app and thus people they don't know who run the app on a Mac will get the same experience. This is the flaw of Java Swing.

Chip

Re:And for anybody who doesn't believe...

[shadow_slicer]

Yeah, the latest versions of Azureus are really nice. It runs smoothly on my machine and doesn't seem to be slowing down other apps at all (an improvement over what I was seeing in 2.0.4, but it could be the 2.6 kernel which I adopted about the same time...).

But it's still Java, and so that means it eats memory for breakfast. If I use gtop (top says 20% for each of the 4 currently active java processes, but that doesn't have much meaning to me...) to check the memory usage it shows that the Java processes (with no other Java-based apps running -- checked using "ps -Af | grep java | grep -v Azureus") has a resident size of 7432128k, a shared size of 5953872k, a total size of 22875472k, a virtual size of 23247480k, and a swapped size of 15551328k. None of the other programs (including X which has mapped my Video memory) comes close. X is only using 23684k/276220k/291204k/290040k/266356k. Since I only have 512 MB of RAM it's kind of ridiculous for it to allocate that much memory...
It also has used more CPU time than X, but with all the hashing it does I would expect that.

Re:And for anybody who doesn't believe...

[Anonymous Coward]

So, with the exception of JBuilder (which is very heavyweight, there's no denying)

As are Mozilla and WinWord...

Azureus, nice little bittorrent client (shows up as javaw.exe): 22MB working set, 80MB pagefile.

Based on working set, that puts it at 9/69 processes. Not too bad, but still up there. Still above XMLSPY, trillian, MSDEV, foobar2k, SciTE, HydraIRC - all arguably equally or more complex programs. Two versions of firefox/bird, two mail clients, acrobat reader, and some obscure stuff beats it.

Based on pagefile, that puts it at 2/69 processes. The only thing higher is Mozilla Firefox with 3+8 tabs open.

And this is when it's sitting there, not really doing anything.

Re:And for anybody who doesn't believe...

[Anonymous Coward]

Azurues uses SWT. SWT is not Swing. SWT uses native widgets.

Then how come it still looks like a GTK reject? And why is sorting by column so slow?

Re:And for anybody who doesn't believe...

[Anonymous Coward]

and anyone that believes that "java is too slow" may wanna take a look at www.intellij.com ..

Depends on how its coded it seems .. !!

Re:And for anybody who doesn't believe...

[civilizedINTENSITY]

Insightful? Comparing the installation of Java to "priming your fuel pump everytime you want to drive somewhere" or "calibrating your derailleur gears before you can use your bicycle"? Lets be real, OK?

Your analogies would do better if used for the VM startup time. That is something that has to be done "everytime you want to" start it up for the first time. In terms of installation, if Java is required, why hasn't the sysadmin already installed it?

In terms of throwing people off the project who would specify run-time pre-reqs...does this include MS Office? MySQL? IIS or Apache? Would you insist on writing a webserver so that one wouldn't need to be installed?

HAH! Oh so not acceptable!!

Re:And for anybody who doesn't believe...

[Rich0]

adding RAM is generally very cheap.

In general, yes, but it depends. It becomes quite expensive once you need more than 4 GB, since at that point you need to move to a different, and still expensive, architecture.

I just set up an AMD64 system and paid about $600 for the entire thing. That was for 512MB RAM. DIMMs that size are selling for $75 each - that price adds up fast for a desktop. Given a program that eats up 100MB and one which eats up 20MB, I'll pick the one which uses 20...

Also, while AMD64 lets you run as much RAM as you want, you'll find that Java is VERY buggy on AMD64. I have to run most of my java apps in a 32-bit environment as a result. Blackdown-jre isn't too bad on AMD64, but it doesn't run everything, and it still tends to crash frequently.

As somebody running a non-mainstream platform I'd normally be a big fan of technology like Java, since it potentially brings me more software. In reality, however, it doesn't always work all that well on some non-x86 hardware.

Re:And for anybody who doesn't believe...

[sbrown123]

In other words, it's a Java app installer that requires that you have Java installed.

Um...yeah. Whats your point? Java Web Start is part of the java runtime from Sun. If you go to www.java.com and "Get Java" you'll get Java Web Start too. Just think of it as a bonus feature.


The issue is that most classes of desktop applications run poorly in cross-platform fashion, due to deployment issues, GUI and UI issues, and/or the use by the app of technology that exists isn't cross-platform, because Pure Java doesn't cut it


Ive used Web Start for some time now. I click on the app (either in a web page, desktop icon, or directly in Web Start), Web Start downloads the app and checks for updates, and than it launches. If the app uses Java Swing, it looks and operates the same on all platforms. Once the app is download it is saved on your computer.

As for technology thats on one platform thats not on another I can only hazard to guess you are talking about something like using ActiveX in Linux or something. Hell, dont use ActiveX if you want to be cross platform. Duh. But pure Java itself has no functionality that is platform specific which is why its cross platform.


The LD_ASSUME_KERNEL mess on GNU/Linux comes to mind.


Thread libs always been a bitch. What does this have to specifically do with Java? I know some old java virtual machines dont work right if you dont set the environment variable. But than again lots of old non-java programs wont either.


After all, the backwards compatibility is a best-effort thing, hardly a guarantee.


Yeah. Thats why there is a testing phase when you build applications. But in six years I have yet to see a pure java app NOT cross-platform 100%. Im sure you'll say Im just lucky. Luck or not, until than its kinda hard to sway me to believe otherwise.

Re:And for anybody who doesn't believe...

[groomed]

You could just as well say C++ wastes memory because it reimpmlements code that exists as a shared library. So does C. So does Fortran. All languages have their core libraries.

Pretty much all apps on GNU/Linux that need SSL end up using openssl. Except Java -- it has to have its own implementation. There are many examples like that, Swing probably being the most egregious one.

Not true since a long long time. 4-5 years.

It's true for 1.4.1 on GNU/Linux. Maybe 1.5 fixes it, I don't know, I've pretty much given up developing with Java for the desktop.

Re:And for anybody who doesn't believe...

[sbrown123]

As I already stated if you want native look-and-feel widgets go with SWT (or even AWT) instead. One mans fortune is anothers loss. You have to pick.

Re:And for anybody who doesn't believe...

[sbrown123]

Then how come it still looks like a GTK reject? And why is sorting by column so slow?


I can only guess you must be running KDE. SWT, the last time I checked, uses GTK widgets on Linux. I have no idea if they are gonna write one for Qt.

Re:And for anybody who doesn't believe...

[Doctor Faustus]

Swing though always looks the same no matter what the platform is. This means Swing apps look and operate the same no matter what the platform.

This is a negative, though. People care about having an app that looks like whatever else in on *their computer*, not that the app looks the same to them as it does to someone running it on a washing machine somewhere.

Re:And for anybody who doesn't believe...

[Anonymous Coward]

Also this part is just wrong: " In fact, many java applications that run for extended periods of time leak memory to the point of exhausting all system memory."

Those aren't necessarily leaks. Leaks are when you allocate memory then lose access to it, so you can't free it up when it's not needed.

What is described here is just applications not letting go of resources after they're not needed. They aren't leaked, though. The developer just didn't design the application with the expectation of extended use.

The developer probably could rewrite the application to limit the capacity of certain arrays or lists or caches in the program, causing old items to fall off and become eligible for garbage collection.

But again, this isn't about leaks.

Re:And for anybody who doesn't believe...

[groomed]

Um...yeah. Whats your point? Java Web Start is part of the java runtime from Sun. If you go to www.java.com and "Get Java" you'll get Java Web Start too. Just think of it as a bonus feature.

The point is that it is exactly one of the integration issues which keeps Java from being adopted as a platform for desktop apps. It's madness to require users to download and configure a 15MB runtime just to run your app.

But pure Java itself has no functionality that is platform specific which is why its cross platform.

There are so many cross-platform issues it isn't even funny. From minor things like cosmetics to major accessibility problems due to widget focus getting messed up. From minor things like system configuration to major things like data interchange between apps. Things like font management and things like widget z-ordering.

Pure Java is so limiting that you just can't write a decent cross-platform desktop app in it, except in the narrowest sense of "with work, it runs". You always need to spend a considerable amount of time writing platform specific code to solve the integration and deployment/packaging issues, or your app will look bad.

This is an area where Java simply has failed to deliver. The fact that you think it's no big deal to, say, download a Java runtime, only serves to illustrate the train of thought that lies at the root of this failure.

Re:And for anybody who doesn't believe...

[SageMusings]

Oops,

Be careful, I said the same thing a few weeks ago and was told I was just a mediocre programmer.

By an idiot AC, no less.

Re:And for anybody who doesn't believe...

[FriedTurkey]

I use Boland JBuilder 9 Personal Edition and it does everything I need for free. I do servlet programing. Just add the appropriate jar files and I am compiling servlet. Compile it right to server and just test with a web browser. No debugging is available for servlets but I just write out values to the console. Its really easy to use and I have found no reason to switch at this point.

Re:And for anybody who doesn't believe...

[bXTr]

- java applications are difficult to install
This is the developers problem

Sure, just tell the users to install Java. Problem solved. My ass!

- java applications start up slowly
As with any interpreted language, and has been an issue since Qbasic. Accept it.

You might accept it, but your users wont. Never worked as a developer for a living, have you?

- 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.

Not everybody has a gig of RAM. You want to make everybody upgrade? That's so M$-ish.

- 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

Bullshit. Java's garbage collection was supposed to take care of this taking it out of the developer's hands completely.

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.

I agree, Java's a great operating system. I just wish it had a decent progamming language for it.

Re:And for anybody who doesn't believe...

[achacha]

I would disagree (with your disagreement) about the install, it's not difficult to install JVM per se, but to install it without clobbering the other applications that will not run in your version of the JVM has been a difficult road to travel. If all the companies using Java as a platform agreed not to stick their version as the default, add their JVM to global path and on and on; it may be bearable, but that is not the case. I can't tell you how many times I had an application written by Borland or Oracle (just to mention large vendors who should know better) start up and kill my eclipse debugger (process just vanished, ghost process left behind). At this point we use many Java based apps from major vendors and I can't run a lot of them at the same time, they require diffent JVMs and it seems different JVMs don't co-exist together very well (this is on Windows 2k and on Windows XP). This alos was enough to tarnish my faith in Java. I hate to keep track of which JVM which install uses so that I don't have to keep losing application (mostly they just vanish with no error message).

The worst part is that using 1.4.1_03 is not compatible with some apps using 1.4.1_02 (some major vendor even requires people to uninstall 1.4.1_03 and reinstall 1.4.1_02 or it would not run, but we needed 1.4.1_03 for another app... these are the dilemmas of the corporate contracts with vendors providing software that they only tested on bare machines with 1 JVM).

This is nothing of how slow they run and the gigantic footprint they have. 2GB is barely enough to run 2 or 3 apps before realizing that my HDD is thrashing. I work with Java and it has a lot of nice ideas, but overall I am not impressed with it.

It makes me sad to see this, but it also makes me hopeful that one day C/C++ will over-run Java and people will go back to learning how to write compact, efficient and clean code and all the new Java developers can either learn or go back to flipping burgers... I am jaded by all the bad developers I have encountered when dealing with Java... sorry I know there are a lot of great ones too. :(

Re:And for anybody who doesn't believe...

[sbrown123]

It's madness to require users to download and configure a 15MB runtime just to run your app.


Thats only true if your app can only be acquired through download. If you distribute your application on a CD what is 15M? And the download is only a 1 time download for all java apps. You get the same thing with having to have users download the 20M .NET framework to run .NET apps. Users have no problem downloading the much larger Mozilla time and again. For music swapping people thats like 3 songs? Geez.


There are so many cross-platform issues it isn't even funny. From minor things like cosmetics to ....


Wow, talk about serious FUDding.

Apparently you never coded in Java. This became obvious when you wrote the line "considerable amount of time writing platform specific code". How the hell do you write platform specific code in Java? Please, Im sure anyone who actually knows Java is really curious how you done this amazing feat. Theres JNI but thats only found in like .001% of all Java apps. I write apps for all sorts of platforms and I never, ever, seen the problems you falsely claim.

Re:And for anybody who doesn't believe...

[groomed]

If you distribute your application on a CD what is 15M?

That's true. Kind of weird for what was supposed to be the Web-language of choice, but true nevertheless.

Wow, talk about serious FUDding.

Sorry, I encountered each of those issues. Either you never wrote the kinds of apps I wrote, or you just don't appreciate the problems, the way you don't appreciate that having to download a Java runtime is a problem.

This became obvious when you wrote the line "considerable amount of time writing platform specific code".

You need code to do something elementary like get/set a file's creation date for christ sakes, let alone to provide the sophistication and polish that users expect from a normal app.

I never, ever, seen the problems you falsely claim.

Then you either haven't been using Java for a very long time or tight integration with the host environment wasn't a requirement for your apps.

Re:And for anybody who doesn't believe...

[necrognome]

Yep. Only difference is Java apps are growing in numbers whereas theres often no new Cobol apps.

Java is COBOL with better marketing.

Re:And for anybody who doesn't believe...

[sbrown123]

That's true. Kind of weird for what was supposed to be the Web-language of choice, but true nevertheless.


Are you talking about applets? Hardly anyone creates them anymore. Those are so 90's. What cave have you been in?


You need code to do something elementary like get/set a file's creation date for christ sakes


Unix, Linux, etc do not keep track of file creation date (try stat to see). Writing an app to run on these OSs that checks for creation date screams STUPID. This is also WHY ITS NOT IN JAVA. If a function existed than java would not be portable.

let alone to provide the sophistication and polish that users expect from a normal app.

And what, dare I ask, should developers use to write applications that have this sophistication and polish you spoke of for multiple platforms and OSs?


Then you either haven't been using Java for a very long time or tight integration with the host environment wasn't a requirement for your apps.


Tight integration kills portability and produces large, sloppy, and hard to maintain code that needs to be constantly updated to keep up with even the simplest hardware upgrades. Even Mozilla developers stated that they wanted to move away from that level of integration because they "were losing fingers and toes" trying to maintain it and keep it portable. That could also explain why it took so many years to get it where its at today. This is why languages like C and assembly are not in large demand. Professional programmers and IT staff know the dangers of what you are advocating. Your gonna find it hard to push them snake oils nowadays.

Re:And for anybody who doesn't believe...

[jrumney]

You need code to do something elementary like get/set a file's creation date for christ sakes, let alone to provide the sophistication and polish that users expect from a normal app.

Creation date, on the few filesystems that support it, should be immutable IMHO. It is supposed to be the date a file was created, not what some idiot developer wants to make it. If you're looking for a date to use as a timestamp for a file, try File.setLastModified(), which is more appropriate and cross-platform.

Re:And for anybody who doesn't believe...

[jrumney]

The JRE has always been redistributable. Even the JDK is nowdays.

Re:And for anybody who doesn't believe...

[Anonymous Coward]

java by no means has a "huge" footprint compared with other typical applications I use.

No, java by no means has a "huge" footprint compared with other typical applications you use that have "huge" footprints(you compared java with the largest applications on your system). How big would the footprint of those Java applications be if they were not written in Java?
I have both cgoban and cgoban 2 on my machine. cgoban 2 is written in Java, and cgoban is written in C. Loading up both applications, logging in to the game network, and observing one game shows 38M RSS used by java, and 2.3M RSS used by cgoban. So moving from C to Java increased memory usage of the application by a factor of more than 15 for this use case. In my book, that is huge.

Re:And for anybody who doesn't believe...

[wfberg]

People care about having an app that looks like whatever else in on *their computer*, not that the app looks the same to them as it does to someone running it on a washing machine somewhere.

No, people don't care about that at all. Webpages are all different, some underline links, some don't, some use flash, others don't, the user-interface is all over the place. Do people care? No! People actually like all those applications that you can "skin" in order to make them look even more different and counter-intuitive.

People care about getting things done. A consistent GUI helps people figure out how to get things done. But they don't care about GUI consistency (whether on one platform, or cross-platform) as long as it's obvious how everything works.

There are exceptions; copy+paste should ALWAYS work, and people will go to great lengths to complain about "ugly" looking applications, and right-mouse-clicks should always pull up context menus (although I've seen apps that use the right button for something else and succeeded in not being completely annoying once you got used to it). But in general; what gets the job done, quickly and easily.

Re:And for anybody who doesn't believe...

[groomed]

Writing an app to run on these OSs that checks for creation date screams STUPID.

Any kind of archiver type tool would need to be able to read and modify these properties. The API simply isn't (or wasn't, I stopped caring around 1.4) any good.

And what, dare I ask, should developers use to write applications that have this sophistication and polish you spoke of for multiple platforms and OSs?

Nothing. They should either target each platform separately if they want polish or create faceless/rudimentary applications if they want wide deployment. The snake oil is the notion of write-once run-everywhere.

Tight integration kills portability and produces large, sloppy, and hard to maintain code that needs to be constantly updated to keep up with even the simplest hardware upgrades.

It also produces apps that people like to use. Isn't that the point?

I don't see what hardware has to do with it. But one should commit to a platform, yes, whether that means committing to a particular version of the Java runtime or committing to a particular CPU ISA or committing to a particular appliance architecture -- it doesn't really matter.

Even Mozilla developers stated that they wanted to move away from that level of integration because they "were losing fingers and toes" trying to maintain it and keep it portable.

They are losing fingers and toes because they tried to shoehorn all platforms into a single codebase on top of an abstraction layer, just like Java.

This is why languages like C and assembly are not in large demand.

That's as may be, but that doesn't explain the piss poor demand for general-purpose desktop Java apps.

Re:And for anybody who doesn't believe...

[RetroGeek]

MyEclipse plugin

I just read through their Subscription Terms

They are nuts!

A $30 fee every year or the software stops working!! Shades of IBM mainframe licencing.

Looks like a good product, but I will NOT get into that sort of payment schedule!!

Re:And for anybody who doesn't believe...

[dnoyeb]

If that happens then the JVM does not conform to the Java specification.

There are lots of new GC technologies these days, and some algorithms are better than others under certain conditions.

The GC problem you see has less to do with the loop, and more to do with the fact that you are staying at the same stack level. GC has to work harder to know that variable is collectable since its former spot is still active. JVMs I use all eventually free the memory.

One small point. The Java specification makes it very clear that an out of memory error MUST NEVER be thrown if there are collectable objects around.

Re:And for anybody who doesn't believe...

[sbrown123]

Any kind of archiver type tool would need to be able to read and modify these properties. The API simply isn't (or wasn't, I stopped caring around 1.4) any good.

If you need to change the creation date use JNI in Java (Java Native Interface). Kills portability but, as you said, portability doesnt matter. So if you were trying to say its not possible in Java you were wrong.

Polish? I am guessing your idea of polish is the GUI? If so, a Java developer could simply use SWT. SWT uses tight integration to the native desktop where it runs which means Java GUIs that are as fast and look 100% the same of anything you could create in C, C++, etc. In other words, theres nothing special in the GUI department that Java can't do.

but that doesn't explain the piss poor demand for general-purpose desktop Java apps.

Azureus is one of the most downloaded apps on Sourceforge. Seems your point is wrong there like so many others you've attempted....

Re:And for anybody who doesn't believe...

[ShinmaWa]

SWT, the last time I checked, uses GTK widgets on Linux

Actually, it has both GTK and Motif bindings on Linux.

I have no idea if they are gonna write one for Qt.

Very, very unlikely. Qt's dual licensing nicely prevents that.

SWT was written for use in Eclipse. Eclipse is open source and distributed free. But! Eclipse is also sold as part of closed source software such as WebSphere Studio App Developer.

If SWT had Qt bindings, commercial products developed from the Eclipse codebase would require the purchase of a Qt license from TrollSoft. That would seriously encumber of the value and the purpose of the Eclipse project.

Re:And for anybody who doesn't believe...

[Bert690]

1. Java does not have support for DNS in its main classes as recent as 1.4.x (need to look at 1.5). As such it is not suitable for any more complex network software period

Uhhh...wrong. Java has had support for domain name resolution (and reverse DNS lookup) since its inception! Sure it doesn't have ability to do fancier stuff like dynamic DNS updates in its main classes, but neither do any other mainstream languages. Languages such as C++ don't even have support for Sockets in their "main classes", so this is a rather weak criticism even if it were remotely true.

2. Java network interface support is not platform independent. As a result any application that needs to bind to a specific interface on a multihomed machine needs to have external config or to be platform dependant which largely defeats the idea of using java in first place.

Wrong again! It's trivial to iterate over the set of network interfaces on a machine and bind to a specific one. One of my apps uses this functionality, and it works perfectly on multiple platforms (including linux, mac, pc, aix, ...)

Try again cluesink...

Re:And for anybody who doesn't believe...

[Bert690]

The GUI is poorly _emulated_ and does not even use the complete Win32 GUI subset, instead creates it's own litle API that you can apply themese to.

Hey dumbass... azureus uses SWT which is *entirely* based on native widgets. Emulated my ass.... Did you even try it? What app does use "the complete Win32 GUI subset" and why does it even matter? Yes I tried resizing it, I saw no "GUI inconsistencies". I somehow doubt you even tried it, or maybe you're just high?

Re:And for anybody who doesn't believe...

[groomed]

If you need to change the creation date use JNI in Java (Java Native Interface).

Yes -- you need to escape from Java in order to be able to do many useful things. This illustrates Sun's failure to deliver on the write-once, run-anywhere promise.

So if you were trying to say its not possible in Java you were wrong.

Of course it's possible. But having to write glue code to interface with the system is hardly what I'd call a Java "advantage".

If so, a Java developer could simply use SWT.

SWT is pretty good. The question is: why didn't Sun come up with SWT?

Simple -- because it didn't fit into their vision of what Java ought to be. The problem is that their vision has proven to be radically misguided not once but twice.

Azureus is one of the most downloaded apps on Sourceforge.

A single swallow doesn't make summer.

Tell me, how many Java apps do you use on a regular basis, that are not related to your work or development activity?

Re:And for anybody who doesn't believe...

[Anonymous Coward]

creates it's own litle API

"its".

Re:And for anybody who doesn't believe...

[sbrown123]

This illustrates Sun's failure to deliver on the write-once, run-anywhere promise.

Hahaha. Your just being silly now. Not having the creation date in the api actually PROVES Sun's ability to deliver a language that is write-once and run everywhere. If they put creation date in than it would not be portable. You do understand that "write once run anywhere" stands for portability right?

Of course it's possible. But having to write glue code to interface with the system is hardly what I'd call a Java "advantage".

Java's advantage is portability. Duh. Glue code is only needed when you want to do something non portable. Most Java programmers never play with this since the very extensive java libs cover almost everything imaginable.

Tell me, how many Java apps do you use on a regular basis, that are not related to your work or development activity?

Lets see: 2. But I only use like six apps. So thats like a third are written in Java. A year ago there were none.

Re:And for anybody who doesn't believe...

[Anonymous Coward]

Only a mediocre programmer would say something like that.

Re:And for anybody who doesn't believe...

[groomed]

If they put creation date in than it would not be portable.

There are lots of ways they could have approached the problem. They could have provided an API like File.setProperty(String what, Object value) and fail gracefully for non-existant properties. Or more fundamentally, Java could have provided the ability to send arbitrary messages to objects, Objective C style.

Most Java programmers never play with this since the very extensive java libs cover almost everything imaginable.

No, Java programmers don't play with it because their world pretty much stops where the class libraries stop. Which is why their applications never seem to quite fit in with the rest of the environment.

Re:And for anybody who doesn't believe...

[Anonymous Coward]

BUT what people dont get is why Swing exists

absolutely - what swing gives you is apps that look nothing like the apps you're used to seeing.

Run windows, you want apps to look the same, not like 'java applications'. Run GTK, you want apps to look like 'GTK applications'.

Swing is crap because of this.

Re:And for anybody who doesn't believe...

[gbjbaanb]

...adding RAM is generally very cheap.

well, my main customer has 500 desktops, even if half a gig of ram is £50, that makes.. quite a bit of money. Not to mention the cost to get a engineer to install it. (half an hour per PC, £15 per hour maybe).

If I went to my customer and said, I've developed that extra functionality you wanted, and I used this cool java language, they wouldn't be too happy if they had to spend all that money to run it.
Don't forget that development cost is budgeted for, PC upgrades due to ram-hungry apps, that you only find out about after development is finished, are an additional cost that simply may not be possible.

Re:And for anybody who doesn't believe...

[iwadasn]

Wow, this is pretty harsh. There's a few things you miss out on though. First of all, don't compare java apps to programs from Microsoft that are part of the OS. One of the primary reasons java is so heavy is that few things are written in it. If it was part of the OS, and more programs were written in it, then that 10 MB overhead for the VM just doesn't look so bad when spread over 20 processes. A lot of C programs are like this too. If you use the standard libraries (the ones everyone else uses), then you take a much smaller hit in memory size because most of your code is shared. If you use a non-standard library, then you get screwed. It's not very valid to compare two standard libraries against each other when one is spread over a dozen apps, and the other is spread over 1. It's like a chicken and the egg problem. If more stuff was written in java, then each program would take a smaller performance/memory hit. Unfortunately, not many desktop app developers want to be the first one.

Secondly, no java installation problems on OS X. I think you're referring to the foolish (or malevolent) choice made by your OS vendor to refuse to bundle any code that prevents platform lockin. That can hardly be blamed on Java, especially considering that Sun did all the work for them and then made it free, but said vendors refuse to bundle it because they want to have complete control over the "one true way." If your vendors made the same choices about standard libraries, you'd be in the same trouble. This isn't unique to java.

Keep in mind that pretty much all modern programs are absolute pigs. Mozilla is one of the worst ones ever seen, supposedly this is due to STL generating countless subtly different copies of the same code that then bloats up the memory use. Being a pig is not a monopoly held by java apps. Furthermore, how much control do you think the Mozilla developers really have? Didn't they write a front end that renders their own windows using some sort of markup language? Does that sound like an act undertaken by somebody who feels that fine grained control is very relevant?

Re:And for anybody who doesn't believe...

[iwadasn]

"You should compare a Java text editor to a native text editor"

Yes, go compare. JEdit is one of the better text editors around. They unfortunately try to sell themselves as an IDE (of which they are on of the worst), but they make a good programmer's text editor. You should try it out and then talk about native text editors always being better. JEdit is roughly equivalent to slick edit or ultra edit, and it's free. It also runs on any platform I've ever tried it on (Mac OS, Linux, Windows), which is more than I can say for the others.

In my case, I pretty much insist on java for most of my tools because I like to be able to use the same thing at home. I have a Mac at home, and very few programs that aren't in java have a Mac version (no visual studio, for instance) so that pretty well determines my choices. I also use Linux computers at work when that makes sense, and it's nice to use the same tools there as well. It makes life much easier, trust me.

Re:And for anybody who doesn't believe...

[WamBamBoozle]

... 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.

Startup time is not a problem if you're always running Java. Running an applet from HotJava was very fast ... I'm sure startup time was terrific on JavaOS and JavaStations as well.

Re:And for anybody who doesn't believe...

[Doctor Faustus]

Programmers like writing skinnable interfaces. Has anyone really checked to see if the users like it?

Re:And for anybody who doesn't believe...

[Anonymous Coward]

MyEclipse plugin
I just read through their Subscription Terms
They are nuts! A $30 fee every year or the software stops working!! Shades of IBM mainframe licencing. Looks like a good product, but I will NOT get into that sort of payment schedule!!

You have got to be kidding. $30/year vs $1000-$3500 for something like JBuilder or JDeveloper? I know which one I am going to choose. You can actually get a lot of the functionality of MyEclipse by installing open source plugins for Eclipse, but if you are paid $25-30/hour, something like MyEclipse easilly pays for itself if it suits your needs. The subscription model means that they are more likely to be up to date and you automatically have access to the upgrades. Compare the app servers MyEclipse supports to the other products, its actually pretty impressive.

Anyway, I don't need to be selling their product for them here, but I think $30/year is very cheap for the productivity you gain.

Without plugins, Eclipse itself is still pretty impressive on its own, though.

Re:And for anybody who doesn't believe...

[Mr. Slippery]

My Windows' users want apps that function like all other Windows apps they use - same for the MacOS crowd.

Has anyone ever actually studied or polled user behaviors to check this common assertation?

My books all have different typefaces. My cars have had different dashboard layouts. Every piece of consumer electronics I've ever had has had different controls. Web sites all have different layouts. Somehow, most of us are able to cope with this variety of user interfaces without a second thought.

For most of my computer-using life, my programs have had different intrfaces. (These days, most of what I'm running is GTK stuff.) It's not been a problem.

False arguments of past not valid

[essreenim]

People thought it was going away because of all the stupid people saying 'Oh, c++ is much faster'
when in fact Java uses allot of native code that is actually compiled c code. Its often very fast.

Re:False arguments of past not valid

[Anonymous Coward]

There was a time when C++ was considered bloated and slow too. (Even as recently as when Gnome was being started.)

Re:False arguments of past not valid

[Anonymous Coward]

People thought it was going away because of all the stupid people saying 'Oh, c++ is much faster' when in fact Java uses allot of native code that is actually compiled c code. Its often very fast.

They're hardly stupid if they're correct. Java being `ofter very fast` doesn't make it faster than C++, especially when the C++ code concerned has been written and optimized for a given CPU whereas Java has to do compilation on the fly.

Re:False arguments of past not valid

[dnoyeb]

A Java virtual machine IS a c++ program. The comparisons are illogical.

I usually like to make this point 2-3 times when it comes up on slashdot once per month.

Re:False arguments of past not valid

[Glock27]

A Java virtual machine IS a c++ program. The comparisons are illogical.

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.

Re:False arguments of past not valid

[SillyNickName4me]

> If a Fortran compiler were written in C++, would that still mean generated executables couldn't be faster than C++ at numeric code? No.

Could? yes, but only if your fortram implementation is substantially better then your c++ implementation. If you use an equally decent compiler for both, then there should be no difference, esp. for the specific example you give (because numeric operations, while easier to express in fortran maybe, are not very difficult to translate and compile.

The point of the grandparent post is the following (strippign names of languages so you 'whatever language of choice' zealots don't take offense:

You use A to implement B
THen you use both A and B to implement C, and compare the outcome.

Now, because B is impemented in A, there is nothign B could do with C that A can't do with C.
There may however be things that A can do with C while B can't do them.

The simple conclusion is that B will not be able to provide a better implementation of C then A for the simnple reason that A can produce B if thats what is needed to achieve the desired result.

This all becomes more interesting when you can implement A in B and B in A.

Bottomline, when the fortan compiler is implemented in C++, then there is no way for it to generae code that won't be possible to produce with the C++ compiler itself.

Re:False arguments of past not valid

[Glock27]

Could? yes, but only if your fortram implementation is substantially better then your c++ implementation. If you use an equally decent compiler for both, then there should be no difference, esp. for the specific example you give (because numeric operations, while easier to express in fortran maybe, are not very difficult to translate and compile.

No, you missed (or didn't understand) this:

The stricter semantics of Java compared to C++ permit further optimization, as is the case with Fortran also, for instance.

The usual examples that are given are pointer aliasing problems, which C++ has, but Fortran and Java don't. In other words, it's not an issue of compiler implementation, but of language design.

The compiler could be written in any Turing-complete language, that's not the issue. The issue is the potential efficiency of the generated code.

Your overly simplistic argument of A vs. B. vs. C ignores important details of code optimization - as I tried to point out in my original post.

Clearer now...or not?

(Another point is that one could certainly write a C++ compiler in Java - would that mean that C++ couldn't possibly be faster than Java?)

Re:False arguments of past not valid

[essreenim]

They're hardly stupid if they're correct.
Java can be optimized to run on a specific platform too.
All I'm trying to say is some people blindly compare c++ and Java as programming languages whereas really Java is an extension of c in many ways, making this argument pointless!

Re:False arguments of past not valid

[SillyNickName4me]

> Your overly simplistic argument of A vs. B. vs. C ignores important details of code optimization - as I tried to point out in my original post.

Clearer now...or not?

It was already clear to me, but it seems you are entirely missing the point of my post here.

First of all, optimizing is a property of the compiler, not of the language, if you have a fortran compiler that optimizes a lot better then the C++ compiler, it is very likely to produce better code, no news there really.

What you are talking about is a limitation in the compilers you use.

Is it easier to optimize fortran well? I bet it is for quite a few cases, but I also bet that there is quite a bit of things you cannot do efficiently or at all in fortran without taking some big detour, so it all depends on the situation if that actually helps you or not.

Bottomline, both are compiled and assembled into some form of machine/bytecode. When you take soemthign that is implementable directly in both languages and have an equally well optimizing compiler, both will result in virtually equivalent machine/bytecode.

> (Another point is that one could certainly write a C++ compiler in Java - would that mean that C++ couldn't possibly be faster than Java?)

WHen you compile to the same target as the java compiler? nope. Given ideal implementations of both compilers, the result would be equally fast.

So language design? not really. compiler implementation is where the difference comes from, and that only in specific cases.

Re:False arguments of past not valid

[Charvak]

the grandparent is correct. in java some optimizations are possible because of language design. for example in java you can move memory, compactt it, reduce the fragmentation etc, which you cant do it in C++.

Re:False arguments of past not valid

[SillyNickName4me]

> the grandparent is correct. in java some optimizations are possible because of language design. for example in java you can move memory, compactt it, reduce the fragmentation etc, which you cant do it in C++.

Seeing how the JVM that allows this is written in C++, I am pretty sure it is implemented in C++, and as a simple consequence, also possible in C++.

That JAVA makes it easy to do is nice when you need this, but has zero to do with the performance argument.

Re:False arguments of past not valid

[Anonymous Coward]

you dont get it. do you ?

Re:False arguments of past not valid

[Glock27]

Seeing how the JVM that allows this is written in C++,

Or traditional compiler as opposed to JVM, as I pointed out. Neither is necessarily written in C++, BTW.

I am pretty sure it is implemented in C++,

Fine. However, the code that is running (machine code from the JIT, or natively compiled code from an ahead-of-time compiler) is not compiled C++ - it is compiled Java. Important distinction.

and as a simple consequence, also possible in C++.

In the sense that you could write stream of bytes to memory and then execute them from C++, true. In the sense of compiling C++ with an optimizing compiler to get the same performance, no.

That JAVA makes it easy to do is nice when you need this, but has zero to do with the performance argument.

Incorrect (and in fact you have yet to understand my point). Here are some references:

• COMPARISON OF FORTRAN AND C [note the parts about optimization]
• Performance of Java versus C++ [note 1) Pointers make optimization hard]

I hope that helped... Please read and understand both thoroughly before posting again. :-)

Re:False arguments of past not valid

[SillyNickName4me]

> Or traditional compiler as opposed to JVM, as I pointed out.

Well, its clear what you mean there, but eh, you can use a traditional compiler in a JVM if you'd want to.. At any rate, it is not that relevant if you use a traditional compiler or a just in time compiler (it may matter for how much time you have for doign your optimizing tho, a jit compiler that takes minutes to compile soemthing is not very acceptable, while it may be for a traditional compiler, so amount of time spent on optimizing can be wiildly different). Eliminating the JVM however by compiling to nativ4e machien code instead of bytecode can make quite a difference however.

At any rate, I mentioned that option a bit later when answerign your comment about a C++ compiler in JAVA. You are quite right to bring it up because it is like comparing apples and oranges otherwise.

Let me just answer it again tho because it is rather relevant to the point I am tryign to make here.

The only constrains that are not a result of imperfect implementation of compiler and optimizer are the limits set by your runtime environment. In a comparable runtime environment and with equally well implemented optimizers, writing equivalent code in two languages should result in almost or completely identical sequences of instructions to your VM or hardware.

> Neither is necessarily written in C++, BTW.

Nope, and in fact, the language they are written in only matters for how easy it is to write them well, but for the rest is irrelevant.

> Incorrect (and in fact you have yet to understand my point). Here are some references:

* COMPARISON OF FORTRAN AND C [note the parts about optimization]
* Performance of Java versus C++ [note 1) Pointers make optimization hard]

I hope that helped... Please read and understand both thoroughly before posting again. :-)

Interesting read indeed, tho I had seen the 2nd one before, and as you are probably aware of as (for as far as I know) regular slashdot reader, its claims are not undisputed either.

At any rate, this doesn't change that optimizing is an implementation detail of the compiler and/or runtime environment. Language design can make that job easier, sure, but it doesn't prevent good optimizing if you have the time for it. That time is a lot more readily available with traditional compilers then with JIT compilers but they can't take advantage of runtime optimizing that easily.

Note that it is all about hard/easy, not about impossible.

Re:False arguments of past not valid

[dnoyeb]

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.

Yes really. If you use a native compiler you will be running a program written in the Java language, but not running a Java program. Java is more than a language, its an environment. (an example is C# which is not just a new language above c++)

Yes, Java's runtime optimization gives it an advantage over many c++ programs. Of course you could write your c++ program to have its own runtime optimization if you wish. Again, c++ vs. Java is an illogical comparison.

I dont make the point 2-3 times to make it more right. I'm just helping out those who have not taken the time to understand Java as I have.

Source critique

[Kingpin]

One of the first things I was taught in college, was to be critic of the sources I based research on.

In the world of WWW, it seems that each and every article and blog entry can be used as reliable fact. "He wrote it, it must be true". If some nerd posts that language X is the best, and those who use it are really really smart (case in point Paul Graham/Pythong) - that really doesn't make it come true. Same goes for Java "dead or alive" etc. etc. (Naturally, we all know that BSD is in fact dying - this is the exception).

Re:Source critique

[KZigurs]

You must be joking. Looking how linux is sucessfully performing every possible action to fuck itself up even more (and I'm not talking about GUI's here, its not even worth mentioning) almost half of my friends that used to use linux on their machines now have replaced it with BSD.
Why? Because it simply works, it has two variants that have good documentation, so, if anything breaks, you really have a chance to use information found online (instead of looking at n solutions for n distros), no one asks them WHY they ARE SUCH A DUMB LAMERS to use that particular distro not THE ONE AND ONLY linux distro by some linux weenie.

Mark my words. BSD IS NOT dying. And in fact the fact that linux constantly fails to create anything but promises and rantings throught its user base, it silently grows and grows.

The fact that every news outlet isn't ranting about BSD doesn't means that it has fallen into oblivion. Smart kids know about that and are really happy 'bout that.

Re:Source critique

[Anonymous Coward]

It was (meant as) a friendly joke. Get over it.

Re:Source critique

[Jerf]

Your message seems to be lacking a point. It suggests being critical of sources in a vague and general way, but has no specifics about the current story.

Are you suggesting that we dismiss this merely because it appears on the web? That's not "sophistication", that's just falling prey to the same fallacy, only in reverse! The reality is that the "web" status is a null factor.

Paul Graham's qualifications are freely available online. While you of course can't therefore accept everything he says uncritically, he isn't even a good example of "some guy with a blog saying things". He's been around for decades, doing real work, writing books on complicated subjects, and while I can't know for sure, if I had to lay money, the odds favor him being much more experienced than you. (Which is to say, his comments can have the type of value you seem to desire, not that they must. I personally largely agree with him but there are plenty of people with equal or more experience I do not agree with, some of them very highly respected; as a concrete "for instance" I don't agree with anybody who believes that only static type checking by the compiler can produce quality software. That's a lot of very big names.)

Similarly, this author's qualifications are freely available online. While I'm not sure I'd trust him to evaluate why Java is doing well, or to evaluate it from a technical standpoint, he seems to me to be in a very good position to evaluate how the industry interest in Java is faring, certainly much better than my position. (On the other hand, the incompetent use of a "Google-fight" is disconcerting; again, I'm not advocating blind acceptance or rejection.)

You don't directly say "This can be dismissed because it is on the web", but you sure seem to strongly imply it. Did you not finish your post before you hit "Submit", or are you really advocating falling into the exact same fallacy you think you are warning against?

Re:Source critique

[Kingpin]

Point: Just because someone says it, doesn't mean it's true.

I refer to "the web" because you'll find opinions from anyone here, in contrast to eg. the library where the concentration of properly researched information is much higher. On the web lots and lots of people blurt out their random thoughts - there are clever bloggers too - but you have to be picky, thus the "source critique" title in my post.

I would take Paul Graham as a solid reference for eg. LISP. But his argumentation for why Python developers are smarter than developers for language X is subjective and unfounded at very best. Bill Gates has been around for a while too, but that doesn't make his "nobody will ever need more than 640k memory" statement come true.

I use the web as a reference, I gain lots of important knowledge and insight from the web - but I don't buy "X is Y" just because someone states it. You need to back up a claim (which is what I'm trying to do here). I dislike bloggers who use statements of other bloggers as if it were the one and only truth, and use that to go on a bashing spree.

Re:Source critique

[nosferatu-man]

Bill Gates has been around for a while too, but that doesn't make his "nobody will ever need more than 640k memory" statement come true.

Of course, but I feel the need to point out that Gates never said that.

I would take Paul Graham as a solid reference for eg. LISP. But his argumentation for why Python developers are smarter than developers for language X is subjective and unfounded at very best.

Subjective, yes, but not in any way unfounded. Graham has a long history of working with very, very smart programmers (and is one himself), so it behooves people who care about what smart programmers think to listen to his opinions. Which is not to say that he's going to be right about anything you quote him on -- although I happen to agree with him vis a vis Java -- but that his opinion is, by virtue of his experience, weightier than, say yours (or mine.)

'jfb

Is there a Sun campaign going on?

[Scarblac]

For quite a while, when Sun was mentioned here, it was often in the context of "they're dying, no new research, no future, no idea of how to compete with Linux", and things like that. I think the height of that was this article, which actually talks about who caused "the fall of Sun".

Now in the last two weeks, we see a steady flow of Sun-related articles. Java is being promoted (this article, and this two weeks back), there is news on Solaris ("Linux apps on Solaris", "Solaris coming to Power architecture"), there have been bits about their cool Sun Rays on Linux, their R&D with the chips without connectors, and rumours that they could buy a key player, Novell. There's also Looking Glass.

All in 11 days or so. It seems someone is screaming "Hey Slashdot, we're really alive!". You'd almost expect them to sue SCO next week just for the attention...

Re:Is there a Sun campaign going on?

[subVorkian]

The increase in interest maybe related to the Dead Cat Bounce .
Or maybe SUN is redefining who they are and promoting their software over their hardware.
I think it's an interesting time for SUN.

Java 1.5 should help things.

[Anonymous Coward]

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.

Re:Java 1.5 should help things.

[Anonymous Coward]

Pain in the ass? In what way? Setting up a Java dev environment is no more difficult than setting up an env. for any other language and it comes with a huge and useful library. This is especially nice for writing those small useful utilities. Like my own version of grep I wrote once to help me solve crosswords. It would have been a pain in the ass if I did it in C. Unfortunately the standard dictionary in Linux was not large enough :(

Re:Java 1.5 should help things.

[pjt33]

Java already has iterators. Did you mean foreach loops? As to autoboxing - IMAO that's the pain in the arse. It breaks some of the sanity properties Java's always had, for no real benefit. If people want to use primitives in collections, PCJ has been around for years. Generics and foreach are the main benefits of 1.5, although annotations may also turn out to be quite handy.

For those who haven't been looking at Java lately

[Coppertone]

Azureus: http://sourceforge.net/projects/azureus/
Eclipse project: http://www.eclipse.org

Java keeps quiet

[16K Ram Pack]

One problem is, no-one much hears about it. Sun rarely seem to trumpet what they are doing with it.

I don't do Java, but from what I've seen, it doesn't change much, and where it does, it adds to what was there before. That is IMO a good thing, that developers aren't sitting around poring over documentation, but are productive instead.

(One reason for not doing Java is the small number of companies doing Tomcat hosting).

Keyword being: Enterprise

[Moraelin]

Java is pretty popular on the server side, but client side it was always one monumental flop.

As applets go, for example, nowadays the whole program-inna-browser market is owned by Flash, followed by ActiveX. And for good reasons.

Starting with the fact that Java 1.0 was indeed a slow piece of crap for anything but the most trivial applets. Try displaying a complex table without a JIT, and you were talking about response times you could measure with a stopwatch, not with System.currentTimeMillis().

The initial lack of support for packing everything in a jar didn't help that cause either. Downloading 50 classes as separate files isn't particularly fast. And that's a very small project.

And for all the multi-platform hype, wasn't particularly portable either. If you tried running even a trivial AWT applet on different platforms, you wouldn't even get the same events. Or for something which required you to give a size in pixels on the web site, you wouldn't even get the same font sizes.

And by the time it caught up... meh. Flash is _still_ the better choice.

Not the least because of download size. Sun now includes all the crap they could think of as standard libraries. Do I need an XML parser to make a simple game applet? Not really, but Sun wants my users to download that crap anyway.

(No, it's not a made up problem. I've had modem users tell me literally "whoa, I'm on dialup. Is there some smaller version I can download?")

That's just a small slice of the many ways in which Sun started it on the wrong foot.

Re:Keyword being: Enterprise

[nick-less]

And by the time it caught up... meh. Flash is _still_ the better choice.

ah, that must be the reason why all of my homebanking is written in flash ;-)

Re:Keyword being: Enterprise

[Azghoul]

Good to see your slowing moving back down the mod chart... "Client side... was always one monumental flop" is pure myth. It's interesting that you seem to think "client side" means "in a browser window".

Run Eclipse sometime.

Re:Keyword being: Enterprise

[Anonymous Coward]

Do I need an XML parser to make a simple game applet? Not really, but Sun wants my users to download that crap anyway.

Flash also contains an XML parser.

Re:Keyword being: Enterprise

[Pfhreakaz0id]

Eclipse is great, i love it ... on my work machine with 2gb of ram. On my home machine, it's pretty much unuseable. This is an 1800 athlon with 256 mb of ram that is prefectly responsive for every other thing I do with it (web, email, wordprocessing, gaming, ok, not doom3, but still).

Re:Keyword being: Enterprise

[Anonymous Coward]

Sorry, Eclipse doesn't really count as a Java client app. It doesn't even use the built in GUI framework! Its a good thing too...if it did use Swing it would probably be a slow bloated worthless piece of shit. I'm all for Java on the server, I generally like the language, but I've never seen a Swing application that I liked.

Re:Keyword being: Enterprise

[Sunspire]

Eclipse is great, but no thanks to Sun. IBM went ahead and developed their own native widget because it was painfully obvious to everyone with eyes in their heads that both AWT and Swing were crap. Sun's been bitching and moaning ever since and they still don't get it.

With the exception of Eclipse and Azureus (both using SWT) Java on the desktop has been an abysmal failure. If it was up to Sun it would have been dead and buried a long time ago. There are however a few things that could revive the Java desktop platform:

1. Open Source Java, allowing it to be distributed with Linux.

2. Allowing bundling of the JRE with end user applications, you just can't expect users to download it themselves. If you believe that you just haven't spent enough time with end users.

3. Be ready to make some hard decisions or watch Java rot from the inside. What the hell is up with the ridiculous "generics" implementation, now we're stuck with this autocasting-lite crap for the foreseeable future because Sun didn't want to modify the VM even a little. Very shortsighted of them.

However Sun won't do it, because there's no profit in it for them. However that's nothing new, it seems like everyone else is making money with Java except for Sun. I predict that in a few years IBM will be the defacto Java driver.

Re:Keyword being: Enterprise

[Moraelin]

What did you want me to do? Write a whole tome worth of everything that ever was wrong with Java client side? I did say "That's just a small slice of the many ways in which Sun started it on the wrong foot."

Believe it or not, I've been in client side application projects. I also have Eclipse open right now.

In fact, Eclipse is the prime example of how Sun started on the wrong foot. SWT (the widget set used by Eclipse) is IBM's work, while AWT and Swing are what Sun had in mind. The words "dumb and dumber" come to mind, when I think about AWT and Swing.

Want one thing that an actual client complained about? We had to program the same very small app in C _and_ Java, on Windows, Linux _and_ MacOS. Well, the whole package were more apps, but this was the only part which had to run on all desktops.

The client's first comment? "Whoa! Why does the Java version need 16 MB of RAM, when the C one is less than 1 MB?"

Another project was a bigger Swing "thick client" database program. In Swing. You know what the first complaint was? The look and feel. Inconsistent fonts, inconsistent keyboard shortcuts, etc. Sun's "Windows" Look and Feel is a sick joke. We ended up doing more work to write our own look and feel, just to get the program to look like a native app.

Yet another way in which SWT got it right, while Sun screwed up.

The second complaint? Performance and memory use. 'Nuff said.

Also, believe it or not, bigger companies have tried moving to Java on the desktop. It was every company's wet dream to suddenly only have to maintain one version, and work on every single OS. Some of which they didn't even support before. Everyone tried it.

E.g., Corel at one point wanted to move their whole office packet to Java.

Why do you think Microsoft got so scared and wanted to kill Java? Precisely because of this. It looked like all of a sudden everything will be multi-platform, and the "but this and that runs only under Windows" advantage will evaporate over night.

What happened to all those projects? They flopped. They ended up slow, bloated and more unstable than their Windows counterparts. So everyone moved back to C/C++.

If that doesn't count as a monumental flop, I don't know what does.

Re:Keyword being: Enterprise

[easter1916]

Yeah, I'd recommend a half-gig for it to be usable. I run it on a 1GHz 1GB Powerbook G4 and it's fine.

Re:Keyword being: Enterprise

[angel'o'sphere]

Come on guy ... make your hme work!

1) It is allowed to distribute Java with Linux, albeit it is not Open Source.

2) The JRE may be distributed with any app you write in Java. Thats exactly the point why there is a difference between JDK and JRE.

3) Generics and templates have not much to do with modifying the VM. Alternative Java compilers like Pizza allways had "templates" and/or "generics" and run on the very first VMs.

Nevertheless you are right with the your stand regarding generics ... they are pretty useless and no computer scientist really understadnds why Sun refused to use a more template like approach.

angel'o'sphere

Re:Keyword being: Enterprise

[Anonymous Coward]

Actually that has bee covered to death in many of the dead-tree sources. The reason Sun choose the brain-dead generics is because it required no change to the JVM itself.

I guess they figured it was better to have junk with the same JVM rather than something useful, but requiring a major overhaul of the JVM.

A curse upon Sun for that decision.

Chip

Re:Keyword being: Enterprise

[anomalous cohort]

Run Eclipse sometime.

That's not all. Other J2SE apps that I personally use are...

• IsaViz is great for visualizing and validating RDF
• ArgoUML is a pretty decent UML editor
• FreeMind is a great Mind Mapping tool.
• Gantt Project beats MS-Project if all you need is Gantt charts.
• Protege is very impressive for editing OWL files.

Re:Keyword being: Enterprise

[Anonymous Coward]

256 MB??!?? For god's sakes, get some RAM.. You can't run any serious IDE in 256 MB without a lot of pain. Hell, I run with 512 MB at home and I'm suffering. Get at least 1 GB if you want a responsive IDE (goes for any of the current heavyweight IDE's)

Re:Keyword being: Enterprise

[MarkCollette]

I think that the whole Flash versus Java Applets thing is a good lesson in learning the difference between strategies.

Flash tried to be the best platform for bringing dynamic content over the web. And so it did that. And won.

Java was shoe horned into Applets, with little regard for what people try to do in web browsers. So it didn't do what people needed. And failed.

Anyone remember what it took to get an Applet to print or save data to the hard disk or play sound files, back before the Java Plugin? Remember how IE and Netscape had different, incompatible security models? What a fiasco. It's obvious that someone made a little animation demo, showed that to marketing, and they were like "We can revolutionise the web!!!" ...

Non-the-less, we have Java to thank for popularising the sandbox mentality, which ActiveX so completely lacked.

Re:Keyword being: Enterprise

[jrumney]

The client's first comment? "Whoa! Why does the Java version need 16 MB of RAM, when the C one is less than 1 MB?"

Because it is more efficient to allocate memory in large contiguous chunks. There are options to tune the initial and maximum heap size if it really makes that much difference to you.

Re:Keyword being: Enterprise

[Anonymous Coward]

Flash! LOL! Only an idiot would make anything than a simple game in Flash. Most people I know block anything that is flash in there browser through the use of plugins. Flash is garbage and cannot be compared to a fully featured programming language.

Re:Keyword being: Enterprise

[Anonymous Coward]

What kind of app would it count as in that case? C? C++? Perl?

Java is not back.

[Cyberax]

It's just a marketing.

Java language has stagnated in about 1999 with the release of J2SE 1.2 (dubbed Java 2); new J2SE 1.5 (Java 5) is just a cosmetic change of language (yes, I consider current implementation of generics/annotations to be 'cosmetic').

It's quite OK to be conservative, but you can't conquer the world of IT being conservative. Java's position on server-side is still pretty firm, but desktop apps in Java (apart from Java IDEs) are non-existant.

And Microsoft's position on server-side is strengthening. So Microsoft will prevail if nothing changes in the recent future :(

Re:Java is not back.

[LarsWestergren]

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.

Re:Java is not back.

[Baki]

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.

Re:Java is not back.

[Anonymous Coward]

.NET's solution to backward compatibility is for you to install every version of the runtime side-by-side. In other words, it isn't binary back-compatible and doesn't pretend to be.

In practice Java's upwards-compatibility doesn't really work despite the hoops Sun has jumped through to maintain it -- for example, trying to run an application developed against 1.5 on a 1.2 JVM is probably not going to work. Sun should just get over it and extend the bytecode when useful to do so (generics) and have the users download the correct JVM.

Re:Java is not back.

[flibberdi]

I wont complain too much regarding the j2ee (or even j2se), but j2me..... I am telling you, I have 2 phones, and I can tell U it's not easy to find working java application for them. It's not like, "down load this if you have a java phone", it's more like "if you have this phone, download this, if you have that phone, download that, this application doesn't work with those phones bla bla bla. I have to spend to much time trying to find the right download for my phones. How the developers feels... I found an informative blog which sums it up.

Re:Java is not back.

[StrawberryFrog]

.NET is years behind and plans to bring similar features only in 2007 (generics).

Uh, I think that's wrong. The whidbey release of .NET, with generics, is due in early 2005, is it not?

It remains to be seen if they can do it without breaking backwards compatability.

Nope, the betas are out, so anyone can see, and they haven't found that to be the case. And support for generics was always planned in .NET, and thus apparently is techincally superior to the kludge that was retrofitted to the Java VM.

Re:Java is not back.

[Cyberax]

Notice, 1.2,1.3 and 1.4 only have different libraries and different JVM implementations. That's not what we call language development.

And J2SE 1.5 is just a frantic attempt to add some sugar into Java language.

Re:Java is not back.

[Cyberax]

JDK1.5 is not 100% backward compatible, because some new keywords were introduced.

And it's not hard to extend bytecode to be backward compatible AND effective (i.e. allow pointer arithmetic, fixed pointers, etc.). Look at J# in DotNET and IKVM in Mono, they can execute Java bytecode on a completely different platform.

Re:Java is not back.

[Daltorak]

Uhhh... sorry to interrupt your rant, but Generics are coming to .NET much sooner than 2007. In fact, they are coming with .NET version 2.0, which is already in beta.

Here's the MSDN documentation for Generics. Also, Generics in VB.NET 2005.
Here's the download of the .NET Framework 2.0, Beta 1. Free.
Here is the public beta of Visual Studio 2005, which includes full support for Generics in C#, VB.NET, etc. Free.

So, there you have it. Generics are available to developers in 'public beta' form for both Java and .NET. They aren't "years behind" at all... Java will probably get 1.5 out a few months before .NET 2.0 will be completed. It's also clearly shown from the documentation that Generics in .NET 2.0 do NOT break backwards compatibility with code written for 1.x of .NET.

Some friendly advice: Next time, before you write another clueless rant about .NET, make sure you've got your facts straight.

Re:Java is not back.

[Anonymous Coward]

I agree. It seems some morans do not do reasearch and just spread FUD they read somewhere.

Java's generic support is very poor. Try doing List and behind the scenes you get List and every element you add is boxed in Integer object. That sure will help performance.

Re:Java is not back.

[LarsWestergren]

Notice, 1.2,1.3 and 1.4 only have different libraries and different JVM implementations. That's not what we call language development.

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:

void cancelAll(Collection c) {
for (Iterator i = c.iterator(); i.hasNext(); ) {
TimerTask tt = (TimerTask) i.next();
tt.cancel();
}
}

into this:

void cancelAll(Collection<TimerTask> c) {
for (TimerTask task : c)
task.cancel();
}

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:For those who haven't been looking at Java late

[mikera]

I second that..... been using Eclipse for my open source Java game and it's superb.

First time I've ever felt that I had a decent free software IDE as a developer.

It went to million servers and clients

[struberg]

and thats not bad.
Consider, that java is not only the language itself, but also the whole environment!

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.

Re:It went to million servers and clients

[dnoyeb]

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

Re:It went to million servers and clients

[Anonymous Coward]

Well I think I could easily write a pure Java program that would not run in 1992. One of the problems with Java is library creep (that is why I do not understand Sun's unwillingness to change the JVM because of backwards compatibily). Can't run a Java Swing program with a Java JRE 1.0. Of course, the problem goes beyond Swing. People seem to love Java's library but I think it is one of its biggest weaknesses- it is too big and a moving target to boot. Something like C++'s STL is much smaller and I find it generally more useful.

Re:It went to million servers and clients

[struberg]

You are true with your argument. But from a developers point of view, it is most important to not have to change your own code if u dont like!

I do technical project management more than 10 years. In the beginning there were people who know what computers may do - and people (mostly managers who do the 'cash' part) who absolotely do know NOTHING about computers.
And this was very good that way....

Nowadays 'cash' managers do believe they know what programming is about, and permanently try to insist for making technical decissions.

Almost all of this kind of management fuzzis think 'hey we've got mono', 'now lets do all things cheaply with Windows and then port them to Unix'

Most 'normal' manager really believe, that Microsoft .net programs may run 1:1 on Linux, HP-UX, AIX or whatever, and that's the really bad part about mono...

I'll called my platform ".COM"

[Vo0k]

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

versus .COM
(1940 000 000 results)

Re:I'll called my platform ".COM"

[LiquidCoooled]

Pah! anything less that 3 billion hits is dead.

Since, I don't like C#, and think c++ is too advanced, heck, even C and b completely confuse me, I think I'm gonna call my language "a"

Results 1 - 10 of about 3,610,000,000 for "a"

Re:I'll called my platform ".COM"

[Joseph Vigneau]

Good to see COMMAND.COM, MORE.COM, and EDLIN.COM are all live and kicking.

Hmm....

[Anonymous Coward]

Mind if I recomend Inferno from Vita Nuova instead of Java for embedded applications? Can run within a megabyte of memory, is fully cross-platform (unlike Java, it really is cross-platform), and has so many other advantages. Check it out.

As is the case with most languages..

[Kjella]

A secondary issue for Java is the barrier to entry is extremely high: sure you can learn the language quickly but it's Java's libraries that add the real value.

I did try Java. I think the main reason I didn't stick with it in retrospect is the feeling that you have to run a beast of a VM to do "Hello World!". Now I program in C++/Qt.

That is to say, I don't program in C++. I barely know pointer artihmetic, templates, exceptions, the standard library, callback functions and a host of other things. Not that I don't value their usefulness, but he high-level workings of the Qt library is a lot more valuable to my needs. And that'd take me just as long time with Qt or with Java's class library.

Worst case so far: Three long recursive function calls replaced with 7 lines of code combining several "advanced" library functions. Going back to look at old code is a horror show.

Kjella

Re:As is the case with most languages..

[CountBrass]

You know, I can't remember the last time I was asked to deliver a product that printed "Hello World" so whether or not the JVM is too heavyweight for such an app' is moot. And even if it was: throw more hardware at it. Hardware is cheap. Maintaining code is expensive and C++ has a much higher maintenance overhead than Java does (pointers, object ownership, misused multiple inheritance - the list goes on).

Re:As is the case with most languages..

[jrumney]

I did try Java. I think the main reason I didn't stick with it in retrospect is the feeling that you have to run a beast of a VM to do "Hello World!". Now I program in C++/Qt.

If all of your programming has the complexity of "Hello World", then you made the right decision to steer well clear of Java. But some of us are writing real world programs, where the "overhead" and startup time of the JVM is insignificant.

Re:As is the case with most languages..

[Anonymous Coward]

You know, I can't remember the last time I was asked to deliver a product that printed "Hello World"

Keep in mind that a high % of slashdot readers are CS101 students that ARE asked to deliver Hello World products.

Re:As is the case with most languages..

[sfmarco]

Dude,

We are not comparing C++ with Java
but we are comparing (.NET) C# with Java!
Actually it's just your favourite language on the CLR against Java on the JVM.

On the favourite lanugage list is C#, C++ (for old time gurus), Visual Basic (?), Python, and even Java (limited edition)

Versus just Java.

Java Swing is beautifully overdesigned and makes it a pain for good IDE support. Compare that with the ease of Visual Studio .NET

7 years ago I always hoped that Sun would come out with some good Java GUI. Good as in: high performance, tightly integrated with the native OS. Seems that only an IBM effort with the SWT was an attempt to solve this.

It was all too late. Sun is searching to get Java into a niche market (Phones, embedded software, server side) before all is gone.

Interestingly today there on ./ there was also a posting on MONO. And it is getting as much attention as the Java article.

The new new thing has won. The Java coffee is cold.

Marco

Re:As is the case with most languages..

[Anonymous Coward]

Keep in mind that a high % of slashdot readers are CS101 students that ARE asked to deliver Hello World products.

Wait, are you trying to tell me that my CS101 projects are not representative of the projects people work on in the Real World?!?!

This writer is into amateurish journalism

[nysus]

He bases part of his argument that Java is less popular than .NET by doing a Google fight between "java" and "net"???

Java can be a coffee or an island in the Indonesia. Net is a device to ensnare animals and is a verb as well.

And he cites a blog item from a Sun executive as proof that Java is back? Please. The article is nonsensical.

Re:This writer is into amateurish journalism

[pjt33]

Part of? It's a couple of hours since I RTFA, but I don't recall him having any other argument that Java is less popular than .NET.

In addition to nets as trapping implements, consider the common "sentence"

import java.net.*;

Re:This writer is into amateurish journalism

[Spoing]

...or .net as in "http://www.mysite.net", though Google will return search results for '.net' with ones that match 'net.' as well. It's useless to even mention the results of a query like this...so why do it?

Re:This writer is into amateurish journalism

[zacl]

I'm not sure if the author of the "editorial" could be considered a journalist. Although the copy is both poorly written and shorter than most README files that I've seen, the real problem with this article is that the author fails to construct any sort of logical agrument to support his opinion that, "Java is back!" He cites:

1) Google hits "java" vs "net"
Completely asinine, as has already been discussed on /. It's probably safe to say that
Geelan has blow his credibility. May I suggest omitting "valuable" research like this from future articles, or, if not, at least have the self-respect to make the citation obviously tounge-in-cheek (perhaps by googling for "java sucks", "java rules", etc).

2) Jonathan Schwartz's blog entry
Almost worse than the "googlefight." Citing a blog may be a fine for something like another blog post, but can it really be considered support for the author's argument in this case? Perhaps an interview with Schwartz would have been appropriate...

3) Quote from David Berlind, ZDNet journalist
Berling says Java is a good choice. Who cares? Who is this guy? Does anyone else share my opinion that ZDNet is a sub-par news source?

4) San Jose Business Journal VC numbers
For those who hadn't already tuned out after the author made his dismal first point, Geelan finally presents a solid, logical defense to his argument. Java penetration is exploding on mobile handsets, and could be well poised to become a platform of choice for a wide range of devices from enterprise-class servers to smartcards. Geelan would have been well served to frame the entire discussion by leading with this argument.

Let us not forget that on the internet, no one knows that you're a dog; and thus a reader should always consider the source. In this case, one could guess that Geelan has a background in marketing and/or business development rather than some sort of strong technical background. The article does make more sense from a business/marketing perspective, but as a technical editorial, however, it falls flat. I doubt many well-informed techies would agree that "Java is back!", because it was never gone.

Re:like a turtle

[Donoho]

got bored watching

Microsoft is a master at switching enough labels to "keep things interesting". New bells and whistles to hold your attention. (I'm a sucker for a pretty interface) Kind of makes it seem like Java isn't moving at all. Java never left and it's not going to "die". It is a young language that has survived and grown on its own merits and not through billions in marketing hype and R&D and despite it's creaters over protectiveness. It's just getting started.

Either the tool you're using allows you to get the job done or it doesn't. Either the tool improves over time to make your job easier or it doesn't. If you want to see Java thrive, use it.

Catching up to the hype...

[ChangeOnInstall]

All good but overhyped technologies do this. It works like this: The sponsor of a technology hits a home run in the media with hype, and everyone jumps on board thinking it's the silver bullet they've been waiting for. Then reality shows up, and all those who bought the unrealistic expectations generated by the hype jump ship, and the media reports on the mass exodus from the technology as though the technology has failed. Meanwhile the technology is still growing steadily as the real users find it suits their needs well. Its capabilities expand and it matures, and then it starts to become widely adopted. And then finally it's good enough to live up to the former hype, and everyone thinks "it's back!"

It's not living up to the expactations we have for it five years from now today: it's dead.
It's finally living up to those expectations after five yerars: it's back.

Java, Linux-on-the-desktop, XML, and many more fit this pattern.

why bother arguing

[thebdj]

This is another one of those horrible things that happens every once in a while on slashdot. This argument is about as big as MS v. Linux or AMD v. Intel or ATI v. nVidia (for those who care).

The fact is you have some people who are super java fan boys and will stand by it until the day they die and most of them probably haven't programmed enough in other languages to say anything but the few bad experiences they did have.

Don't think I am letting the C/C++ programmers off either. I am one of them and I will be the first to admit I have hardly ever used java, but I have also had enough first-hand bad experience to not want to use it.

The fact is that people will stick with they know best and odds are whichever you learned first (java or c++) that will more than likely be the one you spend the majority of your time working with. So half the people can continue to rip on java now and the rest of you can praise it. I do digital design so I don't care enough about code to get into this argument.

--
"The same thing we do every night Pinky; Try to take over the world!"

Re:why bother arguing

[gov_coder]

I concur. I think if folks actually try some of the newer java apps out there they'll be surprised how light and fast they can be.

One of my favs is Quarbon - 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:why bother arguing

[acceleriter]

And who can forget Azureus, the app that convinced me that cross-platform Java apps don't have to be slow and clunky.

Re:why bother arguing

[Vengeance]

Hmmm.

I have, in various jobs, done coding in BASIC, C, C++, Visual Basic, Java, and a host of scripting languages and such.

If I stuck with what I learned first, I guess I'd be in trouble, because I kinda started out with interpreted BASIC, followed shortly thereafter by 6502 assembler...

Re:why bother arguing

[thebdj]

*poke* look at my original post. i specifically said java or c++. we all started with something easy. i learned basic, then pascal before c/c++. then i got to college and learned a bastardized c (thank you OSU) and several assembly languages.

Re:why bother arguing

[Vengeance]

Owww! Stop poking me!

Re:why bother arguing

[alcmena]

Ahhh yes, the joys of Resolve. Don't you just love it when your school invents a whole new language for the sole purpose of ensuring that you will never graduate with real world skills?

Java is NOT slow

[Rik Sweeney]

How come whenever Java is mentioned people think of Swing and Web Applets?

Re:Java is NOT slow

[downbad]

Because the only time most people come into direct contact with Java is when they have to wait 10 minutes for a 20MB Yahoo Chess crapplet to load.

Re:Java is NOT slow

[Dewin Cymraeg]

Horses for courses.

Three things have changed: broadband has meant that applets are not as slow to load as they used to be; machines have got faster; and JVMs have got better (including plugins).

In the project I'm working on (I'm a Java developer, mostly servlet/JSP/struts) we're deploying an applet to provide a richer user experience which HTML alone would not provide. I would not have dreamt of providing this solution even a year ago.

The applet is very usable, only takes a second to load the first time it's used (and thereafter is cached) and the user has a better experience of our product. We're telling our customers to use JRE 1.4.2.

The trick is to use applets when they are appropriate. This is, after all, true of all technologies.

I believe that eclipse http://www.eclipse.org/ and netbeans http://www.netbeans.org/ have both made a huge contribution to showing how Java applications can be used for serious development projects. There is now a huge amount of support for the Java development community, with lots of free libraries (Apache Foundation rocks http://www.apache.org/!) and some great stuff coming out of Sun (Java Server Faces).

Put it all together and you have a very rich environment for creating serious multi-tier applications using web or application front-ends.

For me, the icing on the cake would be the development of a forms standard which allows application-like front ends with a web architecture. Maybe XForms? XUL? This is what our customers want. Combine it with a strict and workable MVC architecture and it'd be my perfect development environment!

Difficult to install? Use Advanced Installer for J

[Anonymous Coward]

That little app will generate a setup.exe that will:
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:like a turtle

[Anonymous Coward]

If you want to see Java thrive, use it.

I could care less if it thrived, It seemed to fill a niche when it was created and I've written my share of apps in it but now I find other languages have begun to replace it (J2EE is an exception here as it's not the Java most users have come to know and curse)

Even better!

[Anonymous Coward]

It gets even sillier than that: Fox News wins the Googlefight "Fox News anti-american" vs. "BBC anti-american" 56 100 to 51800!

http://www.googlefight.com/cgi-bin/compare.pl?q1=F ox+news+anti-american&q2=BBC+anti-american&B1=Make +a+fight!&compare=1&langue=us/

Stop moaning sweetheart

[essreenim]

It doesnt "look" good at all
Let the Flamebaiting begin:
Azureus is cool. What are you using Windows? You desserve what you get if you complain about it and you use Windows....You certainly sound like a Windows XP user or something. Java has its own original look and feel that is difficult for Windows buffs to accept. If you are clever you will focus on how it works not how it looks.

Re:Stop moaning sweetheart

[SillyNickName4me]

> You certainly sound like a Windows XP user or something.

Smae issue applies when using Linux/FreeBSD/OpenBSD/NetBSD/Solaris/Irix/AIX/HP-U X or any other OS..

> Java has its own original look and feel that is difficult for Windows buffs to accept. If you are clever you will focus on how it works not how it looks.

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?

And before you repeat what you said about looking at how it works instead of looks, you may want to take into account that the UI also dictates how a user operates a program, and as a result, how the user abnd program work together. Ensuring it fits in with the environment the user is using will make it a lot easier for the user to work with it, so it works better. Conclusion, even if you ignore the graphical aspect, it not workign the same as the rest of the UI is still a problem.

How often do you have to hear 'it looks uggly' before you realize that it is maybe not a valid technical issue in your world, but is somethign that matters to people? It would eb a really really really good idea to go try understand the issue.

Re:Stop moaning sweetheart

[Anonymous Coward]

That how MS has managed to dupe the average non-techical user into using the insecure, cobbled togather mess that windows is. Put the garbage in a pretty package, heavily market it and just to help ensure success, use illegial monopoly practices to take away choice.

Never judge a book by it's cover...........

Re:Stop moaning sweetheart

[lucas teh geek]

use illegial monopoly practices to take away choice.

I'll tell you what I choose. I choose to have a consistant look & feel across my desktop, whatever OS I'm using. java does not fit into that choice

Re:Stop moaning sweetheart

[Undertaker43017]

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

Re:Stop moaning sweetheart

[Anonymous Coward]

Looking & behaving like a native OS app is great, especially for consumer applications. However that really isn't a priority in the enterprise (where Java is strongest). It's a "nice to have" not a "must have". Just take a look at SAP or pretty much any enterprise portal project.

If you are doing development for OS X, just use Objective-C... that is more fun anyway. :-)

Re:Stop moaning sweetheart

[Anonymous Coward]

UIManager.setLookAndFeel(UIManager.getSystemLookAn dFeelClassName());

Done!

Re:Stop moaning sweetheart

[SillyNickName4me]

> That how MS has managed to dupe the average non-techical user into using the insecure, cobbled togather mess that windows is. Put the garbage in a pretty package, heavily market it and just to help ensure success, use illegial monopoly practices to take away choice

Maybe you'd care to reread my post, or are you suggesting that this applies to KDE, Gnome, Aqua and a whole host of other user environments that try to give a consistant look and feel?

Again, just try to get it into your head that people like their computer to look and work in a consistent way, NO MATTER THE OS.

Re:Stop moaning sweetheart

[SillyNickName4me]

> Looking & behaving like a native OS app is great, especially for consumer applications. However that really isn't a priority in the enterprise (where Java is strongest). It's a "nice to have" not a "must have". Just take a look at SAP or pretty much any enterprise portal project.

Uh no. having the same look and feel as any other app are very important for applications you use every now and then, and almost irrelevant for an app that you use almost all the time.

It is not such a problem to learn to use a different way of interacting if you are gouing to use it most of the time anyway.

To use somethign every now and then that works entirely different from the stuff you use often however takes quite some efford each time you use it.

If it is worth to put in the efford depends, but for many peopel the choice is simple: If 2 things do what they need to an acceptable level, they will take the one that they are most comfortable with, and that will without exception be the one that looks and feels the most familiar.

You may not liek that, thats fine. Please use what you think best for your situation, but at least try to understand what motivates the average user in their choices if you try to argue about that.

Re:Stop moaning sweetheart

[SillyNickName4me]

> UIManager.setLookAndFeel(UIManager.getSystemLookAn dFeelClassName());

And that actually works? If so.. I suggest you go inform all those JAVA developers out there who can't seem to manage.

Re:Stop moaning sweetheart

[Anonymous Coward]

Speaking about consistent look and feel, maybe you can be consistent with the spelling of the rest of the population. Why the hell should your spelling look out of place?

Re:Stop moaning sweetheart

[Undertaker43017]

I agree, but the project that this thread is about is a consumer targeted product, so perhaps some effort should be put into making it more "native feeling". In Java that isn't too hard to do.

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:Stop moaning sweetheart

[Anonymous Coward]

"And that actually works?"

Yes, that actually works. Being a Java programmer I myself never really understood why most Java programs don't use the system look and feel. The new look and feel system for Swing is very well done (especially on OS X) and looks almost native on all platforms however most Java programmers don't seem to use it. Is there a reason why most Java programmers don't use this?

Re:Stop moaning sweetheart

[SillyNickName4me]

Well, all I can say is I hope to see more of it. I have no issue with JAVA as a language (I have with how SUN manages it, see the java related article on my weblog for that). If it integrates well with my desktop environment, I don't see why I shouldn't be using JAAVA applets.

Of course as someone mentioned, this is pretty irrelevant for the server side of things, but heh... we were talking about user interfaces here ;P

Re:Stop moaning sweetheart

[SillyNickName4me]

What population? if you mean the US population.. I'm not living there, but I do know it was them who couldn't manage writing Englsh like the rest of the world so they ahd to make their own variation on the spelling ;P At any rate.. don't like the message so shoot the messenger eh?

Re:Stop moaning sweetheart

[Anonymous Coward]

Yes that actually works, and for the record, I went to DeVry :)

Re:Stop moaning sweetheart

[SillyNickName4me]

Well, good, go tell the JAVA world now please ;)

Re:Stop moaning sweetheart

[Anonymous Coward]

Never judge a book by it's cover

"its".

Did it ever go away

[malsdavis]

Probably been already mentioned.

But when did Java actually 'go away' for it to "return". Sure, it doesn't have its new cutting-edge, wonder kid programming language status of a few years ago.

From what I've seen working for a couple of big companies is that Java usage has been steadily increasing, with Java now being at its most used ever (as one would expect if new software built on it gets steadily released).

Also, nearly all universities I know of now teach IT students Java as default.

Not sure what that means about its life, but considering most these companies now using Java apps were previously (just before switching to Java) using Fortran and C programs from the 1980's, I don't think it is going away soon.

Mobile???

[Akimotos]

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.

Re:Mobile???

[greg_barton]

Note the bit of cognitive dissonance here. The poster talks of Java being big and slow, then says it's "strong" running on mobile phones, a small low power platform.

Anti Java bigots think quite illogically at times.

Re:Mobile???

[Anonymous Coward]

Based on your comments, it sounds like your sister isn't the only one who "knows shit about computers".

Re:Mobile???

[Akimotos]

Sorry, Netscape 6 must have given me the wrong impression then regarding Java. I remember it as slow and one HUGE download. For me, it were those ISDN days with a brand new computer....

And yes, I admit I was surprised finding such a heavy platform (again: my personal perception) running on such small hardware.

I must also admit that I'm very disassapointed at it, because running a high performance Java app, sucks power more quickly from my battery then running full screen video (eg Shrek 2). So it might run on small platforms, but quite top notch is something else.

Re:For those who haven't been looking at Java late

[WWWWolf]

Yup. Eclipse is just about the best IDE I've used, and SWT kills other Java GUI toolkits dead.

And Azureus is quite definitely the best bittorrent client ever devised. =)

Now, if only Eclipse 3 would eventually hit Debian - and getting Azureus on Debian would be pretty cool too (proggies that come with their own swt.jar tend to be severely sluggish to start for some reason...)

Java vs ".net -site:.net"

[hitchhacker]

Java vs .net (excluding all .net tld's)

65.6 million for "Java"
22.4 million for ".net -site:.net"

.. still unfair though. What about relevant .NET websites w/ .net tld's

-metric

Re:Java vs ".net -site:.net"

[hitchhacker]

Nevermind.
Google ignores the initial period in .NET.

-metric

No Star Wars joke?

[Fr05t]

No Return of the Javi jokes? I am very let down :(

And anyone putting white text on a black screen

[Anonymous Coward]

to make their "argument" must not be as smart as they think they are. That anti-java op-ed piece for konspire2b was hard to read, and I have 20/20 vision. The authors spent too much time lambasting java instead making a webpage that is accessible to people with low vision.

Hint: never use a light font on a dark background.

java and linux rocks, .Net is like flakey VB/COM

[Anonymous Coward]

I have been coding for 12 years and Java for the past 7 years java jas been the most rock solid language, scalable platform to me the portability is great from windows to linux. When we switched all our 500 windows desktop to linux our internall java apps was our saving grace it worked like a charmed.

Elipse is the best IDE and weblogic/tomcat best appserver. .Net is still very buggy like VB stuck in com world with and you are stuck in windows for ever . It is buggy full of holes like IE. Mono is not .Net and M$ will pull the SCO thingy on mono sooner or later.

The Reason Java 'appears' slow,

[tonywestonuk]

There is this concept called MVC (or model view controller) That is regarded as the way to develop OO based GUI apps. However, pure MVC is the biggest stumbling block to performance.

The idea is, you have a VIEW (The actual GUI Code), that reads it's data from the MODEL, ( a data structure modelling the data that is viewed, and a CONTROLLER, that the view notifies when something happens, and then the controller updates the Model.

This, though well suited for a Web application, does not work well in a windows type environment. Consider for example an order entry screen consisting of 10 dropdown combo boxes, Buttons to add an order line, Tabs to show different areas of the order, (delivery address, customer credits, etc). Now the data model for this screen will be massive - each combo box's entire list of values will be stored within the single Model. On start-up, first the view will be rendered, then the data contained within the model copied into it. This process takes time, and makes the guy unresponsive and sluggish. In a Web application, this is not a problem , as the data has to get to the browsers some way or another.

With Java Swing, there is an alternative - Encapsulate the individual components with the data it requires to display, and only store within the external Data Model, the actual value that the component is set to. Eg, if you want a combo box with a 100 or so currencies to be selected, store the list of currency information, together with the combo box..... Call it a currencySelector or something. The 'Data Model' is still there to contain the actual chosen currency, just not everything else!

This way, you can cache up these components, so when added to the screen, no time is wasted moving all this data from the data model into the component. The data model becomes much smaller, and the components become fully re-useable.

The Swing applications I have written use this technique, and are easily as responsive as a native Windows Application....

Untill industry realises that MVC is not all its cracked up to be, we will be stuck with slow gui's.

As a Side note, Mac OSX uses MVC throughout , maybe this is why Aqua is view to be so slow.

Re:The Reason Java 'appears' slow,

[argent]

Java's got a lot of problems in the standard class libraries and type model. When I started working on it I found the lack of dynamic types and the inconsistent classes are a big problem: I wanted to write wrapper classes around everything just so I could get the bookkeeping out of my hair. Apple's Objective C class libraries (Cocoa) have the same problem to a certain extent, even with dynamic types to help.

I'm not sure that MVC is the problem, though. It's been widely used in a variety of systems since the late '70s on processors that aren't even pocket-calculator quality today. The Smalltalk I played with in 1982 was running on a Dorado that must have managed all of a million instructions per second, and my NextStation (however that's supposed to be capitalised) has a very responsive GUI on a 68030... it actually feels faster than OS X on a G3/400. Java's implementation of MVC may be particularly bad, but the inherent overhead in the design can't be that great if machines as anemic as these can manage it well.

I would put the responsibility for Aqua's performance squarely on the shoulders of Quartz. Quartz is a high quality rendering engine, but to get decent performance out of it you need a good video subsystem and enormous amounts of memory to copy and composite the high resolution pre-rendered bitmaps... not to mention enough processor time to do print-quality rendering in the first place. I expect that Microsoft's next generation video subsystem will be equally aggressive.

Re:The Reason Java 'appears' slow,

[am 2k]

The thing you're explaining has nothing to do with MVC, I'd call it "on-demand fetching".

As a Side note, Mac OSX uses MVC throughout , maybe this is why Aqua is view to be so slow.

Cocoa on Mac OS X uses on-demand fetching for tables and optionally popup buttons (and optionally menus since 10.3).

Re:The Reason Java 'appears' slow,

[nikster]

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.

Re:The Reason Java 'appears' slow,

[mpcooke3]

Urm why would you "copy" all the data from the model to the view when using MVC? Yes, that would be inefficient but that's not a requirement of MVC, infact I wouldn't recommend it at all.

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)

Re:The Reason Java 'appears' slow,

[ragnar]

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.

Re:The Reason Java 'appears' slow,

[Anonymous Coward]

Urm why would you "copy" all the data from the model to the view when using MVC? Yes, that would be inefficient but that's not a requirement of MVC, infact I wouldn't recommend it at all. I would second this sentiment. What happens when the database table has 5 million rows. You're going to read the whole table? Lazy loading was invented for a really good reason? I'm guessing the original post never had to show more than a couple thousand rows of data.

Re:The Reason Java 'appears' slow,

[Anonymous Coward]

I was wondering how you would go about doing this code wise. I admit that I have not done very many Swing applications so I'm sure its a very obvious solution.

Thanks

Re:The Reason Java 'appears' slow,

[mpcooke3]

Well he is suggesting MVC requires copying the model data into the view on each notification. That could explain why he finds MVC slow.

Re:The Reason Java 'appears' slow,

[argent]

The performance improvements i make usually start and end with one single thing: Remove unneccessary updates.

That's interesting: I would have expected that to be handled by the runtime, too. The actual repaint operations should be deferred until all the internal event handling has completed: in the old days this kind of thing was more or less reflex, since even for a 'dumb terminal' application display updates could take many seconds as the changes shuffled down a slow serial line, and of course network window systems have lots of tricks to avoid repaints over high-latency links.

Do you get the same kinds of performance hits on JVMs running under high latency window systems like X11?

Re:The Reason Java 'appears' slow,

[Anonymous Coward]

People think Java is slow because Swing is a pig.

College Board like Java

[jabberwocky_rt]

Considering the "College Board" http://www.collegeboard.com/
has made Java the new language for the AP Computer Science test, replacing C++, I'd say Java isn't going anywhere...

Personally, I think this was a bad move on the College Board's part, but I also love my C++...

Re:like a turtle

[Anonymous Coward]

I never thought the language was all that great. The VM was the really the interesting part and now that's not all that unique.

Java.equals("chaos")

[bstarrfield]

Well, Java may be back for the time being, but I'm concerned that the language may still crash despite its new found momentum. The Java toolkits are fragmenting, Sun's market position is questionable, and alternative technologies are gaining in both strength and promise.

Sun's marketing materials always mentions Java's strength in enterprise development. But what, precisely, is Enterprise Java? Is it J2EE? Quite possibly, as a theoretical specification. But in real life, the platform is fragmented. On app servers, is Java WebSphere, WebLogic, JBoss, or Tomcat? For persistance: EJB 2, Hibernate, JDO or Cayenne? For Web apps: JSP, Struts, JSF, Tapestry? And just for fun, lets throw in XDoclet, Velocity, Cocoon, AspectJ, and about another thousand or so projects.

The diversity of new Java technologies is both great and terrible: great in the sense that new ideas are being explored that Sun may find to radical to consider putting in their specs, but terrible in the sense that few, if any, Java programmers will have knowledge of the various different projects. This is a real problem, folks. Someone who knows .Net can reasonably be expected to understand most of the C# related APIs. Its unreasonable to expect even a seasoned Java developer to understand how to program the full spread of Java APIs. Someone with Sun certification, an EJB whiz, may be damn well baffled by Hibernate (I've seen this), and may not comprehend why you'd use Tapestry instead of good old JSP.

I think the Java development platform is fragmenting. Sun's work, impressive as it is, often seems to be more concerned with being architecturally perfect at the expense of real world application speed and developer productivity (code astronauts). The Open Source projects seem to be trying to be as cool as possible, at the expense of API consistency and, just like Sun, developer productivity.

The general chaos in the Java world has, thankfully, allowed my development team to finally look at entirely different languages: Ruby, Python, even back to Smalltalk and Lisp. We've chosen this route out of frustration with both the limitations of the Java language and the increasing fragmentation of the toolsets.

As an aside, its fun to watch how hard various Open Source projects are working to emulate a ten year old toolkit: WebObjects. Yeah, WebObjects rules. Object Relational Mapping that works (and Hibernate folks, doesn't require learning yet another XML dialect to get things working). OO web page design, true components (Tapestry is essentially a copy of Web Objects Framework, made more obtuse). I wish Sun had started it's development efforts copying NeXT instead of Microsoft. We'd have a better development world today.

Googlefight

[todhsals]

Before the inevitable complaints ("But it never went anywhere!") start, let's remember that everything is relative. 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.

With this as a measure of Java's success it's amazing it did as well as it did. Java fared pretty well compared to counting the google hits for anything on the net with the term ".net", such as every freekin url in the net TLD. At this point I just stopped reading.

Re:Googlefight

[Paulrothrock]

Until they make a .java domain, I don't think Java will ever win a google fight against .Net.

In other news, Steve Jobs is richer than Bill Gates, and Apple has 50% of Microsoft's market share

Googlefight != research.

Slow GUI

[Anonymous Coward]

As you point out, Java in itself is not significantly slower than native code (perhaps 20% or so). That is a very small premium to pay for cross-platform compatibility.
The problem is Swing, the 2:nd generation GUI that Netscape started and that Sun completed. In order to achieve true platform independence it draws each pixel, instead of relying on Operating System widgets. That is really slow. In addition it uses floating-point calculations, so running it on a PDA or mobile phone is more or less out of the question.
The Windows freak doesn't see that the underlying operating system could possibly be detached from the GUI. But just like XWindows is an add-on on top of Linux, Swing is only one of many GUI's for Java.
Sun has a Widget-based GUI called AWT (standard with every Java), and the Eclipse project has a widget-based GUI called SWT.
Both of them give the user a near-native speed for the GUI, but then will not have identical look-and-feel on all platforms.

Bill Gates wants You to belive that Java is slow, and that C# is fast. That is entirely untrue: Both rely on a Virtual Machine, which adds an overhead similar to running an application on a Micro-Kernel OS (as compared to a traditional OS). That is all the overhead that you will experience. But C# has one big drawback: Platform lock-in.

Re:Slow GUI

[Javagator]

Java is slow, and that C# is fast. That is entirely untrue: Both rely on a Virtual Machine

Here's my understanding of the difference between the Java and the C# virtual machine. Both systems use an intermediate code instead of native code. The C# virtual machine is basically a JIT compiler. It compiles the intermediate code into native code when necessary. Java also uses a JIT. The big difference is that the Java Virtual Machine also provides a number of other run time services. Many of the native libraries that ship with Java have to make Java Native Interface call backs into the JVM. That's why a Java memory footprint is large while the memory footprint for C# is small. Also C# programs share the run time libraries while each Java Program has its own copy of the JVM. C# and IBM's JVM run at about the same speed. It's SUN's HotSpot that is somewhat slower.

I enjoy programming in Swing. I find it powerful and easy to use. It is a little more sluggish then native code apps, but it seems to be getting better with time. Some Java programs are ugly, but it's because they are using a simplistic layout manager. If you use something sophisticated, like Gridbag or its more programmer friendly descendants, I think Java GUIs look BETTER than GUIs laid out by hand (like in VB). Also, you can re-size them and have them do something sensible, unlike with most VB dialogs. If you change the Look and Feel from Metal to Windows, you have to look closely to tell a Java GUI from a native Windows GUI.

I think the big problem with Swing is how long it takes to start up. It takes much longer than just starting the JVM. There is something seriously lame with Swing initialization. I have a simple utility program that takes forever to start up. If I start a second copy under the same JVM it takes less than a second. This slow startup time eliminates Java for use in a whole class of desktop applications.

Monkey

[Graymalkin]

I find it amusing that Java is dying because it hasn't totally supplanted Win32 as a desktop application environment. More and more I'm seeing companies replacing their aging in-house applications with Java web services. Where several years ago an internal application might be a VB5 front-end to an Access database today is likely a full fledged web service running on a central server. Such applications are available over a VPN, dial-in modems, or even bridged networks with little trouble. The data is also centralized meaning there's no synch issues within the office. When Mary updates a record Sam gets that information immediately. These applications are also client agnostic so they'll run on just about anything with a web browser.

Centralized web services are capturing the hearts and minds of a lot of companies anymore. Clients for such services can be thin or fat and can run whatever OS is practical. An office full of iMacs can access a web service just as well as an office full of HPs running Linux. If Java is ditched down the road for Perl or Python the database server isn't going to go tits up.

Java's death never really happened, it's just that its success came from an area no one really expected early on. Perl's met with similar success. What started off as a language to parse server logs and turn huge data files into meaningful information became the premiere CGI language on the web. While a successful word processor might never be written in Java, the language and environment are far from dead.

Modern languages for the Java platform

[bonniot]

If you need to produce code that runs on a JVM but enjoy the benefits of more advanced languages, have a look at Nice or one of the many other languages for the Java VM.

Re:Modern languages for the Java platform

[BarryNorton]

I don't know Nice, so I could be wrong scanning through here, but the referred page says that 'parametric types' are supported as are functions "manipulated as first class expressions [sic]". At the same time, though, we're told "[v]alues of primitive type (int, float, ...) can be used in polymorphic code" - should we assume that functions cannot? In which case we don't have anything like a functional language (correct me if I'm wrong) because we can't even write the 'map' function!

As for as 'languages for the Java VM', I remember that people were working on ML over JVM, but the VM doesn't provided for sharing the 'nice' higher-order features (which I believe is one of the aims in http://docs.msdnaa.net/ark/Webfiles/whitepapers.ht m#babel01)

Re:Modern languages for the Java platform

[bonniot]

Rejoice, you can use functions in polymorphic code. The reason why primitive types were mentioned is that many generic proposals handle "everything but primitive types" (Java 1.5 won't let you write Collection, IIRC). Would it be clearer with "Even values of primitive types ..."? For instance, map could be typed as:

<T,U> Collection<U> map(Collection<T> c, T->U f);

Actually, it has a more precise type by abstracting over which collection class is used:

<Collection C, T, U> C<U> map(C<T> c, T->U f);

The difference is that if you call map on a List, you know statically that you get a List, not a mere Collection. Again, that's something you couldn't express in Java 1.5 (even if you had closures).

Re:Modern languages for the Java platform

[BarryNorton]

Groovy. I shall certainly have a look at this - thanks for the tip!

"Brian is back"

[mgkimsal2]

I think the Beach Boys had a big 'brian is back' campaign in the late '70s. The only thing remotely resembling a hit happened years later in the form of Kokomo (without Brian's involvement).

I predict this Java is Back hype will have about the same ending. :)

Insert obligatory references to 'surfing' somewhere here.

Re:"Brian is back"

[tradervik]

Remember the "Paul is dead" rumour back when the Beatles released Abbey Road?

I predict the nonsense about Java being dead will have about the same ending.

Since the Beatles outclass the Beach Boys, my prediction wins.

At Work, At School

[bgumm]

When I left college four years ago, Java was an afterthought and C++ was the language of choice for language and data structures classes.

I left college and became a Java developer, learning most of it on my own.

I just started taking college classes again this spring, and Java has replaced C++ as the "instructional" language.

Oh yeah, and I'm still a Java web developer at work. So for me, Java has never left. It's a great language, platform, solution. Fun times...

Re:At Work, At School

[Anonymous Coward]

Such a shame that Java is now considered the "instructional" language. I would rather see people start off with something like Scheme where you really don't have to worry about pointers (references in Java) and types. Learn to design and program.

Afterwards C++, Java, and other language could easily be worked in.

There should no one "instructional" language.

the J2EE market has been going strong for a while

[sethg]

...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.

I win!

[one_eyed_king]

I going to call my framework sex. I bet I win the googlefight by miles...

Re:For those who haven't been looking at Java late

[Daagar]

The interesting thing to note here is that while yes, they are Java apps what is making them excel is the fact that they use SWT rather than Swing.

Googlefight is a bit hmm

[kahei]

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.

Re:Googlefight is a bit hmm

[Anonymous Coward]

Not only that, but a Google search for ".net" will also turn up things that don't even have the dot in them. For example, Health on the Net and MedicineNet.com to name a few.

Re:Astroturf

[hsoft]

Troll? this was a joke related to the announcement of the SCO astroturf campaign on /., hence the smiley.

*sigh*

Re:Java is not back

[Anonymous Coward]

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?

I care. To me, Java has two arguments in its favor vs Python: execution speed and jobs available.

The former is being eroded. Really, the only application I can think of where Python's execution speed worries me is for a 3D engine I'd like to do. But with psyco, I found that the Python version of lesson 10 of the nehe opengl tutorial gets 140 frames-per-second to Java's/LWJGL's 180 (though not 'out of the box', I had to level the playing field by turning on the same opengl features for both versions). I'm still leaning slightly towards Java for this project, as I wonder that the performance gap won't become more pronounced with a real game engine that does more than just feed polygons to my graphics card.

As for jobs, I'm deciding whether I would really want another Java job. Java's not fun for me, but I digress.

Getting back to Sun, they broke backward compatibility from 1.3 to 1.4 for assertions. Why did they not do the same for generics when it would have improved performance? You'd think they would have, since there have been stories circulating of .NET's superior performance (true or not). I think generics were rushed into Java to compete with C#. The JVM was left alone, not to preserve backward compatibility (which Sun has broken before), but because there was no time to add this feature and still ship Java 1.5 in a short enough time-frame to preserve Java's waning mind-share.

".NET is years behind and plans to bring similar features only in 2007 (generics)."

Incorrect. C# has generics right now.

Also, I like that C# can allocate stuff on the stack and allows 'unsafe' code to use pointer arithmetic. These are all boons to performance, and performance is why you use C# or Java (buzzword-compliance notwithstanding). If you want to innovate or be spookily productive you use something else.

Odd comment about realtime, C, and Java...

[argent]

"it's actually kind of amazing how ill-understood some of the timing is in C--things like malloc and free can actually be awful" -- Gosling on realtime

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.

Companies want J2EE in entry levels

[arudloff]

I graduated in December of 2003, went on a bunch of interviews shortly after.. After each one, I asked the interviewer what the most important skillset was to have right now.

Each one said J2EE. Java may have lost its sex appeal with the slashdot crowd, but it surely hasn't lost a step in the Real World(tm).

Re:Companies want J2EE in entry levels

[Anonymous Coward]

would you actually be able to sleep at night knowing you where touching such a dirty piece of crap?

Re:Companies want J2EE in entry levels

[Anonymous Coward]

When, oh when, did the slashdot crowd ever actually live in the real world? They still think Linux is a viable alternative to Windows for christ's sake!

Re:For those who haven't been looking at Java late

[Anonymous Coward]

I downloaded and tries Azureus once. It crashed with some complaint about a missing library of some sort.There were no installation instructions anywhere to be found on the web site.

I _guess_ that I have to install a 50-100 Mbyte Eclipse development IDE before it'll work. But I really can't be bothered to install Eclipse just to try out a file transfer proggy.

In the bin!

Confession

[argent]

I used malloc and free dynamically in a videogame once, because to start with I wasn't sure of the size of the pool I needed and it never came up as a performance bottleneck... my partner derided me (rightly) for doing this, when he found out after the fact. Looking at the code later I realised that the reason it worked was that I was only using it in one place, and for objects that were always the same size, and the "free" operations were always happening in a predictable order... so fragmentation and timing irregularities didn't come up.

You can't depend on that kind of luck, though. Best stay clear.

of course it's still here

[discogravy]

because it's too damn slow to have gone anywhere.

Re:of course it's still here

[iggymanz]

I'm sure the java enthusiasts will post plenty of proof that it's no longer slow. It's just a resource pig on machines fast enough to run it.

Re:of course it's still here

[Anonymous Coward]

+5, hilarious :)

MOD PARENT UP

[Progman3K]

>I find it utterly hilarious that people say that Swing proves Java is fast, because the really fast parts aren't written in Java.

Me too.
Java apologists are funny that way.

When you get right down to it, a tight-loop algorithm using only native keywords and operators CAN'T be as fast in Java; it's interpreted.

All the cognitive dissonance you can throw at that fact can't change it, but the apologists keep trying anyway.

To be fair, I *do* like Java; as a teaching tool so students can pick up programming basics.

But if I had my way, everyone would learn assembler FIRST, because to my mind, that is the only true way of understanding what is REALLY going on in the computer.

I think that that is also why C (and C++) are so succesful and will never go away; they're the languages that map closest to assembler and are therefore relevant.

Until we design a computer that DOESN'T operate on the same principle as current ones do, C and C++ are never going away, and Java will always need apologists.

Re:MOD PARENT UP

[Anonymous Coward]

MOD PARENT DOWN!!! Because he's a MOD-PARENT-UP-Troll!

Re:MOD PARENT UP

[dup_account]

Hehe, teach them assembler first... coming from someone who isn't keeping up with new technology. Current Java implementations have the potential to create programs that do run faster than your average c/c++ program.

You haven't really used Java lately, and you obviously aren't making objective comparisons. I use java systems, and don't notice any more startup time, or slower performance than non-java systems on my computer. I'm also using a server that is completely written in Java, and see just fine performance there too..

Re:MOD PARENT UP

[Progman3K]

*brrrzzzzt*
Wrong! But thank you for playing!

I worked professionally as a Java programmer for two years.

Re:MOD PARENT UP

[dnoyeb]

You are so completely wrong as to be considered a troll and unworthy of reply.

Try understanding the Java architecture, then return once you have educated yourself.

Re:MOD PARENT UP

[Anonymous Coward]

>You are so completely wrong as to be considered a troll and unworthy of reply.

So, um, you felt you had to reply?

Its going to make things worse

[gtaluvit]

Lets take a look at some of these new/improved features:

Metadata: This is something great for the aspect oriented folks out there but unfortunately they made the mistake of making it look EXACTLY like a javadoc. Keep code and comments seperate.

Generic Types: Could be argued either way but if everything was an Object already, why break that? If stronger typing will improve performance, this could be a good thing, but I think it weakens the strong 'everything's an object' paradigm.

Autoboxing: Good if you like generic types, bad if you like strict OO.

Enhanced For-loop/Iterators: WTF. Added syntax just to save a few keystrokes? Its the equivalent of adding "(something) ? do this : do that" to a language. It hurts readability and adds unnecessary syntax.

Enumerated types: Its about time

Static import: Total missuse of a keyword.

Formatted output: Its about time

Varargs: Its about time though not totally necessary since arrays have a given length.

Those are just my thoughts. They make things easier for writing but they're hacking the language to pieces to do it. Metadata should have been done C# style and we don't need generics to do the work.

Re:Its going to make things worse

[duder]

Generic Types: Could be argued either way but if everything was an Object already, why break that? If stronger typing will improve performance, this could be a good thing, but I think it weakens the strong 'everything's an object' paradigm.

Well I fail to see how it weakens the everything's an object paradigm. It is an extentsion of the type system and Java has always boasted of being strongly (static) type safe. In no way are you disqualifying an object from being an Object. I will say that Java Generics suck though, because you can do stuff like this:

List<Integer> lst=new List<Integer>();
Object obj=lst;
List lst2=(List) obj;
lst2.add(new Stack()); //corrupt lst!

Re:Its going to make things worse

[bladesjester]

believe it or not, "(something) ? do this : do that" has worked since at least 1.4 (never tried it before that).

I did it just for shits and giggles to mess with a friend of mine that wanted to look at a piece of code (he dislikes them as much as I do). Personally, I dislike using them because they're a pain in the ass to read (not because they look weird, but because they're too easy to miss if you're just looking at code trying to find a problem)

You're being far too generous

[Anonymous Coward]

Sheesh, I can't believe this got modded so high. I reckon most of slashdot are sysadmins and not developers. (ducks)

A *GOOD* sysadmin is every bit as clued up and well-read as a good developer, and most will understand key programming architectures like MVC that have been around for decades. Good sysadmins inevitably train up their development skills, because programming is an extension of your arm and allows the sysadmin to perform his or her job far better than without. A sysadmin that has no interest in programming is not fully competent as a sysadmin.

Unfortunately, you're being far too generous in your estimation that Slashdot is full of sysadmins. While it started off as a forum populated with techies, and the vast majority were sysadmins or developers back then because of the way Slashdot spread by word of mouth, that is no longer even remotely so. The majority of Slashdotters now are techie wannabes, as you can tell from their comments. They may think they're technical, but actually they're technically clueless. Some even rejoice in it.

And don't worry about ducking. The attention span of the majority is now so short that most won't have got as far as your last line. :-)

Re:the J2EE market has been going strong for a whi

[Anonymous Coward]

the real question isn't why does it take so much more code to do the same thing. It is this. If you wrote it in Perl, how well would it scale to handle large number of concurrent users and how easy would it be to write a database cache in Perl. On the otherhand, you can use any number of mature ORM solutions to do that, without having to re-invent the wheel. absolutely, it will take more time and people to code, but it would only take 5 guys if you're talking about junior developers. A single senior level developer would be able to build it by himself in the same amount of time as a Perl expert. In the end, the Java guy would have to write fewer components to reach the same level of scalability.

GC should handle circular references

[brlewis]

When did the Java garbage collector ever fail to deal with circular references? Real GCs don't work by reference counts.

Re:GC should handle circular references

[DarkMan]

It handles them fine.

The problem is that if you've got a circular loop of, say, 15 objects, and a reference to a single object. The GC can't get rid of the fourteen other objects (or whatever part of them are actually redundant) because there exist references to them all. If that ciruclar reference were not present, then the GC can destruct all the objects without direct references.

Note that a manually managed memory model wouldn't nessecerily help in that situation - if you free() the objects you no longer need, not noticing that there is a cirular reference, you can end up with a particularly painful to sort out segmentation fault if you later acess that ciruclar reference (probably in a call to free() itself).

Re:GC should handle circular references

[frank_adrian314159]

The problem is that if you've got a circular loop of, say, 15 objects, and a reference to a single object. The GC can't get rid of the fourteen other objects (or whatever part of them are actually redundant) because there exist references to them all. If that ciruclar reference were not present, then the GC can destruct all the objects without direct references.

GC's don't start collecting from random objects. All real GC's start from a known set of objects called the root set, usually the VM's globals and stacks. All items reachable from the root set are retained while the others are reclaimed. Since your hypothetical set of circular references are not reachable from anywhere but themselves (and, by extension, from the root set), they will not be reached and, therefore, reclaimed. If they are pointed to by somewhere reachable from the root set, they are not garbage and are retained.

In short, your post shows that you don't understand the difference between a reference counted system and a garbage collected system - a sad state that we often see in Windows programmers, too long exposed to COM, and in some Unix hackers whose exposure to languages is limited to ones having reference counting as a faux method for real storage management becuase it (a) is slower, (b) doesn't work reliably, and (c) is easily understandable by the programmer who thinks that malloc and free are the height of memory management technology.

Re:GC should handle circular references

[Torne]

If you have a circular loop of 15 objects and a reference to a single object, then you have references to *all 15 objects*. Any memory management strategy which frees the other objects is *unsafe*. Why is this a problem? If you didn't want the other 14 objects, it's trivial to clear the reference in the one you have, leaving the other 14 as an isolated chain which will then be freed.

The Sun GC used in HotSpot since at least Java 1.2 is 'perfect', which means it always correctly determines whether something is garbage or not; it never misses something which can legally be freed.

Re:GC should handle circular references

[DarkMan]

To clarify, I ment a reference to a single object within the loop, that being the only object within the loop that you still want. This can occur, for example, in a (not terribly great) implementation of a circularly linked list.

Hence, rather than being able to reclaim 14 or thereabouts objects worth of storage, the GC holds on to them. That's a programmer error, and wherein circular references can lead into memory 'leaks'.

Re:GC should handle circular references

[_xeno_]

To clarify this, the issue usually comes up when something large is placed into a collection and then never removed because it's forgotten about. The collection still has a valid reference to the object, but nothing is ever going to reference it again. There's really no way for the GC to know that the fifth object in a linked list should have been removed ages ago since it will no longer be used. All Java memory leaks are variants on this issue.

The simplest way to do this is to add event listeners to objects, because most people consider those "throw-away" objects. You just chuck an event listener onto a button, for example, and forget about it. This generally works because usually you'll drop references to the button when you're done with it, so all the event listeners will become garbage too.

The problem comes in situtations where that object reference persists (for example, if you make only one copy of your "About" window, but accidently add new event handlers to it every time it is displayed). You wind up with a memory leak, since you keep using memory for these objects that you then no longer use. But a collection still contains them, somewhere, so the garbage collector can't collect them.

Java memory leaks are always caused by something, somewhere, containing a reference to something that it no longer should. This makes tracking them down incredibly hard, since you have to figure out what, where, has a reference to an object that should be considered dead. These reference are almost always abstracted away into a collection object somewhere, making them even less obvious. In C/C++ you can usually get away with freeing something you know will no longer be used even if something still has an invalid reference to it. (Although, obviously, you still should remove the reference.)

This isn't really a flaw with the Java system, though. It's a flaw that any GC system can have and is caused by people failing to recognize existing strong references to an object. Sun has a "solution" to this in the java.lang.ref.WeakReference class, which allows you to stick "weak references" to an object into collections. This is only a partial solution, though, since the WeakReference object itself takes memory (albiet a much smaller amount) and still needs to be removed from the collection.

Re:GC should handle circular references

[Torne]

That kind of thing is a simple coding error that can happen in any language, and is a problem in any language. It's not hard to track down where things are referred from if you have a decent debugger. Soft, weak and phantom references don't use any significant memory, and you can make them automatically remove themselves from collections..etc that they may be in using reference queues. The standard library WeakHashMap class has most of it implemented for you.

Your example with the About box is cute, but it's no better with explicit allocation; if you are intending to only add the event handler once, then you will likewise only free it once, and you will leak exactly the same amount of memory.

I can't, in fact, think of any examples at all where a mistake that causes a 'leak' in Java is not also a leak in an equivalent program with explicit allocation.

Re:GC should handle circular references

[_xeno_]

I can't, in fact, think of any examples at all where a mistake that causes a 'leak' in Java is not also a leak in an equivalent program with explicit allocation.

Yeah, I agree. The issue comes up because a lot of developers hear "garbage collection" and think "memory leaks are impossible." Then they ignore things like removing objects from collections when they're done with them, and cause memory leaks in Java.

The point is that memory leaks are indeed possible in Java. Yes, it's because of bad coding practices - but honestly, that's really the cause of memory leaks in any program.

Far too many people assume that because Java is garbage collected it is somehow magically immune to memory leaks, and that simply isn't the case.

Re:GC should handle circular references

[Piquan]

Sun has a "solution" to this in the java.lang.ref.WeakReference class, which allows you to stick "weak references" to an object into collections.

Hang about. It sounds like you're saying that, in Java, you frequently have collections of objects that are all referenced somewhere else, somewhere live. Is that correct?

I ask because, in all my time programming in GC'd languages (not Java), I've only once needed a weak collection. I have wished that I had weak references in one particluar refcounting language that rhymes with Earl, but that's just for "parent" references in nested structures.

Re:GC should handle circular references

[Torne]

Here we are in violent agreement. =)

NO, WAIT... MOD THIS PARENT UP!

[Anonymous Coward]

yep.

Why *I* don't use java!

[callipygian-showsyst]

I don't use Java because:

• I don't like to associate with the folks who invented it
• It's impossible to write a good-looking app with it
• It's SLOW
• It's not a STANDARD, like C# and .NET are
• There are no good Open Source Implementations available

Re:Why *I* don't use java!

[Ace128]

http://www.arturia.com/en/storm3newfeat.lasso

Re:Why *I* don't use java!

[Anonymous Coward]

Good grief, have the pills worn off already?

1. Strangely, despite developing in Java for years, I've never once met James Gosling or anyone else involved with developing Java. Clearly I'm doing something wrong. I don't actually believe that using Java in any way constitutes an approval of the lifestyle and behaviour of people I have never met.

2. Yes, you're right. Java stops you from drawing anything to the screen if its inbuilt filters detect anything 'pretty'. Or could it be that lazy programmers develop ugly apps? I'll admit that a good GUI takes some effort in Java, but I can choose to do something about it.

3. It might be slow, but at least it knows the value of the CAPS LOCK KEY

4. Imagine.. Microsoft submits c# to the ecma. Then they change it, breaking hundreds of APIs in the next version and submit that to the ecma. But it's OK, because it's a standard. Sun on the other hand have managed to release seven major versions of Java without too much problem, support deprecated APIs beyond all reasonable expectations and provide comprehensive validation tools to allow people developing JVMs to guarantee that they are compatible at many levels.

5. Not correct. For that matter, has Mono been ecma approved, and has it any assurance that Microsoft won't close it down for relying on patented Microsoft technology? Is Mono guaranteed to be compatible, and to still work when Microsoft upgrades to the next version? So far Mono is the only other implementation of Net. Compare that with the huge eco-system of languages and JVMs that have been developed around the Java platform.

Re:Why *I* don't use java!

[Anonymous Coward]

Take your medication and stick your head back in the sand. MORON.

Re:Why *I* don't use java!

[Anonymous Coward]

"I don't like to associate with the folks who invented it [rotten.com]"

This had nothing to do with Java.

It was clearly the result of working for Disney.

Re:For those who haven't been looking at Java late

[Anonymous Coward]

Exactly! Azureus made clear to me how wonderful Java programs can be these days!

For those in denial

[Ace128]

http://www.kano.net/javabench/data
http://www.kan o.net/javabench/

http://developers.slashdot.org/article.pl?sid=04 /0 6/15/217239&mode=thread&tid=108&tid=126&tid=15 6

http://cpp.student.utwente.nl/benchmark/

I have fate in java. Even read somewhere that java is actually faster than C++ in some cases.

Besides:
http://www.arturia.com/en/storm3newfea t.lasso

Completly done in java!

Everything I see is Java

[Anonymous Coward]

In my world (Enterprise Application Integration) it's all Java. Has been for years, and it won't change anytime soon.

Java has the same problem as Linux

[Bandit0013]

It's too fragmented, there are too many flavors! Speed/performance be damned, hell we can all just buy more ram and faster processors right? That seems to be the mantra of many posters.

Fragmentation is why Java and Linux, though worthy concepts and definately have a place in the world, will never topple microsoft.

Microsoft has a plan, they have total control over their specifications. When I compile a .NET application, I know for a fact that any machine with the .NET framework will run, I don't have to worry about which java vm/linux distro they're running, nor do I have to pick and choose between a crapload of library add-ons just to get basic gui functionality. .NET also easily interops with all the other popular microsoft products, exchange, office, etc right out of the box which allows me as a developer to do some cool stuff without much effort. This is important because selling an application is always easier if it adds value to applications already in use.

What .NET gives you is a fast, stable, secure (I don't know wtf a previous poster was saying when he said .NET isn't secure, that's an ignorant lie if there ever was one, I can't even recall hearing about a framework exploit yet), and consistant development environment. It is astounding how fast you can put together an enterprise application in .NET. Plus with Mono 1.1 you can now run these apps on OSX and Linux, so don't cry about being tied to the windows platform.

The best way to grow a language is to make it attractive to new developers. That means a lower learning curve and better tools. The learning curve in python, php, and .NET is way lower than java, and Microsoft Visual Studio is the best RAD tool on the planet, hands down. THAT is why Java is going to lose ground. It has enough followers to be saved, but can they pull together enough to compete with .NET etc? I don't think so, but they could surprise me.

So many comments about the "googlefight" silliness

[brlewis]

I'm surprised to see so many comments that show people actually read the article before posting. Now we just need to get people to skim prior posts before posting.

JDJ? Biased? Never!

[SuperChuck69]

Am I the only one that finds it a little biased that the Java Developer Journal is reporting "Java is Back"?

JDJ "earns" their income by selling their rag to java developers. If Java declines, so do their sales. If Java's on the rise, their subscription base will also be "on the rise".

Not to mention, as I recall from the Java Evangelist days, JDJ wasn't exactly the most honest of rags. They seemed to devote entire issues to praising products that advertised heavily on their pages.

Re:There has been some good alternatives[reformat]

[darcybrown]

Yawn. The 'Java is slow, obese and heavy' arguments are poor, out of date and largely inaccurate. Java's popularity on mobile phones suggests it is hardly a performance bottleneck, nor is it too demanding for memory.

I understand you argument, but it sure doesn't apply to phones. Maybe for a simple Java business application, but thats about it.

Find one book, one article about making apps on j2me that doesn't explain how to use obfuscation. Thats not because of all the pirates trying to steal your code, its because Java is big.

In order to make a sophisticated app, you basically have to throw out everything you have come to love about Java to make it work on a phone, namely OO....

Its not the amount of code thats the problem, that's inheirent in any language, clearly. It's the fact that adding classes, or doing anything that the language is built for or suggests you do costs alot.

The Jar footprint and class size comes straight from how many methods, variables, extends, implements, packages, etc.. You would crazy to try to run an app on a phone that have tons of getters and setters - classloader loads that and then whoop, there went 80% of your memory.

For sophisticated apps, this makes Java on a phone is basically procedural code, large case statements, public variables for direct access and maybe 3 or 4 classes tops. At that point, I have a hard time calling it Java, but also at that point, its not obese.

Its popular on phones because there are 2 options, that or BREW.

Java doesn't exist!

[dfj225]

Well, according to my research Java doesn't even exist! There are absolutely no servers existing in the .java domain. However, there are many, many servers with .net. Apparently, Java has much catching up to do if they ever want to pass Microsoft.

Pot, Kettle

[mihalis]

In the first article, Eric Allman says I'm curious about a couple of other languages. My favorite language to hate is Perl. It seems like no real thought was given to the language. It kind of grew over the years. So it's just really deeply, deeply ugly.

And this is from the guy who wrote Sendmail !

Corrections

[SuperKendall]

And a 20 MB download that takes dog knows how many megabytes after installation. Also, the whole process will have to be repeated at the next release, as chances are software developed on a newer version won't run on an older one.

The JRE is only 7.6 MB (compared to the .Net runtime which is actually a bit larger than 20MB). And complaints from some circles are that Java is TOO backwards compatible - in the discussion of generics people are complaining that Java did not do everything .Net did. But Java kept backwards compatibility (so I can use generics in 1.5 and the code will run just fine in 1.4.

Googlefight?You have to know how to use Google 1st

[aprilsound]

if you actualy do the search right, .NET Microsoft OR MS OR Framework OR Programming
9,630,000 results

Java
63,600,000

so, in terms of relevant results... you were saying?

Java on the server side...

[nil_null]

Although I don't see Java on the client being any different than it used to be; maybe a little better, but not compared to alternatives (or maybe I just haven't payed much attention to Java client technology). But in any case, Java on the server is alive and well, doing better than ever. I think the arrival of lightweight alternatives to EJB's is making Java development a lot smoother than it has been.

Take a look at tools like Spring and Hibernate, for example. J2EE is no longer as cumbersome as it used to be. These new developments make Java equally useful as many of the alternatives, if not more useful for many types of server-side software. Web services is also helping making Java a very viable option on the server side, since you remain flexible in your choices for what software interoperates with your web services.

Re:the J2EE market has been going strong for a whi

[Paulrothrock]

I had a similar reaction when I switched from C++ to Java. There are so many things that need done before you can even start programming that it's no wonder you need so many people to do stuff. (I had started school learning C++, but they switched to Java half way through.)

Luckily, I found PHP before I got totally turned off by the prospect of web programming.

"why kast wasn't written in Java"

[Anonymous Coward]

java applications are difficult to install

It all depends on the programmer, doesn't it?

java applications start up slowly

I give them half a point there, but this is not a big issue.

java applications use a lot of memory

As with any language... you can write bloated applications... ask any Microsoft employee.

java applications leak memory

I've never noticed that. You might tie up a lot of memory if you're hanging big structures in the application space.

Embedded Java debunked

[amightywind]

You don't know what you are talking about. Java is a terrible choice for embedded systems. A cheezy cell phone does not count! Java is slow and bloated, and the GC is non-deterministic. These are bad characteristics for the avionics system I work with. Decent JVM's exist for only a few widely used processors (PPC, ARM), and they are proprietary. Start using anything more obscure (like an AD Blackfin) and it is assembler and C only. Sometimes broken C++. Like Jack Nicholson once said: "Peddle crazy somewhere else, were full up here."

Re:Embedded Java debunked

[shadow_slicer]

Did you even bother reading what the poster wrote?

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:Embedded Java debunked

[amightywind]

In these cases, most of the 'JVM' is implemented in hardware

Oh really? And what do you mean by implemented in hardware? Got a clue for you. The JVM is written in C or part in assembler, then glued to the Java language with JNI. Until Java produces assembly (like GCJ) you will have to mix C and Java to port the Java environment anywhere, a non-trivial task. The point is most Java programmers have to resort to C if they work at a low level on any platform.

Re:Embedded Java debunked

[shadow_slicer]

What happens to your precious C and assembly when you compile and assemble them? They get converted into machine code for whatever processor you are running it on.

JVM stands for Java Virtual Machine.
It is called that because it interprets the Java bytecodes as if they were machine instructions, and executes them as if they were running on a "Java Machine".
The JVM is just an emulator for a standard "Java Machine". At the time Java was designed, there was no real machine that could execute Java bytecodes.

The specialized Java processors use Java bytecodes as their instruction set (to an extent, they leave out a few bytecodes and usually add I/O instructions). This is what I mean by mostly implemented in hardware. They still need a low-level operating system to handle linking and garbage collection, but this is usually already burned into the ROM (along with a few specialized classes to handle I/O and such), so the developer doesn't need to worry about it.

If you're still unclear how this is possible, feel free to read the JVM specification:
http://java.sun.com/docs/books/vmspec/2nd-edition/ html/Instructions2.doc.html
It doesn't specifically say that this can/should/has be/be/been done, but you can look at the instruction set and see if you think it could reasonably be implemented in hardware.

Re:Embedded Java debunked

[dmivs]

Hmm, Java byte-code hardware processors? Where is portability? And how about Forth or Pascal P-code hardware processors? Truth is out there...

MOD PARENT UP

[Anonymous Coward]

true

I want to love Java

[Stone316]

I do, I really do but I ran into so many cross platform problems I simply gave up. Simple app's would not work between windows and linux and the many different browsers.

I spent hours debuging why something wasn't working one night, by chance I loaded up a different browser and it worked fine. Forget about user's being able to install a JVM but how do you write an applet or client application that is truely cross-platform? (And i'm ignoring the formating issues I experienced between linux and windows.)

I'll admit, i'm not Java guru but I haven't found any good books or documentation which recommends guidelines on how to do this successfully.

What is with all these comments?

[Espectr0]

Every comment posted on this thread appears in the article discussion forum at http://www.sys-con.com/story/feedback.cfm?storyid= 45966

Who is copying who?

Re:What is with all these comments?

[Anonymous Coward]

woah.. that is really weird... It even added hrefs to the words "Spring" and "Hibernate" in my post and the were the correct links (I didn't href them myself). Though that appears to be only place where that happened.

nil_null

Re:What is with all these comments?

[Anonymous Coward]

A new twist in astroturfing, what the hell we call this? It is like cgi'ing in extras in movies. JDJ is saying look we have an actual discussion going on here. Seems their advertizers should know what they are doing stealing comments to make their boards like alive, truly sad, loserish behavior.

Why is java better than perl/python....it's NOT.

[Lodragandraoidh]

"Were I a CIO facing these issues [the technical effort needed to port an app off one app server to another], I'd stay focused on the one thing definitively under my control - keeping the cost of substitution, of at least application portability, as close to zero as possible. How? You guessed it, I'd write to Java." - Jonathan Schwartz Sun COO

Ummm - what about python or perl? Both of these are just as portable - requiring zero modification of the code to port to any OS.

And don't pull out the 'java is more efficient' bull scatology. I have a java application right now that my team is rewriting in perl because it runs too slow (and also has a memory leak - code is vendor proprietary, so they won't let us see/modify the source to fix it). There is nothing I can do with java that I can't do with perl or python - as much as David Berlind would say otherwise (his statement in the article suggests perl and python are good for 'scripting', but not robust enough for large applications). As a supposedly impartial journalist/editor for ZDnet - I have to question his motives for jumping on this bandwagon. Also, his primary focus on writing, rather than building apps, hardly makes him qualified to make such an accessment, imo.

Given that I would have to disagree with this editorial in JDJ.

The words of the COO of SUN, who has a vested interest in the success of java, and the words of a journalist, who from all appearances doesn't have the technical background to be taken seriously concerning application development issues, in an editorial on a website dedicated to java development, hardly seems like 'news' more than a marketing ploy.

Java isn't going anywhere but up

[bokmann]

Java isn't going anywhere. Java has at least reached the status of 'the next cobol', to quote Stu Halloway. This isn't a comment on Java's speed, quality, and such, it simply means that even if all Java development stopped today (which it won't), there has been enough investment in Java'based intfrastructure that the maintenance alone will be quite a large job market for years to come.

Java is NOT dead/dying. New, important projects start with it every day. I am the president of the Northern Virginia Java Users Group, and we have a steadily growing membership (now over 1100 members). I am also a speaker for the No Fluff Just Stuff Software Symposiums, and the discussions about Java tools, techniques, etc dominate that conference. Why? Because it sells. .NET has been gaining some momentum, and c# is undoubtedly the 'next big thing', but Java is here to stay. If you are a software engineer, Java is a 'safe place' to be for new and interesting work for the next 4+ years, at least. (That doesn't mean software engineers don't need to have diverse talent - but that is a topic for another rant).

Re:Java isn't going anywhere but up

[dacarr]

Calling it the next COBOL, though, is pretty much damning it with faint praise. MOst of the people I've known who even admit to knowing any cobol either do so while blushing, or don't work in that environment - and yet like it.

It's time for Java++

[jinxidoru]

It's time for Sun to make a new version of Java. Java was a seminal creation. It delivered a powerful method of application development with the ability to build once and run anywhere. The problem with being a pioneer though is that you inevitably make many mistakes. It's unavoidable. Sun made mistakes with Java. They've tried to cover up their mistakes, like by hiding AWT with Swing, but it's still lurking down there below. I don't wish to go into depth on the deficiences of Java. If you use Java on a regular basis, you know quite a few yourself.

Now please realize that I'm not trying to bag on Java. I love Java. What I'm saying is that it's time to quit worrying about backwards-compatibility and build a new system from the ground up.

This is what Microsoft did recently with C#. C# is superior to Java. Why shouldn't it be superior? It was made by copying everything good from Java and leaving off the legacy fluff that exists for backwards-compatibility only. It does everything that Java does plus more (the ability to use pointers, structures, native types are instances, etc.) I just wish Microsoft wasn't in charge of C#, so let's see Sun do better.

We're comparing apples to oranges here

[JustAnotherReader]

Everyone's talking about how Java requires the user to install a JRE and how Java is slow (I beg to differ) and how Java Swing is to bloated. All these complaints assume that Java's predominant use is to write desktop applications.

But that's not what Java is being used for. The most common usage of Java is for high volume dynamic web sites such as Amazon.com and most online banking systems. The combination of Java servlets, Java Server Pages and Java based web engines (WebSphere or Web Logic for example, or even Apache and Tomcat) are becoming the most common usage of Java.

I work at a major California bank and have worked on various web based applications for about 9 years. Java is the standard for writing those types of dynamic web apps. For example. When you want to see your financial summary you wouldn't expect that there is somebody writing a web page just for you every time to make an ATM transaction would you? Of course not. You log in and we identify you. Then we go to an Oracle database or a bank host system and get your transaction history. We load that into a data object and pass it to a JSP which dynamically creates the web page with your transaction history. Java excels at that kind of application. And by the way, I can develop my code in Windows 2000, move it to a Linux box to do some basic testing, and then move it (all without recompiling) to an IBM AIX Unix box and have everything work the same on all these different environments. That makes my job easier.

So we need to stop comparing apples to oranges and saying things that essentially sum up to "A badly written Java program is slower than a well written C program" or "Java was slow 6 years ago so it's still slow today" or "I don't agree with the language designer's choice of [properties, no operator overloading or whatever language peeve you have]". Look at how the language is actually being used and you'll see that Java is indeed alive and well.

Re:We're comparing apples to oranges here

[wtoconnor]

I don't believe Amazon uses Java for their website. They usually are trying to hire Mason developers which is Perl based. Lets face it most of the high performance websites are Perl/PHP based Java equal slow. But Java fits better into the IT mentality of one monster machine being serviced by minions. That is not to say that Java does not have a place in development. I often wish gcc would go Java. That way we could have cross development tools on virtually any machine without a lot of hassel. For instance Apple modifies gcc so making an gcc arm compiler for Mac OS X is not easy. A good carpenter doesn't only keep hammers in his tool box and neither should good programmer. Use what is appropriate for the task.

Right

[essreenim]

You'll just love Longhorn then. It has borg assimilations for mp3 burning..everything included.
Be careful what you wish for...

Re:like a turtle

[Anonymous Coward]

The VM was never unique to begin with. It's basically a more binary-oriented version of BASIC, or perl, infocom system, or any of the hundreds of other various interpreted/emulated systems out there, many of which predate java.

Issue with that

[essreenim]

people like their computer to look and work in a consistent way
Thats because you've been using the same OS too much my friend. Soon everyone will be using MS OS, and applications for everything and then you will be REALLY into your work in a consistent way/u> People dont even realize they are having their mind made up for them by MS. What really gets me is the misinterpretation. Windows OS practially lie: 'Everything you asked me to do is done because my lovely progress bar has reached the end..'BS.

I'll called my platform "THE"

[Anonymous Coward]

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

versus .COM
(1940 000 000 results)

versus THE
(5850 000 000 results)

Warning: referenced article moronic

[Anonymous Coward]

OMFG! That article was hilarious!

"java runtime...[is] difficult to configure."

It's a one-click install.

"java applications have slow, unresponsive user interfaces"

Sure, if you write slow code. But hundreds of snappy Java client apps prove it's possible.

"java applications use a lot of memory"

That's a fair point, but...

"java applications leak memory"

Yes, they do, if you write code that hangs on to data structures it doesn't need anymore. (Is that really a "leak" though?) Otherwise they do not. (And *of course* a C++ program will "leak" memory if you do the same thing.) And what's this einstein's alternative? He wrote his thing in C++! Of all the lamebrained comparisons of Java and C++ I've seen in the last decade, this has *got* to take the cake! He picked C++ over Java because of memory management! The only thing better would be seeing someone say they picked Java over C++ because of the speed!

Re:For those who haven't been looking at Java late

[Coppertone]

Nope you don't need the whole Eclipse environment - There is an installer Win32 package available on the sourceforge website which included SWT library that is needed so I think you should give it another try!

I don't use Java

[CaptainTux]

I've been programming professionally since I was around 15 and have a CompSci degree under my belt along with probably a few million lines of code. I know what it takes to develop a large scale application and I'm definately willing to put in the work to learn a new language. I've learned solid principles of OOP and undertand where Java is coming from and trying to accomplish. I even took the time to learn it a few years back just to have it under my belt.

Java is a good language. Yes, there are issues, but they could be resolved by Sun fairly easily. But, in most cases, Java simply isn't needed. Statistics show that the vast majority of software applications being developed are not "mass market" type apps but rather stuff that is used in house. Most shops have standardized around one platform or another so cross platform isn't really an issue. And, when it is, it's usually trivial to edit C code and recompile for the new arch.

Lastly, let me tell you a little story: I am currently launching a new startup aimed at developing a kiosk for the entertainment industry. Originally, everyone said I simply *had* to write my software in Java because of an infinate number of reasons. Even as an experienced programmer, I was dumb enough to buy into it and try. Within a few weeks the software had become so slow and bloated that I knew I had to find something else. Where do you think I went?

Python with the WX extensions.

Python offers me everything Java can (WORA, Speed, Good GUI enviroment, etc) and is absolutley painless to learn. In fact, I am LEARNING the language AS I write the new software and it's not slowing me up at all. There are times I have to go back and fix things but usually it's pretty straightforward. Python is, to me at least, a Java killer.

I think that Java has some strong points. But, ultimately, it's no stronger that some other languages out ther (think C++, Python) and in some ways weaker. Sun needs to do something to get Java back on track. They can save the language but they need to drop the arrogance and get back down to basics.

Re:I don't use Java

[Anonymous Coward]

So you're not as good a developer as you think you are and a real language was beyond you. I'm glad to see you're able to make use of little scripting languages, though.

If you've got a slow Java app, it's not the fault of the language but the developer.

A craftsman never blames his tools.

The problem with Java...

[Mandrel]

...is that it sucks you in because it's free, but at the same time is closed source so that you have to beg some unresponsive god to fix bugs or add features.

Re:The problem with Java...

[Bert690]

...is that it sucks you in because it's free, but at the same time is closed source so that you have to beg some unresponsive god to fix bugs or add features.

Here here... finally some criticism of Java with actual merit.

Sun seriously needs to get their head out of their ass... submitting bugs has basically become a futile exercise. One bug I recently reported took 6 months to acknowledge, and the last one I submitted has gone completely ignored for even longer despite a simple 3 line program clearly demonstrating the issue. Now I don't even bother.

The only problem with Java is the fact that Sun controls it. If it were open, Swing and various other crappy & bloated aspects of Java (such as entire EJB spec) would likely have been abandoned long ago and replaced with sensible alternatives.

Re: If only wxWidgets were truely x-platform

[Rob Y.]

wxWidgets is a really nice toolkit. The problem is that it isn't truely cross platform where it counts.

Like it or not, the 2nd platform most business app developers want to target is the Macintosh. I tried porting a Win32 app to wxWidgets a while back, and it looked like I could get it to work on Windows (and probably Linux), but the Mac port was just not there. Widgets didn't draw, size or behave right, and I had problems getting sockets to work right.

It appears like there's a push on currently to get the mac support up to par (at least their website is soliciting contributions). It's a shame that Apple wouldn't fund this themselves, but I guess they're still pushing native Mac toolkits (though why, at this point in the game, I can't imagine).

When it 'runs everywere'

[Anonymous Coward]

The original Java mantra was "Runs everywere". It never did.

When Sun bothers to make the original promise of Java happen, then Java would have a chance to "return"...for it never "got there" to begin with.

Java success does not imply Sun success

[brlewis]

Sun does not make money directly off of the popularity of Java. People who develop Java server apps and need to move to high-end servers might go to Sun, but they might just as easily go to IBM. Where would they be going if it wasn't a Java app? Probably the same vendors.

Re:Java success does not imply Sun success

[Anonymous Coward]

So are you trying to say that money directly recieved is the only suitible criteria for achieving success?

Re:the J2EE market has been going strong for a whi

[sdcharle]

I have noticed that about J2EE. Well, that:

• there are a bazillion ads for J2EE people, making me wonder if the title of the article here could possibly be anything stupider than 'Java is Back!'. Don't call it a comeback, it's been here for years, as a wise man once said.
• J2EE, on cursory examination, seems to exist to turn 1 person projects into 5 person projects, and 5 person projects in to $5 million projects. Great for programmers, no doubt about it.

Good to hear taking a class helped you out, I may go do the same as protection in case I find myself unemployed down the road.

Re:like a turtle

[Com2Kid]

• It might have left, but if you've ever watched a turtle you know they can wander off without you noticing because you got bored watching said turtle try to run.

Some turtles are oddly enough, fast as heck.

Even box turtles can go really fast when they want to. (Oh crud, where did the little bugger go? Ahh!!!)

I think it'd be nice if Sun did some sort of multi-platform automatic binary distrobution system instead of that darn VM, Java itself is a nice language, the API is simple to use for many many things, the only issue is the darn VM!

If compiled binaries were more common, or even some sort of limited compiled binaries, compiled to the LOWEST level possible and still be run in a sandbox, I think Java would have a better chance.

I mean heck, how many plateforms are there REALLY browsing the Internet? Three: Windows, Macintosh, Linux.

For most applets, multibinary support would not add THAT much more size to the applet, since most of the size of an applet is likely to be in the graphics and sound department anyways.

Oh yah, talking about graphics and sound:

Sun: STOP IT WITH THE MINIMAL LEVEL OF SUPPORT CRUD!

2.4Ghz machine;

800x600 resolution;

Instanciating a new Color object to draw random lines: 100% of my CPU use.

Head --> Wall

*POUND* *POUND* *POUND* *POUND*

stupidstupidstupidstupid.

This is not even counting how slow doing other graphical operations is, ugh! Please, sun, optimize Swing on a per machine basis!! On Windows it should automatically take advantage of DirectX, on OSX, Quartz, on Linux, umm, whatever Linux uses (MESA? Err, no clue).

Annnnyways. Aside from the, umm, performance issues (which ARE a killer), and the graphical issues, oh, yes, wait, one more mini-rant on graphics and Java.

People complain that making a GUI in Java is a pain, indeed, it IS a pain, but you know, compared to other APIs, it is not ALL that bad. Just a bit odd at times, having to work with a lowest common denominator toolkit. Actually it is NOT truely crossplateform, as the dude with the Mac OSX Laptop in my class wrote GUIs that didn't "look right" on Windows and the rest of the class on Windows wrote GUIs that didn't look right on his box. ^_^ Oh well, they were USEABLE more or less, only a bit of overlap between elements, hehe.

Yah, umm, that was good for a couple of laughs.

Oh yah, the language.

Fun to program in, very interesting, makes me WANT to program, easy to use.

Just performance bites. Horribly.

damn realism

[Anonymous Coward]

this is ./; don't spoil the fun for all the kids ;-)

Great research...

[ultranova]

From the article:

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.

The article provided a link to the Googlefight, which in turn contained a link to the searches for "Java" and ".NET". A small sample of those 388 million hits for ".NET" from Google, emphasis preserved as it was in the listing:

SourceForge.net: Welcome

www.php.net/

www.cnet.com/

freshmeat.net: Welcome to freshmeat.net

www.historynet.com/

www.photo.net/

In short, this list seems to include the mainpage of every webserver in every domain which has the word "net" somewhere in the domainname (like in, for example, at the end...), as well as every page which mentions that word...

For Googles credit, the very first hit was Microsofts page for .NET technology.

Conclusion: This article might not be entirely trustworthy.

Add Jonathan Schwartz

[JBrow]

Interviewing both Gosling and Schwartz would provide plenty of answers to help cut through the FUD, IMHO.

Re:the J2EE market has been going strong for a whi

[Anonymous Coward]

Well if Java is beyond you, accept your limitations and go back to writing your little scripts in Perl...

Re: Free(tm)

[struberg]

for the ones who got me wrong. The part that made me laugh is

Free in combination with (tm)

Because of a lawers view, a trademark is for making something CLOSED and only useable for the trademark owners.

From a philosophers view this is a really great antidigma (opposite to tautology)!

But you know, while we're at it;

[Progman3K]

I never said I thought Java should go away either.

Maybe the answer would be to do like I suggested and change the way the computer works fundamentally:

Transputers.

Check out this page; it makes the case for a Java computer: the java code would BE the instruction set.

The next two pages are most relevant to our discussion.
http://arstechnica.com/cpu/2q00/x86fu ture/isa-future-5.html

Note; the whole article is about the future of the current (x86) instruction set, which doesn't seem to need to go away either.

At the end of the day, I feel whichever language is best to do matricial math in for you, hey, go for it, and if we use transputer technology to level the field, all the better.

Maybe it comes down to memory allocation.

I prefer to structure that stuff myself, rather than let an automated thing control resources like that, so I use C++.

Re:I said it before, and i'll say it again

[mrshowtime]

Oh, I'm sorry, should I have said that "JAVA is Great!" When it has caused me so much trouble in the past. Fuck, you can't say anything negative or TRUE about anything on Slashdot without being modded a troll.

What if you wanted to eat a good chicken soup?

[iamacat]

Most 55 year old users have no trouble downloading, unpacking and de-iceing a packaged chicken, deleting unneccessary components according to instructions, installing other things like salt and pepper, making sure that the correct version (red vs black) is used and waiting until the system is optimized for optimum taste.

On the other hand, if you just like a candy bar in convinience store, you will not buy it if you need to defrost it before eating. So if you are designing a web page that people will just occasionally read, don't expect them to install Java, Flash or a particular browser just for your benefit. But for serious programs like word processors and even big games that people will play for weeks, some setup and even an $40 memory upgrade is not a big obsticle.

Sure, some people want to eat their chicken soup from US army rations. But it will never taste as good and may be harzardous to your health in the long run. So farmers selling packaged, frozen chicken shouldn't worry just yet. And if adding red pepper to your mexican dish will cause your spicy candy to use it instead of black one, you need to switch to a better cooking system.

Respect for Java apps

[The MESMERIC]

How I wished there were more Java apps they are truly cross-OS
I didn't have a file-share program so I've installed a pretty good one in Java - pretty simple.
I needed an MSN Clone so a pretty cute one in Java.
I needed a SQL Server GUI found one in Java.
Mind you - am resorting now to web-based SQL Server apps - much better less hassle.
There are a number of software that runs in Java, ok not all are good - that is up to the programmers.
Datadino is full of bug and $99 when they use open-source code.
But many others are pretty slick and hassle free.
Java apps are truly cross-platform, wished there were more.
Last app I was impressed with but haven't played with it enough is Eclipse - brilliant

People diss Java (maybe because its trendy to do so?),
when so far I don't know of anything as cross-OS compatible and easy to install (as long as you have JDK of course).