Why Linux Lovers Jilt Java

BrightIce writes: "The Java Developer Journal has an interesting article about Java in the Linux world. It tries to explain why the Linux folks dislike Java, what the future might bring regarding M$, C# and Java, about Sun and Microsoft, and Java and Embedded Linux." I know why I hate it: it takes too.long.to.get.to.my.method(half, of, the, time); and then there's the fact that when Java was new and exciting I wrote a video game in it, only to have Sun cease-and-desist me for calling it "Java Invaders." (oh, and have you ever noticed that our logo isn't the sun logo? They cease-and-desisted us for using their logo here too, even tho that is definitely fair use). Other than that, my only problem with Java is that the VM in Netscape is crap. Oh, and their licensing. And the fact that it's bloated. And the fact that I don't have enough time to type in all the reasons it irritated me *grin*

Re:those are your reasons?

The bloat he was referring to has NOTHING to do with the size of the runtime download, nor with the size of the developer files. He was referring to the memory overhead that java puts on programs.

Before you say "Use JNI, it's the VM not java", let me explain to you why you have your head up your ass.

I'm not saying "use JNI" because then I would be sacrificing portability so YOU take your head out of YOUR ass and stop putting words in my mouth and then giving counter claims to stuff I've never said. Very poor manners!

I'm pretty sure he was refering to API bloat, which you *could* argue is there.. Memory overhead is not really an issue, however, and you can get memory much cheaper than you can get coders to write the same stuff in C so that it would save a couple of megs of ram. Besides, you can optimize very well for size in Java too by not using heavy weight stuff like String objects for everything. If you plan on using a lot of strings, roll your own 8-bit string containers and write a separate handler class for it to minimize overhead for methods in the string container class. Just because you're not programming in assembly doesn't mean you have to - to quote you - have your head up your ass when you make design decisions.

It is a "True OO" language. It's is a "High Level" language. The higher level the language, and the more OO the language, the slower it runs and the more memory it takes up. That's a FACT.

Yes, you are very right there. There doesn't have to be a huge overhead in OO (as opposed to using structs with function pointers for instance) but the way you write an OO app usually means that you have a lot of method calls going on from object to object. If you want to write a very fast and also size optimized Java app, you can do it the same way you would in C. Yes it will be slower. Yes it will eat more RAM. But it will most probably also be fast and small enough, unless you're coding an OS, a game or a web browser.

As an obvious starting point, garbage collection. It's very nice and you can be lazy about keeping track of your objects, but it causes overhead.

Ah, you might think it's obvious and a big overhead, but it's not. First of all, garbage collection happens much more rarely than people think and it doesn't take nearly as long as people often think. In a large application, gc is more efficient than manual malloc & free. Why? Because complex apps have complex object life cycles that you have to track yourself if you have no gc. You might have references to memory from several places in an app with several threads and it's not easy to know when something can be freed. Having a *good* gc implementation do the work for you allows you to focus more on your own code. In many systems, you will find very gc-like structures for stuff like exception handling, with pointers pushed on a stack that is then cleaned up when you leave a method early due to an exception. Gc is much more convenient and not a big overhead at all. By re-using objects, you can also minimize (almost to zero in many cases) how often gc is called. That is, unless you have your head up your ass.

Re:those are your reasons?

A have to say I don't think you know what you are talking about.

First off, you are mixing up the notions of OO and "High-Level". I presume by "High-Level" you mean a "High-Level" of abstraction. It is quite possible to have an OO language which provides very little abstraction (you could take a subset of C++ and call it an OO language, and it's certainly not that high level).

"Garbage Collection" is probably not the right term to use either. What you're talking about here is automatic memory management. There is not necessarily overhead in automatic memory management, and certain techniques for automatic memory manage can reduce overhead substancially.

Good OO programming can actually significantly reduce the size of a program. Java has been used in embedded environments for this precise reason. By reusing code you save a lot of space.

Sure, assembler code can achieve essentially anything that is possible in software because it is a form of expressing the exact instructions you are sending to the processor. That being said, in the real world, you don't have an infinite amount of time to optimize your code. You have a fixed amount of time, and as a consequence your assembler programming team is usually going to get it's butt kicked. C compilers have been outperforming hand assembly for quite a while now, and Java is certainly capable of the same feat. It's just a matter of time.

Java's real overhead comes from the VM. There's a signifcant amount of overhead in that. Now, in some projects, the relative overhead of the VM is puny, and so Java proves to be an exceptionally efficient language. In others, the VM is 10x the size of what you'd expect the whole program to consume. There you are screwed.

For specific tasks, C (which is considered pretty low level by most) has been beaten by APL, Lisp, Self, Smalltalk, and yes... even Java. It just depends on how well the people writing the software for these different languages tuned it for specific operations. If you are working at a low enough level, you can do that for yourself, which is a nice advantage in some situations. Unfortunately, the price you pay the rest of the time consumes more than enough of your time that you'll never have a chance to do that optimization.

Re:those are your reasons?

I think one thing to keep in mind here is the progression of things.

Years ago, people programed computers by rearraning pluggable wire connections.

Years later, we had machine code, them ASM, then started to get more functional languages like Fortran, Cobal, C, etc. Now we seem to be moving into OO languages with Java, Smalltalk, C++, etc. (let's forget how *pure* they are).

The same thing has happened with OS's and programs. People are becoming removed from the hardware. More layers are being inserted inbetween.

Both of those things are OK because memory keeps getting cheaper and computers keep getting faster. This enables us to force the computer to do more work so the numan has to do less. That goes for using the computer, programming the computer, assembling the computer (anyone remember the pre-PnP days?)

So, I argue that the fact that Java is slower isn't a bad thing. It's faster development at the cost of runtime speed, just like Justin Dubs said. The older technologies will probably never die out (Lego Mindstorms uses pluggable wires of sorts), but they will no longer be mainstream.

Who knows what the future holds?

Re:Fighting the Logo Removal

For the record,

"Fair use" is a copyright conmcept, not a trademark concept.

As usual, Cmdr Taco displays his "amazing grasp" of intellectual property law.

Why would anyone want portable code on servers???

If I buy a $70k whiz-bang machine, I want to exploit all of the cool platform-dependent hardware on that machine.

Damn straight I want to address the actual devices I plonked down all that money for.

Don't confuse the language with the IDE

Java the language is adequate.

Java' VM is very immature (the could take a page or five from the Smalltalk people who've been improving theirs since 1980,) and it shows.

Java the suite of libraries is in the same state as the VM and again could learn from the folks who've been at it a lot longer.

Java the IDE is pathetic except for IBM's VisualAge for Java which is almost as good as Smalltalk's IDE (VisualWorks, VisualAge for Smalltalk, Dolphin or even the late, lamented VisualWorksSmalltalk.)

Basically C++, C#, Java and Smalltalk (even Perl, CLOS and php,) as languages are roughly equivalent and its possible to write translators between them.

The IDEs are what make the difference and if you want a look at the best, check out Squeak [squeak.org] to see just what you can get for free.

Don't let the syntax defeat you. Its actually the correct one for an object-oriented expression. If you can understand RPN calculators, you have the mental equipment to grok Smalltalk.

Re:Java bad

I just thought I'd correct some of your misconceptions about Java. Are you absolutely sure none of the pages use java? Most java usage now is on the server side using Beans or JSPs. The JSP pages generate the HTML code your browser reads. While there might not be any applets on any sites you visit, java might be generating the content that you are reading.

Now to counter your java bashing:
I have never seen a cleaner network/socket interface than I have seen in java. I know C,C++ and perl. Java's interface for networks is incredible. There's no way you could implement something that uses any networked functionality in less code than you'd use in java. It's very abstracted, and clean.

Java is not a 'buzzword' any more than linux is. I work at a large web company, and I only code in java...under linux. The java API (with a few exceptions) is truly excellent.

I'm no die hard sun supporter either. Java does have serious problems. Because of the VM architecture, another layer of possible bugs can creep in to your applications. I had an instance a while back where a buggy VM was causing serious problems in one of my applications. Thank heavens I was using linux where a quick network sniff (ethereal is golden) determined the problem was indeed with the VM. Then I called sun, and they refused to admit they had a problem. However, because of the extremely clean network implementation, I was able to re-code some low level modules in about three days.

To sum it up, java has its problems, but I really think you're missing the point here.

Re:I can't stand Java, but maybe that's just me...

Jeez - someone needs to get down off their soapbox.

Yes Java is more wordy than some languages, personally I like that. I like the fact that it looks more like english than C. It makes it more readable. But if you don't agree then fine don't write stuff in Java.

As for your comments on the IDE, you seem a little confused. If you didn't like VisualAge (I assume thats what you used as you mentioned IBM) then use something else. JBuilder is great, Cafe is supposed to be good, emacs is fine, hell use vi if you like. I actually did a fair amount of my early java coding with nothing more than vi and jdk. You then go on to rant about JavaBeans and the API without really explaining why you don't like them. The two are entirely unrelated - the API is simply a set of default classes. Again, if you don't like them don't use them, but in my experiences there is some great stuff in there (like the Collection classes for one example). JavaBeans is a standard which your classes may _choose_ to comply with, which means they can be freely dropped into any other JavaBeans aware application. Yes you lose a little flexibility if you use beans, but the power you gain is significant. Being able to code up, for instance, an extension to your preferred IDE and have it seamlessly appear in the menu/toolbars is great. Surely that kind of thing is just what open source is supposed to be about??

You mention data-hiding. You don't need to have get and set methods for every field you idiot - just the ones you want to be accessable!! Of course you can have true private members and just have no accessors - totally legal. If you want it to implement serialisable/beans then there are a couple of issues but it's no big deal.

Naming conventions...nothing that important. The convention is that methods look like "thisIsAMethod" and classes look like "ThisIsAClass". But it will still compile if you call it "this_is_a_class" so don't worry.

C++ is a messy, dangerous part-OO, part-declarative travesty built on top of C, which is a generally decent language if you really need to hit the metal. For writing large scale business oriented apps I'd recommend Java in almost all cases.

Re:He who likes Java does not know other languages

There is no connection.

I think there is a connection, though kalifa didn't state it: functional programming. ML-based languages are functional, and Python has some very useful functional-ish constructs, especially in 2.0.

Both make it natural to pass around strings, lists, other structured data, and function references around, but in Java you're limited to simple types and objects.

Want a method to call you back to do some calculation? In Java, you can't tell it your own method or lambda function, you have to make a new object which implements the interface the external method expects to be able to call. Major PITA. Want an (int, string, boolean) tuple? Have fun creating a whole new class to describe it, or surrounding a Vector with ugly (Cast)s.

(unrelated rant) And is it just me, or are Java exceptions completely useless? I thought the whole idea of exceptions was to bubble error conditions up to the nearest level of execution that knows how to handle them, but Java requires you to include what possible exceptions can be thrown in the method interface, so it's impractical to not handle exceptions as soon as they occur. It's no better than checking the return code from a function call in C. Actually it's worse since you don't even have the option of *not* checking it; if you don't catch (...), it won't compile, even for exceptions that will never ever happen.

--
This comment was brought to you by And Clover.

those are your reasons?

it takes to.long.to.get.to.my.method(half, of, the, time);

Huh? And how is this any different from if you have a pointer to a struct with a pointer to a struct with a pointer to a struct in C? If you feel like it, you can have everything declared global and even write code outside of methods. Yes, you actually can do that in Java even though most people don't know it:

public class TryMe {
static {
System.out.println("i am not in a method");
}
public static void main(String[] args) {
System.out.println("i am in main()");
}
}

And of course in a properly designed app you don't HAVE to type long stuff like that because the complexity is hidden in the objects. All that point shows, Taco, is that you can't code object oriented languages properly. Read up on your design patterns...

and then there's the fact that when Java was new and exciting I wrote a video game in it, only to have Sun cease-and-desist me for calling it "Java Invaders".

What does that have to do with Java? That has to do with *SUN*.

(oh, and have you ever noticed that our logo isn't the sun logo? They cease-and-desisted us for using their logo here to, even tho that is definitely fair use).

And again.. SUN - not Java.

Other then that, my only problem with Java is that the VM in Netscape is crap.

And now Netscape instead of Java.. This is actually a reason many people think Java is inheritly unstable and slow tho so it's a little sad. The company I work for has several large scale sites running Java in business critical functions and have uptimes of months and months. No crashes, no speed issues, no Netscape VM's.

Oh, and their licensing.

J2SE is free for anyone to use. It's source code is downloadable so you can see how everything works. Granted J2EE has a pretty lame licensing scheme, as do J2ME but most "Linux people" don't know what J2EE *IS* and that most of it can be downloaded separately without the lame licenses.

And the fact that its bloated.

Yes, that really is a problem isn't it? A Java 2 SE runtime download is about 5 MB.. That's terrible! Takes 30 seconds on a decent network connection.. and who has hard drive space for that anyway?

And the fact that I don't have enough time to type in all the reasons it irritated me *grin*

I think you don't have any good reasons really. If those were your two cents, I'd be asking for change...

Re:Taco, Chill.

That's where I've always thought Java was slow- with GUIs. Not a little "Hello World" or currency converter app, but in actual applications, Java is slow as molasses, IMHO. Java is pretty fast for straight numbers, but it seems to drop the ball for real world apps. Which is not surprising- Java wasn't meant to scale so high.

There are a lot of other options (that aren't so slow) for cross-platform apps, including GUIs. Some are more cross-platform than others.

Speaking of GUI api, have you ever heard of OpenStep, er, rather YellowBox, I mean Cocoa [apple.com]?

Java isn't going anywhere?

Java was a great idea let down by a flawed implementation and a flawed corporate strategy IMHO. What I think is that whilst the language itself isn't really going anywhere fast, the idea behind it will live on.

Java is used by almost every major player in every major industry in the U.S. and beyond [sun.com]. Personal Java runs on the myriad embedded systems with their own JVM [ibutton.com] and even American Express credit cards [sun.com]. Java servlets and JSP run myriad websites from mail.com [mail.com] to First Union [firstunion.com]. Enterprise Java Beans [sun.com] and it's associate web server platforms has spawned a cottage industry of server platform developers that include IBM, Bea, Allaire and more. Java ships with a free fully functional CORBA orb [sun.com] which allows for rapid development of robust, multi-tiered distributed applications.

Simply because all the C hackers and Perl users on Slashdot aren't using Java does not mean that it isn't going anywhere fast. I haven't seen a new Linux app coded in Lisp or Smalltalk in a while, this doesn't mean they are dead.

And it seems as though Microsoft have learned the lesson from this that Sun didn't, so I expect C# to go places Java never will.

C# will be a Microsoft only language which already puts it behind Java in places it can go. Standardization of the syntax of the language is useless if all the underlying DCOM/COM+/.NET infrastructure exists only on Windows.

On the other hand, I recently wrote a testing tool for a multibillion dollar corporation that sells SCM software to several Fortune five hundred companies, over the summer and noticed that Java is almost Write Once Run Anywhere as originally promised by Sun. The company I worked for supports six different platforms and is considering supporting Linux as a seventh. Their languages of choice for building tools for cross-platform development were Perl and Java. The chances of them switching all that to C# and losing over 50 per cent of their customers? ZERO

Of course the actual apps were written in Motif/MFC depending on the platform



Grabel's Law

Java is well accepted by OS

I originally wasn't going to write a response to this, thinking that the whole premise was ludicrous. There doesn't have to be linux support for Java, you just write java and it runs on any platform. There is a large amount of Open Source support for Java, from the Giant Java Tree [gjt.org], to the Java [apache.org], Jakarta [apache.org], and XML [apache.org] Apache projects. There is even an Open Source application server called Enhyra [enhydra.org] that supports pretty much everything you would expect from an enterprise class J2EE server. And if you don't like open source, then BEA's WebLogic server runs fine on Linux.

So why is there an impression that the Linux community doesn't support Java? One thing I will say is that if you are a Java supporter, you probably aren't a strong Linux supporter. That is because Java is platform independent. A Java developer doesn't care what platform they are on. Before people respond to this with the typical FUD that Java isn't cross, platform, bear in mind that all of the open source projects above run on all the platforms I've ever used them on, without any recompilation. Xerces worked on Win2K and linux. Tomcat worked on Win2K, linux, and Solaris. I don't know about weblogic, since I haven't tries moving the binaries over (I just used the rpm on linux, install on Win2K). Development in Java is development in Java. If you do it right (meaning don't setLayout(null)), it'll work. If you're server side, you have no worries.

That being said, Blackdown supports JDK1.3, the latest release of the JDK on any other platform. It seems that the majority of the OS developers I know from the projects I listed use linux as their development machine. And let's face it, Java is giving linux a lot of credibility in the server side market because it's sinking in that spending 20,000 on a single Sparc if better spent on a cluster of linux machines running (insert appserver du jour here).

Finally, you can go ahead and say that it isn't making any headway on the desktop. Well, that's true, but it isn't making headway on any platform's desktop. Linux is no exception.

You can try to say that it isn't making headway in the embedded market, but with the KVM for larger embedded devices (>40K RAM), and real-time specification [sun.com] fromt the community development, you'd be wrong.

I'm surprised that JDJ would print such tripe. I'm not surprised that Slashdot twisted it even farther and threw in a bunch of FUD.

Java misconceptions

This is slightly offtopic, but there are lots of Java misconceptions by people who either haven't worked with it, or who have played with it for a day or two without really understanding what it's all about. I see a few mentioned here in user comments:

Common Java misconceptions

• Java is slow - for most apps (client AND server-side), Java is pretty damn fast. I've seen lots of cases where developers were so much more productive in Java than C++ so that they were able to write sophisticated caching algorithms to speed things up much faster than they could have done in other languages. Early implementations of applet classloaders (Netscape, Microsoft) were pretty dumb and hit the network for every class (yuk) but there are better ways to do that nowadays. JITs and HotSpot bring raw Java to C/C++ speed. Period.
• Linux and Java don't mix - this is bs. I've been developing on Java/Linux for years now, and while there have been quirks and generally things take longer to get ported, it runs just fine. Once we started getting the IBM VM on Linux things really picked up, and now Linux is pretty close in terms of getting the newer APIs near when they come out (look at JDK1.3 and JMF performance pack as examples)
• Java must be opensourced - I'm going to get crucified for this, but I like Sun having control over Java. The source code is there, so I can always look at the library and VM code whenever I want. Sure, there are a number of bugs that have been outstanding for a bit too long, but I think Sun is getting better at fixing the more annoying ones. Sun has been pretty good at coming out with timely enhancements and I don't want that process slowed down to the point of being Mozilla-esqe (years to release a product).
• crossplatform doesn't work - this misconception is brought to you by the same people who generally claim Java is slow--people who loaded one or two applets and think that represents what Java is all about. Sure, browsers had (and still have I'm sure, though I don't code applets nowadays) major issues with GUI events and widget painting, but Swing helps out here quite a bit and I believe browsers are at least a little better. In any case, GUI apps and server-side apps are great cross-platform. I have a number of both that I regularly write under Linux and run under NT/Solaris, and my cross-platform issues are very, very, very few.

...and too many other misconceptions to mention.

Re:Was the logo really removed?

Using the Sun logo when showing a Sun story doesn't leave any ambiguity (heck, it says SUN all over it), but the swirly cup used on a generic (non-Sun specific) Java discussion waters down their trademark... kind of the whole Kleenex/Band-Aid sort of thing (though I still don't usually think of Sun when I hear 'Java', like I don't think of Kimberly Clark when I hear Kleenex - just any old tissue substance).

--

C++ attracts the wrong kind of programmer

Its not "lazy" to worry about performance later. Its best practice. The first pass at a product should get the functionality right, get the bugs out, and keep the design clean. The second pass - possibly before the initial release - should involve testing for the acceptability of performance, profiling to locate the problems, and changes to the design to remove these.
In my experience Java tends to attract people who want their code to reflect what its intended to do, whereas C++ tends to attract people who like to write obscure code for "performance reasons" because it makes them feel clever. The pleasant thing about Java is that issues with the language do not get in the way of expressing what you want to do.

Now, as to your example, doing a linear search or a bubble sort is sometimes acceptable. Linear search, for instance, is OK if the data set is small, the operation rare and the data structure you've got does not support something better because it was optimised for some other case. Similarly, recalling "get" methods rather than caching the result is not usually a real performance problem: the VM optimises the fetch away to nothing.

However, what you report is disturbing. I don't consider overuse of linear search, refetching of already fetched data, and so on, to be performance problems. They're sheer carelessness, and they mess up the structure and expressiveness of the code. They reflect a lack of thought in the design. As you say, laziness. I must say, however, that I've seen this kind of thing in C and C++ much more than in Java, as their lack of class libraries tempts people to do things in stupid ways to avoid having to write the code needed to do it properly.