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*

Comments

Re:those are your reasons?

[X]

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:I can't stand Java, but maybe that's just me...

[radish]

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.

Java is well accepted by OS

[Fjord]

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, to the Java, Jakarta, and XML Apache projects. There is even an Open Source application server called Enhyra 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 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

[blw]

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.

C++ attracts the wrong kind of programmer

[SimonK]

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.

Re:C++ attracts the wrong kind of programmer

[ChaosDiscord]

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.

Actually some of us prefer C++ over Java because C++ better reflects what I intend to do. Code crunching BigNums is very frustrating to write without operator overloading. Some real live code at my job reads: "s = (k - x*r) % q;" where s, k, x, r and q are all BigNums. I can easily compare this to the product's specification of this equation. Without operator overloading I'm stuck with something like "s = mod(subtract(k, multiply(x, r)), q);" Ick.

(Many people complain that operator overloading is too dangerous since operator*(BigNum lhs, BugNum rhs) might not mean what you think it means. Fair enough. Of course, there is not certainty that multiply(BigNum lhs, BugNum rhs) does what you think it means either.)

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.

Ripping on C++ for lack of class libraries is simply foolish. The core features of the STL are pervasive now. Modern compilers all have solid support for the fringier features. Having worked with a large, standard library of typesafe containers and algorithms for arbitrary types makes coding Java frustrating.

Java is a great language. C++ is very dangerous in the hands of beginners (It's a loaded machine gun helpfully pointed at your feet with the safety off). Java keeps it simple. But Java is less expressive. Larger, more dangerous languages give you more power to say what you mean, or to blow your foot off. Don't project Java's faults onto C++. If you want to find fault with C++, complain that it's too powerful (and thus dangerous) for your average programmer.

Thoughts on Java on Linux

[American AC in Paris]

This article raises some interesting points on the percieved confict of philosophy between Java and Linux. My concern, though, is that if the Linux Community Et Al. continues to snub Java, and Java continues to mature at the rate it has been maturing, will Linux be at a substantial disadvantage in terms of the maturity of Java on Linux and/or Sun's commitment to supporting Linux Java?

I mean, think about it this way. If the Linux community is snubbing Java now, just when we're starting to see viable server implementations, what will Sun's response be when the Linux developers start complaining in 2007 that Linux's Java runtimes and support are woefully inadequate, while Java runs like a charm on virtually everything else? How will Linux fare in the business world if Java becomes the language du jour for most programming needs and works well on everything but Linux?

Java is showing more and more promise, and is maturing quite quickly, despite all the jokes to the contrary. Yes, there are still a lot of things Sun needs to fix (Swing, graphics, and many other desktop/UI elements are still decidedly sub-par) but Java is getting better, and won't be going away anytime soon. If nobody in the Linux world cares to use Java, what will Sun care about supporting Linux, now and in the future?

$ man reality

Taco, Chill.

[kevlar]

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

Thats not Java's fault. Its Netscape's. Also, you can REPLACE the VM in Netscape with whatever you want. You can even run applets with Swing components in them with the proper setup.

As for Java being slow, there is a JIT (Just In Time) compiler for it, as well as numerous native code compilers for Java.

I have not experienced Java's slowness as ever being a serious problem. If I'm doing number crunching, I use JNI. If I'm doing network stuff, then the interpreter is always faster than the networks ability.

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

[harmonica]

#define const public static final

Thank God they didn't include macros in Java. Whenever I have to read larger portions of other people's C and C++ code they're the ultimate source for confusion. In terms of maintainability, they're hell.

Re:Java Exceptions

[_xeno_]

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.

Oh my, you must be right - let's see, a String, List, and other structured data are all... OBJECTS! Imagine that. And function references can get quite ugly, although as mentioned in another reply, try using java.lang.reflect.Method - which is, you guessed it, an OBJECT! I guess passing objects around is really limiting. Except, of course, Java is object orientated.

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.

Oh my, you're right! There's absolutely no way for a class to implement the interface itself. That would mean something like...

public class MainWindow extends Frame implements KeyListener, MouseListener, MouseMotionListener, WindowListener

There's no way to implement the interface in your main object at all. Can't be.

As for passing tuples, yeah, that can be a pain. Try using an Object[] array unless you really have a variable number of return results. And not surprisingly, creating a new class is actually the right solution. Although I really see no difficulty in just making a new .java file for the new class, or, depending on circumstance, using a public inner class. I suppose typing

public class Tuple {
public int number;
public String text;
public boolean bool;
}

Is really difficult. And creating a new file - my what a hardship. Of course, you could also add those lines inside the class that returns it - it would be an inner class. But given your apparent knowledge of Java, you already know that, right?

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.

Um, OK, yeah. There's a useless and incorrect rant. Java exceptions are insanely useful, far more useful than error codes. And you can bubble them up - I have a method that reads in a file and interprets the data. One of the exceptions it throws is IOException. Should an IO error occur, I don't have to check it in the method itself. The load method completely ignores the possibility of an I/O error, since the error would prevent it from successfully loading anyway. Since it doesn't update any class data until after it's finished with I/O, it's safe to handle it that way. As soon as it has succesfully loaded data, it does some post-processing and then updates internal data structures. Should there be any error, it throws an exception.

Next question: Why would you ever want to ignore an exception? Doing that strikes me as bad programming. I suppose you ignore return codes in C programs too. If the method claims it can throw the exception, there's probably a reason for it! And if you "know" the exception will never be thrown, then just

try {
// Do Whatever
} catch (UselessException ue) {
// do nothing, it'll never be thrown
}

Maybe the requirement to list exceptions that your method throws is just to help make sure that when you use the method elsewhere, you know what it'll throw? I know, that would be something like being forced to document error codes that your function returns. A real hardship.

(Also, if you want an exception that you can safely not catch, make it extend RuntimeException - RuntimeExceptions don't need to be caught. However, if they make it all the way to the top-level (ie, no function ever catches it) they will halt the program. Often, this is a good thing - usually continued running would be bad anyway. And if not, then, well, you should have caught the exception!)

Server side is its strength

[jdesbonnet]

I've stopped taking client side Java seriously
years ago.

Its at the server end where Java really shines. I've tried many application development environments, but you just can't beat Java for
fast, scaleable and easily maintainable
web apps.

There may be hope for the client side yet, but
last I looked Swing was still too slow for
comfortable use on the Linux port of Sun's JDK.

Who jilted whom?

[brlewis]

It's Sun/Javasoft that jilted the Linux community, not the other way around. Linux releases of Sun's Java hava lagged way behind Solaris/Windows releases. NetBSD has it even worse -- they still can only run Java 1.1.

The GNU project is stepping up its recognition of free Java-based software now that free tools like Kaffe have matured more, so I don't think the free software issue is as big as the article makes it. I can't speak for the embedded issues.

Not everyone...

[jmstetter]

As a longtime linux user and C/C++/Java programmer, I beg to differ. Anytime we start making generalizations about such a broad group of people (such as all linux folks), we begin to display a lack of understanding of the group itself. All of us are not using linux because of the philisophical underpinnings of open source, to some of us, it is not about religion, it's about practicality. Am I an embedded programmer? No. I'm a server-side guy myself, and nothing works better than Apache+Tomcat (as well as playing around with some sweet non-open source servlet engines as well). JSP's and servlets rock, and run great on my 2.2.x boxen. Doesn't run with the 2.4 series? Then I won't use it. Don't like java? Then don't use it. But don't tell me that it's crap, because it's not. Again, just a lowly geek's opinion, but just had to share...

Why I dislike Java

[PureFiction]

There are a few reasons why I dislike Java on a purely technical basis:

- No multiple inheritance. None. Which means you either klidge your design, or use aggregation. Neither of which is pretty in a case where multiple inheritance would work best.

- Memory management. If you have a larger application, with complex processing, the memory manager can stall your application for hundreds of milliseconds during the full sweep garbage collection. They still have not solved this satisfactorilly. If your application has tight time contraints, this can be a severe problem.

- The finalize method of dervied classes must explicitly call the finalize method of the base class. Why in the hell did they do this?

There are some good points though, which, once the above are solved would make Java superior to most other languages:

- Incremental garbage collection. True incremental collection, with no more sweep checks.

- Threads. Java threads kick ass. Period.

- Libraries. Java has a library for everything under the sun.

- Portability. I love the fact that you can take a jar file and run it opn any VM (almost). This is a real time saver.

Your mileage may vary... ;)