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.

Thoughts on Java on Linux

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

Fighting the Logo Removal

Queston: Why didn't /. fight the Cease and Desist letter from Sun? If you're so sure you would have won, then why not fight? If /. is going to lecture and preach about the evils of companies and their licensing, then shouldn't it be practiced as well? I realize its a question of money and time, but doesn't it make sense that a site so bent on advocacy should take up the banner when given the opportunity?

Taco, Chill.

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

Yes, the VM causes a larger memory overhead and bloating. That's the nature of a VM, and I don't fault java for it because you can compile natively and not use the VM. However, the bloat I am referring to comes from the nature of the java language.

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.

If you want fast small programs, use assembler. It'll take you a week to write Hello World but it'll only take a single clock cycles to run. C is slower and bigger than assembler, but faster to code in and more portable. C++ is even more scalable but a little slower and bigger memory-wise. Java is bigger and slower than C++ because it's higher-level and more OO. Lisp and Scheme are even higher.

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. True OO design makes code more modular and more scalable and a hell of a lot easier to program big projects. But it also makes it slower and take up more memory. That's a truth of OO programming that you learn to live with.

You can write a big project in java in fractions of the time it would take you in C, much less assembler, but I guarantee you that when it did get finished in assembler it would blow your java code out of the water in terms of speed. But your code would blow the assembler out of the water in terms of maintainability.

The world is full or tradeoffs and that's one of 'em.
1) Language is more High Level -> Language is slower and takes up more memory
2) Language is closer to machine code -> You have more power over the machine -> Code can be faster
3) Code is abstracted -> Less control over actual generated machine code -> Code is slower

Justin Dubs

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

#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

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

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?

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.

Support for Java

I find that Linux supports java really well. When I'm installing RH7 I need all the coffee I can get...

Re:Simply annoying...

Dude, use Emacs and learn what C-x a-i-l means. It turns on abbreviations. When I was writing servlets I never typed more than three characters to call a method -- I had autoexpansion on.

While you're at it, learn to use the speedbar and autogeneration of skeleton methods in JDE.

Too bad you can't tune any kernels in Java, or I'd probably still be working in it. (and Perl)

A Java-coding Linux supporter

I'd like to consider myself a strong Linux supporter, and I've been working almost exclusively in Java and Perl for the last 5 years.

I'm getting ready pretty soon to release version 1.0 of my network directory management system [utexas.edu] for various platform, including Linux. It will be interesting to see how many people shy away from it solely because of it being written in Java. I am completely confident that the work we have done could not have been accomplished with 4 times the resources using any other programming environment that is available today, let alone 5 years ago when we started.

Re:He who likes Java does not know other languages

You can call any method in any object in java through the reflecion api. The java.lang.reflect package includes all the info you could want. It is possible (and relatively simple) to write a java program that reads as a string the name of a class from the command line, loads that class on the fly, outputs the names of all its methods and paramaters, instantiates it, calls whatever methods you want etc. It is one of the languages most powerful features. I have java programs that can load classes and use them just by having the classes name in a propertied file. No need for dlls or anything like that, just knowing the name is enough.

Of course you have being modded up nicely for your misinformed rant so well done. There is a Method class that can be used for a callback, quite easily it must be said. You might want to take the time to look it up. And what of javas other powers, Its multithreading is some of the easiest you can ever use, It has a uniform database access API that you can actually use accross multiple databases without changing any code. Its network code is clean, easy to use and very solid. And of course the executable is the source code. Why do people give out about java not being open source when any java class file is inherently reverse engineerable. Once you have the class, you have the code. Some people obfuscate alright but you generally have pretty usable code just from decompiling.

Not everyone...

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

Embedded Java??

Linux's real strength lies in embedded widgetry of all ilks. In that market Linux is starting to make a major dent in what had been a purely proprietary OS market.

Another worry of the Linux community, indeed of the embedded community in general, is the stability of the Java code base. Unlike desktop computers with a few years' life span, it's not unusual to find embedded devices that are expected to run unattended for 10-15 years. Java is simply changing too fast right now to provide the comfort level that embedded developers need.

Did this bother anyone besides me? Judging from the Slashdot discussion, embedded systems are not exactly the biggest thing on Linux folks' minds. And the second quote doesn't make much sense to me. If your car or your portable game box is going to have Java inside, it's not going to break because a new version of Java comes out. Whatever version of the VM is burned into the roms is going to remain burned into the roms.

Actually, it seems to me that the reasons many applets are a disaster don't apply at all to embedded Java: browser and VM incompatibilities, slow startup times.

If there are any Slashdotters involved in this thriving embedded Linux community, could they comment?

--

Java

All of these posts are only telling half the story, of a quiet revolution that is happening in the computer centers of major companies adopting Java, open source philosophies in enabling business processes.

First, let me state, that Java as a language and Java as an implementation are two very different things.

The posts on Slash.dot here are referring to Java as an implementation, big slow etc, which in fact is true in _some_ instances.

But not true in others. It also isn't the only _implementation_ that is possible, so don't blame Sun for all of these implementation issues.

Java as a language reference can be implemented in both VM and native form.

That means, you don't need a jvm to run your Java program kiddies.

The OOD and OOP implementation benefits the language brings to the table, really, is an acknolwedgement that Software Engineering hasn't advanced very much in the past 30 years.

This is the FIRST language in my opinion that recognizes this fact. I know, I hire people to write ecom software. Software that cannot afford to have too many critical mistakes in it that result in lost dollars or unsafe transactions/privacy issues for the individual/companies. Software that must be designed/run in environments that usually bridges the gap between old and new, and provides direct access to a companies business systems. Also very much firsts, for customers who only requirement is that they use a web browser.

I have seen how this works. Companies who started out on small systems, such as NT boxes that have had to move to large SUN RISC environments after a year or two to meet demand.

Complete whole Ecom systems, moved without a single rewrite of 10's of thousands of lines of code on totally alien environments form where they have been built and ran. In my 15 years, I have never seen this happen before with off the shelf software. It is a true advancement, a real pay off.

A payoff Microsoft does NOT want you to have.

Our tools have become better, certainly some of our methods have improved, but the quality and maintainability of a vast majority of the software that is written is still not very good. (That is being overly complementary in my opinion.)

Java repesents I think an acknowledgement that for the first time, addresses a couple of points that for my business, dare I say software engineering economics (we build and write Ecom software for mission critical sites using ONLY java and open source platforms like Linux, to deploy them) is critical:

First Point is Code Reusability

What does Java have to offer that other languages don't? Reusability with a twist, and that twist is it pulls a API that I can count on between platforms.

Does anyone here have any idea what that means if you want to live in a world that tolerates a large number of OS platforms and you want to do business?

The holy grail in business process/technology is write once and run anywhere. It also has been the driving force behind C's portability and various gnu initiatives. It also We who write software have been seeking in the business world for 3 decades.

It isn't just a business desire either. How many here would like to play Homeworld on a linux box? How about MechWarrior 4???

For the first time I am seeing it actually work on a huge number of platforms, Sun, HP, Linux, As400's, S390's, Intel, with NO effort to port code for a single line.

It is not possible to do this with any other software development technology at such a low cost point and still allow everyone to pick what they want to run as thier OS platform of choice.

I am not sure everyone here understands what this means to organizations who want to save money and still be able to support platform OS diversity, given the kinds of posts I have seen.

-gc

Re:java?

By the time anything is aproaching standardization and wide spread use it is obsolete.

Its a catch-22, if a product is wide spread and popular then you have to maintain compatibility or risk upseting the user base. Thats a big part of the reason why the x86 architecture is still in use. There are things chip manufacturers can do to greatly improve chip performance but they break the ever important backwards compatibility. Joe User dosen't care if a chip is a RISC or a CISC chip so long as he can run Windows and type his spreadsheet. But Joe User is comforted by the fact that if he wants to run Wolfenstien on his system that all the hardware changes over the years haven't made that impossible.

The same goes for standardization. There is a Java standard set by Sun, and every browser of note has a Java VM in it. Sun has to be very careful about what they do to Java because while I'm sure there is stuff they could do to make Java better, have more functionality etc, they run the risk of breaking both the VM and angering programmers who have made an investment in learning Java as it exists today.

Any tool or library goes through an early stage where it is very dynamic and flowing, because the number of people affected is minimal. As it gains wider acceptance the development cycle slows down and eventually the tool stagnates. Somewhere along the line someone develops a new tool that surpases the old tool in one way or another. Around the time that the new tools functionality begins to exceed that of the old tools is when the new tool will stagnate. Why? Because at this point more and more people will start to use it because it is better. But the more people that use it the more any changes have to be analyzed for their impact.

Take a look at Motif vs GTK. As I understand it both are windowing toolkits. For the longest time Motif was "it" when it came to graphical toolkits. But it stagnated, part of the stagnation was that it didn't go open source. Along comes gtk, and early on, no one uses it because the early versions stink. But that means that stuff that dosen't work well can be purged out and replaced. Then it gets big, people start switching to it from Motif, more and more people start using it. So now, every change that the developers make to the functionality of the program they have to look and see if it will help more people then it will hurt. As a result it will begin to stagnate, and something else will come down the road a little later.

Why I dislike Java

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

Re:Simply annoying...

Oh, come now. Think how java is used:
1) on the server side. Most input and output will be going through network connections, not to stdout/err.
2) on the client side. Most input and output will be going into cute graphical widgets, not to the console.

Basically, the only thing you ever use System.out for is to write debug stuff. Unless you're writing a command line app in Java (someone email me if you've EVER done this, 'kay?). So it's fine that it's buried under some heirarchy called "System." It's kind of like a programmer's backdoor (in a good way!) to get things done efficiently. If it makes you feel better, think of System.out as a Singleton and look up the Singleton pattern in "Design Patterns." Lots of applications have things that you only need one of, all around the code. That doesn't have to ruin the object heirarchy, and I don't think it does here.

Why I love Java and why I hate java

I like Java because it lets me whip on sophisticated applications much faster than C/C++/Perl (Maybe not Perl...). The Sun supplied Java classes are pretty well writeen for the most part and allow rapid application development in a cross platform manner. These classes are Java's greatest assest since they all work on any Java platform. Java is a also a great teaching language. My introductory Java class (which is very easy for me) has people writing checkers apps.

Why I Hate Java

• Swing sucks. AWT sucks. GTK+ should have Java hooks (now that Sun is a GNOME backer.) I cannot get an App that doesn't look like ass.
• Redundacy within stuff. Ex: Integer.parseInt
• Slugishness. Java gets its ass kicked by C in speed.
• Gluttony. Java gets its ass kicked by C in memory.
• No (good/easy) way to hook C/C++ code into Java.
• Browser JVM's are old ... except NS6/Mozilla. And BLOATED!!!!

Re:Simply annoying...

import java.io.*;

...

OutputStream whiner = System.out;

whiner.println("Learn Java");

That's the biggest pile of crap I've ever heard

I've been developing in Java since its introduction in '95, and it's clear that you have no idea what you're talking about.

The main problem with java is it's insecure code methods. They aren't usually used so you might not run into them

I would like to see an example of said "insecure code methods". A method in Java is not 'secure' or 'unsecure'. If you are referring to accessor and mutator methods that are declared 'public', it is up to the programmer to ensure that proper access to private data is implemented.

If you're faulting Java for accessor methods, then you might as well fault all of OO languages (Smalltalk, C++, etc.).

Basically the sandbox approach works fine until you start to abstract it.

What do you mean by 'abstract it'? Explain yourself, please.

The sandbox is a 'safe' place to run untrusted code so it does not damage the rest of your system. If the sandbox is poorly implemented, then yes, there is a risk. This is the fault of the developer, not the Java language.

Flame me if you will but this is the reason that Amercian Express got hacked last year.

Excuse me? Care to provide a link to a story on said hacking?

The next time you post on a subject you have no knowledge of, don't throw jargon around. It only exposes your ignorance.

What's good about Java

Consistently mentioned when I ask programmers what they like about Java are the following:

• Exceptions
• Garbage collection and memory management
• Interfaces
• Object oriented
• Threads
• GUI
• Built-in networking support
• Strong typing and specified widening/casting
• extensively specified operator precedence/evaluation order
• Extensive libraries included as part of the language
• cross-platform portability
• primitive type sizes are specified and platform-independent
• primitive type conversions in expressions are specified by the language
• No messy signed/unsigned/short/long/double issues. Question: in C++ what size/signedness is the result of this: uint64*1000?

For folks that think they need multiple inheritance, they haven't understood interfaces and inner classes yet.

I'm not even going to address the "issues" CmdrTaco rants about because they don't directly address the language as a tool, only his personal political attitudes.

Re:C++ attracts the wrong kind of programmer

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.

Re:Hacker Mentality

> I suspect many hackers (and that certainly covers a lot of Linux users) don't like Java
> because it is often a little too 'friendly'.

Yeah, you can actually write something like

int Count = 5;
string Text = "Count = " + Count;

without needeing an itoa() or anything. What's up with that???

IDE?!?

First, why knock Java because of its IDE? First of all, it doesn't have an IDE. IDEs are value-added products by third parties.

Second, I've never found much use in one. Give me a good text editor (read vim), a build system, CVS, and a command line. An IDE is just something pretty that makes the average programmer feel better about themselves.

In the past, IDEs have been very useful for rapid development. They allowed you to visually represent something and out pops 1000 lines of code to build that pretty window you drew. Because of the structure of Java, really object-oriented not just kind of like C++, rapid development is inherent. You subclass a window type that is pretty close (something for the Java API or your own class), spend a few lines tweaking it, and show it.

The best part is that the developer is left close to the code, not abstracted from it like rapid prototyping IDEs do. The result is fewer bugs.

No, I don't agree that IDEs make the difference.