How Much Java in the Linux World?

jg21 writes "Java is 'incredibly heavily used' in the Linux community, according to Sun's James Gosling, one of Java's co-creators. Gosling was debating Stanford's Lawrence Lessig, Apache co-founder Brian Behlendorf, IBM's Rod Smith, and others at JavaOne this week about the possible merits of open-sourcing Java vs the market's demand for continuing compatibility. But Behlendorf seemed not to agree. So who was right, how many Slashdotters are also Java users? Is "incredibly heavily used" an overstatement by Gosling, who after all helped create the language and therefore might be biased?"

Comments

C/C++, not java

[TheCoop1984]

Afaik the most heavily used language is C/C++ and not java. Although its used in openoffice and jedit, no other java programs I use regularly spring to mind (unless they're masquerading as something else). C/C++ ar ehte most heavily used, not java, since its used for the kernel and all the 'base' programs

Re:C/C++, not java

[Pieroxy]

How many enterprise web application do you know that is written in C/C++? Cause that's where the money is these days....

Re:C/C++, not java

[Anonymous Coward]

I'm sure most enterprise systems are coded in Java not C++. Sure all the new open source desktop stuff is being done in C/C++ .... but search a job site for 'Java Linux' and then 'C++ Linux' and compare the number of hits.

Re:C/C++, not java

[halowolf]

Please lets not go to language wars yet again! :)

When it comes to programming, I believe in the right tool for the right job. I predominately program in Java but it doesn't mean I use it to solve every programming problem I have. I use scripting languages and whatever else is appropriate to get the job done.

I only wish more of my peers could understand this :(

Re:C/C++, not java

[iapetus]

Nobody said Java was better for those applications. Just that it's extremely widely used there, along with Linux - and based on my experience I'd tend to agree.

Re:C/C++, not java

[Dr. Eldon Tyrell TC]

There is no such thing like C/C++! C and C++ are different languages with different standards.

Re:C/C++, not java

[furball]

+5 insightful to parent if I had the mod points.

People who lump C and C++ together have a shallow idea of how those languages work.

Re:C/C++, not java

[Decaff]

I use scripting languages

Why not try running scripting languages with Java? You can use Jython (Python in Java), Groovy, BeanShell (dynamically typed scripting Java) or Jacl (TCL in Java). This way you can pick the right tool for the job within the same application, and package it all up together.

Re:C/C++, not java

[halowolf]

Thats nice of you to say, but I wasn't talking about the suitability of Java for open source projects. I was just saying what my philosphy on the use of programming languages was.

Re:C/C++, not java

[nwbvt]

"Although its used in openoffice and jedit, no other java programs I use regularly spring to mind (unless they're masquerading as something else)."
Well if we are limiting this discussion to desktop applications (which is not always Java's forte), eclipse and netbeans come to mind (though they are primarily used by Java developers).

You do have to keep in mind Java is still somewhat new, so of course most of the 'base' programs are done in C. That doesn't mean people aren't using Java, it means they are not re-writing all the old stuff that was done in C (I don't think there are any plans with replacing vi with a Java clone anytime soon). I can tell you I do some development on Linux with Java.

Re:C/C++, not java

[angel'o'sphere]

I think the question was about new crafted programs and wether you as a code use java. The question was not wether most installed programs are Java or not, which would be ridiculous.

Why is that worth a /. storry? You only need to search on sourceforge or freshmeat to realize that the majority of new projects start in Java.

All people I know program mainly in Java and script in Python ... Commercial projects are either for the Windows platform, and then likely in Visual C++ or Visual Basic, or they are platform neutral and then they are done 90% of the time in Java.

angel'o'sphere

Re:C/C++, not java

[sniggly]

What about Perl or PHP or Python; Quite a few C and C++ programmers that moved to using scripting languages. The quote is not about enterprise programming it's about how often its being used in the Linux community and in that community there are HUGE numbers of people who are using scripting languages. I've learned C in the '80s and didn't consider PHP suitable but the horsepower of modern CPUs makes PHP a totally legitimate solution nowadays; you can do very complex things in it, almost all C functions are included with often the same syntax and on the other hand beginning programmers or web developers can very rapidly learn it. I find the wording "incredibly heavily used" weird from someone like Gosling, "widespread use" would be perhaps applicable but Java has nothing like the kind of community that PHP has.

Re:C/C++, not java

[TRACK-YOUR-POSITION]

As someone else pointed out the slash can indicate disjunction, but in this case I think C/C++ indicates conjunction--it truly and accurately means C AND C++. C++ not only contains almost all of C as a subset, but you can call C code from C++, and in some cases with effort vice versa.

Languages are abstract, fuzzy things. If want to define a new language as a combination of English and Japanese, there's nothing to stop me from doing that. (I'd only be able to speak and understand half of it, but that doesn't stop me from defining.) Now, you might be complaining that computer languages aren't fuzzy at all and must be defined precisely--but I can simply refer you to the ways in which C and C++ are frequently used together in actual projects--the language "C/C++" is implementation defined. An annoying but common way to define a language (it's the way English is defined--they're supposed to write dictionaries based on how we talk, not vice-versa). So, technically and logically, C/C++ is a "language".

But perhaps this is about more than the pedantics of what is and is not a language, but some sort of cultural reason you feel C and C++ need to be kept seperate--presumably because you like one a more than the other. Well, too bad. I go to the bookstore and see a Science Fiction/Fantasy section of books, even though plenty of people in either genre would object to being so grouped, because to everyone outside the genres in question they are nearly the same.

Re:C/C++, not java

[Dr. Eldon Tyrell TC]

"but some sort of cultural reason you feel C and C++ need to be kept seperate--presumably because you like one a more than the other."

Yes, you can call C code from C++ and there is no problem as long as the C code still was compiled with a C compiler and then linked with your C++ code.

The very problem starts when people take code written in C and compile it with a C++ compiler!

Why? Because for the first look (and sometimes even the second) it works perfectly. But after a while debugging fuzzy problems you recognize that the syntax of the languages are indeed different and if the original programmer was not using a s**t load of brackets (not necessary in C) because he was aware that some morron someday might use a C++ compiler with this code, you are in trouble. This is why I am pointing this out: if you are not aware that they are indeed different you might get into trouble.

Re:C/C++, not java

[Anonymous Coward]

> How many enterprise web application

None. However, when we speek about the "linux world" in this context, we usually mean client applications.

There are *no* java client applications running on Linux. This has technical reasons, for one Swing does not fit into X11 world, second, Sun forbits distributing Java with Free (as in freedom) distributions (Debian, RedHat, Slackware, ...).

However, there are some Linux applications which are written in a Java variant (GCJ uses CNI, not JNI) which ship with the RedHat Enterprise Linux. But again, these are not java applications but applications written in java and compiled with gcj into native code.

Re:C/C++, not java

[johannesg]

The grandparent poster has a point, but he has it in the wrong context. Sometimes you see statements like, "C/C++ is a bad language". In cases such as these the two languages are obviously treated as one language, which has a specific property. However, since they are two very different languages (even though one fully encapsulates the other!), such statements are usually indicative of a severe lack of understanding of C++.

However, in this context this isn't a problem. It is perfectly valid to say things like, "there are more projects in C and C++ than in Java". It may or may not be true (I don't know), but at least it doesn't presume C and C++ are the same language.

Still, I understand the problem with the "C/C++" phrase. Usually it is used by people who think there is only one language (or maybe one language and another that is 99% the same, except it has "classes"). It bothers me because I am one of those apparently rare people who has programmed lots in both languages, and now hates C and loves C++. Throwing them together as if they are the same feels wrong.

Re:C/C++, not java

[EpsCylonB]

There is no such thing like C/C++! C and C++ are different languages with different standards.

See this is why people don't like nerds, no one said they were the same thing but they often get grouped together because of history, stop being so pedantic.

Re:C/C++, not java

[srussell]

Although its used in openoffice and jedit, no other java programs I use regularly spring to mind

Most of your Java usage, then, is probably invisible to you, being servlets running on websites that you visit.

My only real complaint about Java clients on Linux, at the moment, is the fact that they integrate so poorly. I can't drag-n-drop from KDE into Java apps. Java applications can't make use of things like KParts, and therefore re-implement a lot of wheels, which is tedious for both developers and users.

The VMs have come a long way in terms of speed on both the client and the server, but integration is a pretty major limitation for some people -- heck, I won't even use Gnome apps for the same reason. I'd rather use a shell, where I can at least pipe data between commands.

Re:C/C++, not java

[TRACK-YOUR-POSITION]

Hey, I'll say that. "C/C++ is a bad language for certain purposes". The two languages share enough attributes that for anything that doesn't involve low level byte manipulation, or frequent calls to C/C++ code, or, even more critically, frequent calls from C/C++ code, that there is almost always a better alternative. Like I say, you guys might not like to be grouped together, but from the perspective of Java/perl/python/whatever, you're basically the same. Everything is relative.

Re:C/C++, not java

[Ryan Huddleston]

I personally use a couple of Java client applications on my Linux desktop..

Azureus and LimeWire are both written in Java.

And that about "Swing does not fit in the X11 word" is just a lie. Swing works fine in X11 under Linux. You should really try some of these things out before posting whatever you pull out of your ass.

Re:C/C++, not java

[halowolf]

Why? Because the problems I solve with scripts do not require the complexity of running them through Java :)

Re:C/C++, not java

[halowolf]

Well its interesting that you bring up the phrase "Swing does not fit in the X11 word" (is that world) because Azureus uses SWT (Standard Widget Toolkit), not Swing. SWT is a thin API layer that is integrate with the native window system. It has been used most effectivly in the Eclipse Platform.

You will find that the windowing performance of a SWT Java application far exeeds that of a Java Swing application, for very obvious reasons.

Being a avid Eclipse user, I can spot SWT from 50 feet!

Re:C/C++, not java

[johannesg]

Sorry, but this just proves my point. If you think C and C++ are basically the same you do not understand C++. That's ok, but don't presume that you can make sweeping statements like that and be taken serious by people like me (admittedly, that is only important if you try to get hired by us...).

Here's the major difference, and it isn't anything technical really:

Programming in C, you will always be writing code in the solution domain. And every little thing that doesn't involve manipulation of a built-in type (think strings or arrays) is a source of pain and a potential hazard.

Programming in C++, assuming you know what you are doing (too many people don't), you will be writing code in the problem domain. You no longer worry about things like strings (you have a class that lets you treat it like a built-in type) or arrays (you have a template that makes sure you do not overrun any boundaries).

Now, I'm _not_ saying that C++ is the perfect language (it isn't), or that it should be used for everything (it shouldn't), or that there are no other languages out there that don't have those features (there are). What I am saying is that C++ is a completely different language from C, and throwing them together like that doesn't make any sense. You might as well say "C/SmallTalk/Python is a bad language for certain purposes."

Picking apart your message a bit, I note that Java also shares many attributes with C++. Does that mean there is almost always a better alternative for it as well?

And I'm not entirely certain what you mean with "you guys might not like to be grouped together", but let me assure you I am not a computer language ;-)

Re:C/C++, not java

[sageman]

Eclipse, yes. I love eclipse, I really do. I use it for all my C/C++ projects, as well as my Java projects. Course, still use good 'ol emacs for little things, perl scripts and lisp programming. Emacs is great, don't get me wrong, its amazing, can do things that eclipse probally won't ever be able to do (play games, read email, et cetera), but doesn't need to either. Both are great programs, but as a developer's tool Eclipse is definitely more intuitive and it also draws converts from VC++ too.

As far as other Java programs, can also include apps written by hackers for their own need. Just some guys that want a quick-to-write app to do something, like visually organize music or whatever. Sure the program is slower than if you wrote it in c++, but you don't care, you just want a quick little app to use, you're not releasing it commercially, et cetera, and the speed increase between c/++ and java is decreasing, plus the time to develop is typically much shorter for java than a c/++ app, thanks, no doubt, in part to garbage collection, which the newer algorithms used are becoming so efficient that garbage collectors average case is nearly as good as the most run-of-the-mill memory management techniques in non-GC langauges (and much better when poorly coded memory management is implemented, of course).

Now, as far as plans with replacing vi with a Java clone, check this out.

Re:C/C++, not java

[dekeji]

For enterprise applications, sensible people should use something higher level than either C/C++ or Java.

Re:C/C++, not java

[Ryan Huddleston]

meh, sorry about the typo. I know that Azureus uses SWT. But I am pretty sure that LimeWire uses Swing, and my main point was that standard Swing applications work just fine with X11.

Re:C/C++, not java

[kyknos.org]

why to use something you do not need? if python is enough, why use jython?

Re:C/C++, not java

[FatherOfONe]

You say Swing is slower than SWT. I say show me the benchmarks. Specifically I want to see how, in a standard business app doing something in SWT will increase a users productivity over Swing. I don't want to see stuff like this window opened in .001 seconds faster.

I also say that we had AWT which is very similar in design to SWING. I have done some work with Java clients and found Swing to be a huge pain in the ass.... BUT one thing it has going for it is that you know what the heck the layouts are going to look like. Secifically if you develop something with SWT, and run it on different platforms, the windows will look different. That can flat out suck. From a developer perspective I "might" want to have a common look and feel for this app, and SWING provides that. SWT does not. The only advantage of SWT is that it is suppose to be faster, and have the native look and feel of the OS it is running on. I say show me SWT for NetWare? My PDA? My cell phone... you get the idea.

So again I say show me the advantage of using SWT over Swing. Specifically in performance, that will relate to increase productivity to a user.

Lastly, to be on topic :-)

All of our Linux machines run Java in some shape or way. I would agree that Java has played a large factor in Linux growth. I would also say that a reason for Java's growth in the server world is largely in part to Linux and IBM. Without Linux, we would be an all Windows shop, and then we would have to ask why we develop in Java when we are all Windows. Without Java we would have to pick a language that we could easily develop on our desktops (Windows) and then move to test and production. That would probably be some Microsoft language.

So I say to all the anti Java people who love Linux and open source... We need each other. The Java people want nothing more than for Linux/BSD to become THE OS of choice.

Re:C/C++, not java

[halowolf]

What complexity?

Why the compounding of a task into another task to achieve the same result. Running the scripts I require to run through Java adds another step to running them that I do not require. Therefore it is a solution to a problem that is more complex than alternate solutions that exist to the same problem.

How is that complex?

It is more complex than what I require. Since you do not know what I do, you are hardly in a position to judge. I on the other hand can readily judge whether running my scripts through Java is something that I require. Believe me, its not.

Is that complex?

No, and this is where things get delicious, I'm talking about scripting, you know, writing text files with commands in them that you launch using a command interpreter of some kind. Not running a command prompt that the so called "Examples" of yours show. Its actually more complex to call a script from Java than your poor examples reflect. How about a link to demonstrate: BeanShell Example - Calling scripts from Java

If it is, I think you should be careful about what problems you are trying to solve. Stick to simple ones.

I think that you should perhaps take some of your own advice. I know how to run a command prompt, I know how to run a script, I know how to run Java. Some other advice I would offer would be to actually not insult people in a public forum. You might not be prepared for the consequences.

Re:C/C++, not java

[Decaff]

why to use something you do not need? if python is enough, why use jython?

Because it gives you more power. With scripting languages on Java you have access to all Java APIs - GUIs, threading, collections, network, multimedia, etc. It also allows you to seamlessly mix-and-match bits of code in different languages: You can call your Java code from the scripting language.

Because it allows for code-reuse. If you already have code written in Python, why bother to re-write it if you have to develop in Java? If you have some neat Java libraries, you can call them up from Python, TCL, BeanShell, Smalltalk, Prolog, Ada, COBOL, Pascal, Forth, Modula, Oberon, or any other of hundreds of languages that run on the JVM.

Re:C/C++, not java

[mabinogi]

but the point was, that the jobs using scripts, weere working ok using scripts.

Adding more power doesn't help anything when lack of power was not a problem in the first place.

Re:C/C++, not java

[Cereal Box]

I think it's probably because Java is a much cleaner language than C++ and has a massive standard library. That cuts development time and bugs down tremendously. Building Java applications is a lot easier, as generally building a component of an application (or an entire application itself) boils down to a single "compile all files in this directory" command. But for anything more complicated, Ant is lightyears ahead of makefiles.

Most universities now teach object orientation with java (something I don't agree to, I prefer C++ for learning OOP)

Why would you prefer C++ to Java for teaching OOP concepts? So students can get bogged down in all the cruft and baggage associated with C++? Java is a far cleaner language, allowing you to focus on pure OOP concepts as opposed to kludgy hacks built on top of a procedural language.

OTOH, corporations prefer Java to reduce costs in case of porting apps

From my experience, the corporate choice of Java boils down to TIME. A Java app can be developed in FAR less time than a C++ app.

Re:C/C++, not java

[Decaff]

Running the scripts I require to run through Java adds another step to running them that I do not require.

Its not another step - its simply an alternate step. You use a Java interpeter for the script as against one written in C or C++.

I'm talking about scripting, you know, writing text files with commands in them that you launch using a command interpreter of some kind.

But that is exactly what these Java shells are - simple command interpreters. Nothing more, nothing less.

Its actually more complex to call a script from Java than your poor examples reflect.

The link you gave was an example of using the scripting language embedded, not command line. Using embedded scripts is fiddly in any language.
Although, the example you have via the link is certainly not complex:

Object result = new bsh.Interpreter().source("myscript.bsh");

its one method call, giving the script file name.

My point was that you can do this:

java Bsh.jar
% x = new MyClass();

then you can call methods on existing java classes using a dynamically typed scripting language.

Since you do not know what I do, you are hardly in a position to judge.

You said, in a public forum, that it was 'complex', and you gave no examples. If you gave examples, people could comment on them and judge them. If you don't give examples, you can only expect people to comment on what you actually say, which was an unqualified statement that running scripts using a Java interpreter is complex.

Some other advice I would offer would be to actually not insult people in a public forum. You might not be prepared for the consequences.

I apologise, it was uncessary and rude. But this is Slashdot, and a place for 'robust' debate. However, as I said, I apologise.

Re:C/C++, not java

[gabebear]

Drag-and-Drop is pretty crappy all over Linux, I was trying to find a MP3 player that would let me drag and drop songs into K3B to burn CDs, and after going through a ton of players I found rythmbox (Gnome's music player), it was the only player I found that worked.

MacOS is the only OS I've ever seen that does drag-n-drop well. Windows's support for drag-n-drop is better than Linux, but it bugs me that you can't use that bar at the bottom of the screen to open files in apps that are running, and that when you drop a file into a a program about half the time it creates a weird link to the file instead of opening it.

Re:C/C++, not java

[Decaff]

Adding more power doesn't help anything when lack of power was not a problem in the first place.

True, and I take your point. I guess what I was trying to say is that Java and scripting are not exclusive options, and that if you need it th e power to combine the two is there.

Re:C/C++, not java

[wideBlueSkies]

I think it depends on the application being written. I'm only talking about Unix/Linux/BSD flavored systems here.

The 3 channels I see for business related applications are as follows:

Enterprise applications: Java/J2EE.
Desktop applications: C/C++ Java.
Utilities/support: Scripting. perl/phython/ksh.

Everyone is rolling out J2EE systems even for critical strategic applications.

But bad experiences with Java performance on the desktop are keeping a lot of folks from using it currrently. Hence, a tremendous amount of C++ development in that space. Though still some Java.

The admins like to script. It's quick, easy and powerful. Perl still rules. Though I see a bit more Python these days.

Of course this reflects current trends, and is subject to change over the next 5 -> 7 years.

The underlying OS is irrelevant really. There's enough support or compatability in all languages for all the major(Enterprise ready) OS's / distros to make the OS transparent to the average developer.

wbs.

Re:C/C++, not java

[urbanRealist]

I'm a C++/Java developer for a structured finance company. Our front end is web-based and uses Java servlets. Our backend engines that do calculations manipulating a huge amount of data are written in C++.

For me, it's been like that throughout my programming career. Java isn't that great for serious computational work, but it is a very nice language that I use where ever I can. Perfect for anything client-server or for user interfaces.

Between Java and C++ I might just be able to take over the world....bwa ha ha!

Re:C/C++, not java

[drolli]

No - actually I think it might be faster than cpython who dies not have a JIT

Re:C/C++, not java

[caseih]

How much is java used in OpenOffice? OpenOffice is all C++ as far as I know, except that you can use Java to extend it and control it. I've heard several people complain about how slow OpenOffice is and blaim it on Java, which is ignorant since it is written in C++.

Eclipse is an example of a successful Java program. And with SWT and GTK and other GUI bindings, I see no reason for it not to be more widely used. That said, I think we'll see a lot more mono (C#)-based GTK apps on linux than java in the near future.

Re:C/C++, not java

[Milo77]

As far as SWT versus swing its all about trade-offs. They take two different approaches, and neither approach can be said to be superior 100% of the time. It depends on what you're trying to accomplish. If you're obsessed with a native OS look-n-feel, then I'd go with SWT. If you're obsessed with your app looking identically on each OS, or you want broader OS support for your app, go with swing.

If I am writing a desktop app, I like for that app to be as tightly integrated with that desktop as possible. Maybe I want the win32 version of my app to leverage an existing activeX control (possible through SWT, but frowned upon by the JAVA purist). To some of us, its is worth the little extra effort to take advantage of these things on the platforms that they're available on. Remember, almost by definition, swing has to appeal to the least-common-denominator. Besides if I wanted to absolutely make sure my app was avaialble on every platform I'd probably go the web-app direction, and not with swing or SWT.

I love JAVA (develop with it professionally), but it is an "lsd" solution. Well, it is if you insist on being a purist. Just do a search on all the hacks out there to use environment variables from JAVA. The purist says, "don't use them, not all platforms have them." I like having the majority of my business logic in JAVA, but I also like giving my customers an application that takes full advantage of the platform they're on, be it linux, mswindows, or macosx.

Re:C/C++, not java

[willCode4Beer.com]

Regarding reasons to use SWT over Swing.

My reasons are two fold. First is the JFace API also provided by Eclipse. JFace provide a nice GUI framework without getting in the way. This leeds to less code and more productive development.

My second may not last long. Using the GCJ, I can compile SWT apps as native Win/Lin/Mac apps (using my cross-compiling techniques). Now, I admit that if the classpath.org guys get swing support up that this last argument goes away.

I've programmed using Swing for quite some time but, now that I've started using SWT/JFace, I don't think I'll go back.

(Now if I could only get SWT/QT integration....)

Re:C/C++, not java

[Dausha]

Actually, C/C++ is a language. Where C++ is an incremental improvement over C, C/C++ is a mere fraction of C. (If C were 3 then C++ would be 4, thus 3/4.)

Re:C/C++, not java

[SpaceTux]

1:
"Java people want nothing more for Linux/BSD to become THE OS of choice."

Sure! That's why Java multi platform! ;-)

They want Java to be the development platform language of choice!

2:
When you (user) choose your platform, you choose your GUI, possibly with a preferred theme.

If you (developer) want your application to be used on different platforms, you must put effort to offer a genuine GUI for that platform, and YES, Java, SWING and SWT will give some help with that!

3:
GJC is putting great effort to create a open source Java API. The only thing that is missing (= what is not in their API and no good alternative for), is the complete SWING / AWT packages, mainly because GTK/Gnome and QT/KDE offer Java bindings as well. SWT in combination with the (promising) SwingWT is a good alternative, since it will also run well on Win32 systems.

4:
Free Linux distros can't include Sun's JVM, and thereby neither a lot of (free software) Java Applications (at least Swing / AWT based). If people start to use SWT or SwingWT, that will be improved! (These Java apps can even be natively compiled for these distros)

Don't misunderstand me: I love Java and I'm grateful to Sun. But I think it's time for Sun to open things up, before they're put out of the market!

BTW: SWT is one of IBM's Eclipse's sub projects. I never thought Eclipse itself is such a "Sun-blocker", but what about SWT?! :-)

Re:C/C++, not java

[SageMusings]

Because you are able to use all the Java Library code. I can't imagine saying, "No thanks, I do not want any library enhancements for my Python."

Hey, use it if it is available.

Re:C/C++, not java

[ryen]

alot of times when i look at large corporate project, old and new, i find that perl pops its head in for script maintenence, server controlling, etc,etc. it may not be the primary language for many projects, but many times it is needed in one way or another.

Re:C/C++, not java

[mmusson]

If you want to use Swing, then use it. I have programmed using both and I prefer SWT.

1. SWT is noticeably faster than Swing. When I use an interface I don't want to see any lag, when my development machine is much more powerful than the typical user machine.

2. SWT looks native. Users probably couldn't tell that it was written in Java. I have a pet peeve about applications that don't look consistent with everything else. If I have chosen a UI theme I don't want some applications ignoring my choice.

3. SWT consumes less memory.

4. SWT has a easier programming model.

Java the language is suited to any OS. Java the environment is in competition with the OS. The Java environment provides the features for your program which makes it much less important which OS the Java environment happens to be running on.

Re:C/C++, not java

[EnigmaticSource]

Indeed there are differences, but C is indeed the superset of C++. If you properly code your C [read ANSI C], it's 100% compatible.

Honestly I get tired of newbies and know-it-alls that assume because thier C compiles it's `correct`. A native C compiler can and does make assumtions that a C++ compiler cannot afford to make, but that does not mean that they're not 100% compatible if you conform to standards.

(note to the non-greybeards: C++ originally was basically a OOP pre-processor to a C compiler, and was designed to be a subset of C, particularly because of that restriction [source, `Borland C++ Techniques & Utilities`, 1993 and `Advanced Programming in the UNIX environment`, 1992)

Re:C/C++, not java

[TRACK-YOUR-POSITION]

What I am saying is that C++ is a completely different language from C, and throwing them together like that doesn't make any sense. C is not a completely different language from C++. It's just not. One is almost a superset of the other. Completely different means nothing in common. I'm saying there are facts that are true of both of them: both of them will have you doing far more in the solution domain than any other language I mentioned, no matter how much you know--you must have never written a C++ program outside a CS intro class if you beleive otherwise. The potential for segmentation faults is probably the biggest similarity--for that alone, I think C/C++ is completely unsuitable for any code in a hostile environment. True, there are similarities between Java and C++, and I think it would be fair to talk about C++/Java, though C/C++/Java would be pushing it. (There's no transitivity in slashes.) Nor am I saying that there is always a better alternative--the exceptions I listed were actually pretty broad--anything needing low level code, anything needing to call C or C++, anything needing to be called C or C++. That's a huge chunk of code today, though as virtual machines and just in time code and other advanced features get better, it's a dwinding chunk. By you guys, I'm talking about people who identify with their programming languages.

Re:C/C++, not java

[frisket]

I use [...] whatever else is appropriate to get the job done. I only wish more of my peers could understand this

Damn right. They said "use Java", which doesn't necessarily mean "write programs in Java".

I use applications written in Java daily, some of them very heavily (Tomcat, Cocoon, Saxon, etc). I don't use them because they're written in Java: I use them because they are tools for the job I do. They could be written in COBOL for all I care.

The pro-Java lobby need to give up this attitude that people use Java applications primarily because they're written in Java. They don't. They use them because they coincidentally happen to do a task that needs doing.

C programmers used to have the same attitude (probably still do, although no-one I know admits to writing C still :-). When the latest whizz-kid successor to Java somes along, this will all change too.

--
Any language which starts by defining its main routine to be void must be brain-dead.

Re:C/C++, not java

[fyngyrz]

All of ours are written in C. 14 of them. Several are very large indeed - millions of lines of source.

When we need a higher level language - meaning, when speed is not an issue, or not much of an issue and we'd rather have more "oomph" in the language, we use Python. Writing in Python is so much cleaner - primarily because of the lack of bracing requirements - and it is so much easier to maintain, that it wins hands down over Java.

One more thing: We do absolutely no client-side stuff - no scripting on web pages, no flash, etc. The company outlook is that it's not appropriate to force a web surfer to have to download a plugin, nor to consume their computer's horsepower for tasks we want done. One immediate benefit is that our stuff works for everybody, on just about any browser and on just about any platform. From the client's perspective "it just works", and that's a Very Good Thing.

Re:C/C++, not java

[Dausha]

You need to either have your sense of bad humor examined, or read my entire comment before posting a reply. I was playing loose with the fact that the phrase "c/c++" is a valid formula in C, but I was being looser with output of that formula. Regardless of if it is c/c++ or c/++c, the result will be 1. try it out in you favorite C compiler.

As I recall, one reason why the name for C++ was because it was supposed to be better than C. If C = 1, then C++ is 2.

Then again, C# is a half step between C and D, musically. So, considering the reason above, C# is slightly worse than C++, and only slightly better than C. Leave Microsoft to miss the distinction.

Re:C/C++, not java

[bgoss]

AC noted "They don't give 2 shits about open source, which is why java is going to fail." Opps - too late. Java's already extremely successful. Damn, if only you had made your pronouncement 6-7 years ago you wouldn't look like such an ass now.

Re:C/C++, not java

[Ars-Fartsica]

How many enterprise web application do you know that is written in C/C++?

Yahoo and Google file systems. Yahoo and Google search. Oracle (sitting behind 90% of the OLTP systems).

Need more examples?

Re:C/C++, not java

[RangerElf]

Actually it does, it's a package called "psyco", if you wish to search for it. In a python script, just:

import psyco

# To JIT compile the whole application.
psyco.full()

- or -

# to accelerate a single slow function.
fast_function = psyco.proxy(slow_function)

Nice and flexible.

-gus

Re:C/C++, not java

[theshowmecanuck]

Let's first start by recognizing that except for those of us expecting a big inheritance from a rich uncle or some such nonsense, to those of us for which this thread really is of interest, we earn our living (or will be) by programming. We can also recognize that most of us will not be able to make a living programming things that we give away for free for our Linux system. Most of us will likely be working on business systems... and many of them will be enterprise systems; big or small.

That said... let's stir things up!

Most enterprise systems out there are written in Cobol!

Most *New* enterprise systems are not.

:-p

With enterprise systems, it's all based on money, not what is the best language. Your (our) managers, who are almost never technical, and who think a reference is a thick book that sits on your desk, or is something HR is supposed to check, don't give a rat's ass about what the best language or algorythm is. They care only about what gets the job done the cheapest. And Since They Pay Our Salaries, They Get The Last Word. They **don't care** if it is pretty, novel, intelligent (brute force is just fine in business), an efficient algorthym, a wonderful language, whatever. Businesses with sometimes billions of dollars on the line only care about two things: (1) Does it work? (2) Does it work in a way that doesn't piss off our customers? (Notice I didn't say make them happy? Many times that doesn't even matter.)

So the question most CIO's and managers are asking is...

What language will allow us to:

• use inexperienced programmers (who are the cheapest)?
• produce an acceptable enterprice application (*not* the _best_ application)
• produce it the fastest (time = money)? And...
• make it accessible from the web.

Of course if I were a short sighted CEO or CIO, the answer would be: who cares, let's just outsource to India or China, and let them make all the decisions for us. However the fact remains that while C/C++ are very good languages, in my experience they have a steeper learning curve, generally requiring more experienced programmers; generally take longer to program an application with; and are not as well suited to web applications as is Java. Yes C/C++ can do everything Java can and more, but in enterprise business application programming it is (unfortunately) not usually about creating the best application, but about being good enough. (And by the way, I like programming in C, but I work in Java).

Yes I am cynical. However, I am cynical for a reason.

Re:C/C++, not java

[DreamCoder]

This is a good start, but since C is technically a complete language, the first operand of the expression would always evaluate to 1, thereby prohibiting C++ from ever even being evaluated. :-p

Re:C/C++, not java

[E_elven]

Hi. My name is Elf af Elfhjelm, and I write C. And I like it.

Re:C/C++, not java

[E_elven]

C is not a superset of C++ (nor is it a subset). C++ is a superset of C.

Re:C/C++, not java

[E_elven]

Borland's excellent IDE C++builderX is also in Java, which is a shame since I only have 128MB of RAM and can't use it :/

Re:C/C++, not java

[SDPlaya]

If you end up thinking about every little thing like "strings" in C programs -- you're either writing your first C program, never heard of libraries|abstraction|reuse, or are just a ridiculously bad programmer.

There are some things that C++ makes easier through the use of certain idioms, but I think studies have not shown any real advantage in using C++ over C (or Java over C for that matter).

Re:C/C++, not java

[halowolf]

My bold statement came from personal experience and from being subjected to too many bad slow swing applications. SWT was a breath of fresh air in a slow Java GUI world. I did actually try to find some benchmarks but I didn't find anything that actually compared the two. I have read that the performance of Swing has improved signigicantly over the course of time.

When I'm sitting around waiting for a GUI to repspond not matter how long it is, I get frustrated and then my productivity can decrease.

Personally (and this is an opinion not a fact) I do not think that Java is a good language for doing graphical applications in. Perhaps its from too many bad experiences I say this. I certainly understand why its popular to use in this way since it is supported on multiple platforms, by I have never considered Java to of delivered on the write once, run anyware mantra that used to abound with Java advocates. We are a few releases into Java now, and what with all the different JDK's on different platforms with different API version numbers and such, getting one Java app to run on another system can have its moments.

I think its important for apps to have a native look and feel so that they respond in a way that a user expects on the particular OS that they are running on. I have had countless frustration trying to do windows like things in Java GUI apps and not having the apps respond as they would if they were nativly implemented. Again more frustration. By trying to implement a common set of functionality across all platforms you can loose the things unique to each platform along the way that make using that platform easier.

Re:C/C++, not java

[MobyTurbo]

Why is that worth a /. storry? You only need to search on sourceforge or freshmeat to realize that the majority of new projects start in Java.

According to a survey of sourceforge (sorry, don't have the link), C followed by C++ are the most popular. I think that Perl was also higher than Java as well. Just reading freashmeat.net on a given day would belie the idea that Java is the most popular language there.

Re:C/C++, not java

[NateTech]

Nor the bloat.

Re:C/C++, not java

[FatherOfONe]

As you mentioned.... Swing has improved in speed recently. I just downloaded 1.4.2_05 and looked at the SwingSet2.jar file, and it rocks. I set the look and feel to Windows (my platform), and it rocks.

I also develop Java Gui apps and agree that the JVM issue is somewhat of a pain, but I am looking at Webstart to help solve that.

You and I agree about native look and feel support, and I will add that when you develop a GUI you need to see what it will look like on that platform. With Swing, and a good IDE you get that. You also get the ability to use a common interface (Java look and feel) for apps that must look exactly the same on all platforms. Something that would be impossible for SWT.

What types of issues did you have with Swing and apps not responding on Windows? Also Sun has just released some new api's that let you work with the native OS. Obviously this will kill cross platform stuff, but for in house development, it may be ok. (Can't find link...)

Having said all this, I will say that Sun needs to address some issues with Swing, specifically tables are a pain to work with.

Re:C/C++, not java

[srussell]

You would have loved NeXTSTEP. You could drag-and-drop from anything to anything. I think some automatic heuristics in the GUI toolkit itself really helps here, and I'm not surprised that MacOSX inherited this from NeXTSTEP.

Re:C/C++, not java

[alien_blueprint]

Someone said: Some other advice I would offer would be to actually not insult people in a public forum. You might not be prepared for the consequences.

Then you said: ... its hard to see what the possible consequences could be (except for people being rude back to me!).

Here's one for you that has nothing to do with threats - politeness is a habit, and no matter how talented you are, you won't get very far in the real world without other people. So, in general, it's good not to get on the wrong side of people from the start, or worse without even intending to. Of course, there are exceptions, but in general you want to maintain a viable working relationships in order to get anything done (aside from, I suppose, than the most low-level functionary type work imaginable).

Now, you can try to separate your "real" life from your "online" one. You can make your Slashdot account as anonymous as you can, you can even post as an Anonymous Coward. It won't help, because being belittling, arrogant and bullying is also a habit, and will inevitably "leak" back into your real life.

I've had it start to happen to me around 4 years ago, and I've seen it in others. For independent proof, look at the people on Slashdot who go around being arrogant and insulting on Slashdot seemingly 24/7. If they haven't carefully hidden their "real" identities (always a damning step for someone who considers themselves to be a genius/uberhacker/whatever), you will *without* *fail* see that they have accomplished exactly nothing in their lives aside from perhaps getting a degree and maybe barely managing to hold down a pretty mediocre job of some kind. And it's not suprising - the real world will naturally punish that kind of behaviour, no matter how good you are, or how good you *think* you are. No one wants to deal with that kind of person, and *that* has consequences.

Note: I'm not talking about you here, even though you're basically anonymous - you flatly admitted you were wrong in another post after being very sure you were correct, and I find that (on Slashdot) almost unbelievable. I suppose that's another thing about not being a prat - it lets you be wrong with no real damage done.

Yes at least in Apache world

[unixmaster]

Check out http://jakarta.apache.org . All of projects are under Java and they are highly sophisticated open source project. Also some of http://xml.apache.org projects are under Java too. So I say not maybe highest usage but sophisticated apps are written under Java and most of them are open source.

Re:Yes at least in Apache world

[Pieroxy]

most of them are open source

What do you know about the closed source ones? Of course, the open source ones are more visible, so you just jump to the conclusion that "most" are. But what is most?

1. More apps? Nope, thousands of (not open) companies are developping Java stuff.
2. More money generated? Oh wait...
3. More lines of code? I doubt it.

Well, all in all, I think that most of the Java apps (And most of all the apps in general) are proprietary, and not open source. Sad if you want, but that's still the way it is.

Re:Yes at least in Apache world

[njdj]

http://jakarta.apache.org . All of projects are under Java
Well, duh. That's what Jakarta means within Apache. But the stuff under jakarta.apache.org is a tiny part of what the Apache organisation does. You get a better perspective if you look at their main site, http://www.apache.org , where Jakarta is just one menu item out of 23.

Re:Yes at least in Apache world

[wario78]

if you look at their main site, http://www.apache.org , where Jakarta is just one menu item out of 23

True, but many of those 23 items are former Jakarta projects that have been promoted to become top-level projects. Looking at it that way, 11 (Ant, Avalon, Cocoon, DB, Forrest, Geronimo, James, Maven, Portals, Struts & Web Services) top-level Apache projects are purely Java-based. Gavin

Re:Yes at least in Apache world

[julesh]

And of the remaining 12 items, 2 are purely administrative projects (foundation and conferences), and one (incubator) is a collection of early-stage projects, an equally high proportion of which are using Java.

For an organisation that started with a flagship project that was written in C, Apache certainly does a lot of work in Java.

Re:Yes at least in Apache world

[clone22]

The Apache products/projects have a strong presence in enterprise development because they are high quality and free (beer). However, the same companies that use them often use a commercial enterprise server such as Websphere or Weblogic running on a Unix or Win32 platform. I'm seeing companies avoiding proprietary J2EE extensions in these server products "just in case" they want to deploy on Linux + JBoss. You can run these commercial servers on Linux, but the easiest route to do so often involves purchase of a non-free Linux distro.

Re:Yes at least in Apache world

[jaaron]

Well, all in all, I think that most of the Java apps (And most of all the apps in general) are proprietary, and not open source. Sad if you want, but that's still the way it is.

Of course. If you compare the total number of proprietary java (or C/C++ for that matter) apps vs open source apps, you'll find that there are more proprietary apps. But that doesn't properly measure the influence of open source in the Java world. Open source java frameworks and libraries such as Struts, Cocoon (java at the core), JBoss, Ant, Eclipse and so forth make up the foundation of real world Java development. Those apps may be proprietary, but underneath they're using open source code.

Not just for linux though

[WebMasterP]

I develop radar software and I'm writing it in Java. This is done for cross-platorm compatibility though, not just because I want to run it on Linux.

Re:Not just for linux though

[Anonymous Coward]

But you could use C, C++, ADA, Perl, PHP, Python, Lisp, OCaml, ... as well for writing cross platform applications.
And for user interfaces you could use QT, FLTK, WxWindows, ...
And for 3D you could use OpenGL.

There might be a million reasons to use Java (and probably as many for not using it) - but writing portable code is definitely no reason.

BTW: by using a language that has different implementations (like C and C++) you should allways write portable as that impoves code quality.

Re:Not just for linux though

[titzandkunt]

"But you could use C, C++, ADA, Perl, PHP, Python, Lisp, OCaml, ... as well for writing cross platform applications. And for user interfaces you could use QT, FLTK, WxWindows, ...

And for 3D you could use OpenGL.

There might be a million reasons to use Java (and probably as many for not using it) - but writing portable code is definitely no reason. "

Why not put aside the additional effort of writing portable C, C++ etc etc, and just get on with fulfilling the specs by using... Java?

BTW, Java isn't so much about writing portable code as building portable apps.

For instance, I'm writing (part of) a biggish defense system (> GBP 300 million for HW + SW). It is an absolutely stunning timesaver to be able to develop, build & test on commodity NT boxes. The same jars are then FTP'd onto the target platform, which is not NT (and I'm not saying what it is, either). Guess what: Exact same behaviour on the target machine as on my desktop, but, each target machine costs around GBP100k, so we're happy that about all we need 'em for is soak testing - it's all inventory, you know!

Next, we can FTP the same jars to the training machines, which are commodity boxes running Linux, and guess what: No recompilation, porting or testing necessary - we get exactly the same behaviour here too. Again less inventory, and no added programming effort. Sweet!

The guys working on older products - ones that are in the maintenance phase, and will soon be phased out - are starting to be trained in Java. These guys are used to programming down to the metal, and at best having a C cross-compiler with printf's for debugging. They are, to a man, amazed at the ease with which they can slot applications together, and at the productivity they can attain with Java. One guy made a comment that stuck in my mind: "Things just work first time... this doesn't feel like programming!"

T&K.

Re:Not just for linux though

[sglow]

I also use Java for any software that needs a nice user interface. The big advantage is really the cross platform nature of Java.

Sure, C++ works cross platform, but you need some library that isn't really part of the language for lots of the details (threading, GUI interface, etc). Really not cross platform the way Java is.

I see Java's main advantage over C++ is the depth of the standard Library. When you use C, you get the C standard library. When you use C++ you pretty much still have the C standard library and maybe STL. Java gives you a very rich library and as far as I know the library is fully supported under all the platforms that Java runs on. Certainly Linux and Windows.

Re:Not just for linux though

[julesh]

I do the opposite. I write in a mixture of Java and native code that only runs on Windows. It could theoretically be ported to Linux, but I haven't done it yet.

I do this because (1) I like working in an object-oriented, garbage-collected, runtime-typed language, and Java was the most convenient for me when I started all this (I'd probably use C# & either .NET or mono if I was starting now, but I have a load of reusable code I don't want to have to port), and (2) I need to use native APIs to achieve the effets I want to. Java's OS interface just wasn't up to the job.

Doing this has given me a pretty unique insight into Java's shortcomings. It's this: AWT. The system is an abomination.

And before you say "Swing!", anything that is built as a layer on top of AWT is doomed from the start, in my opinion. AWT is badly designed and inefficiently implemented, and nothing can save it IMO.

Re:Not just for linux though

[nicolas.e]

Could you elaborate on why AWT is such a mess ? I personnaly find it pretty good.

Re:Not just for linux though

[dekeji]

Why not put aside the additional effort of writing portable C, C++ etc etc, and just get on with fulfilling the specs by using... Java?

Because there is not necessarily any "additional effort". Java makes some things easier and many other things a lot harder than C++.

Fortunately, you can have all the advantages Java gives you over C++ without many of its limitations, by using C#.

Re:Not just for linux though

[theefer]

Then try SWT (Standard Widget Toolkit), notably used for the Eclipse IDE.

Re:Not just for linux though

[iabervon]

I suspect that the Linux-Java link is largely that Java lets you run on any platform, and Linux is the best platform when you have no requirements for the platform. If you are planning to run purely Java software, you can choose your platform based on cost, performance, stability, etc., rather than worrying about features and migration cost.

I think that it is not particularly the case that Java is popular in the Linux world, but that Linux is popular (as least as a deployment platform) in the Java world, and that is a substantial portion of the Linux world as seen in business.

Re:Not just for linux though

[gbjbaanb]

quite true, however, those guys down there in the to-the-metal department will pretty soon find that they want it to do something Java doesn;t cope too well with, and then you'll see the limitations.

Your argument is a bit like windows developers going on about VB - you can do nearly everything you need a business app to do in the language, but when you step outside the cosy boundary, it becomes hell.

Re:Not just for linux though

[deanj]

Some of the event handling stuff might be under the awt libraries, but Swing wasn't built on AWT.

AWT was awful though.

Re:Not just for linux though

[gabebear]

Because there is not necessarily any "additional effort". Java makes some things easier and many other things a lot harder than C++.

One thing Java does well is portability ("the right tool for the job"). Java programs are also about as fast and somtimes faster than C++ programs in cases when you are not dealing with a GUI.

Fortunately, you can have all the advantages Java gives you over C++ without many of its limitations, by using C#

Umm, C# is Windows only, Java has really good VMs available for almost every OS. I think C# is a pretty neat language, but it's totally useless to me. The legality of Mono along with it's incomplete implementation of C# make is pretty unsuitable for anything.

Re:Not just for linux though

[dekeji]

One thing Java does well is portability ("the right tool for the job")

But Java isn't the right tool for the job when developing for multiple platforms. When I write software for Windows, Linux, and Macintosh using something like wxWindows or Qt, I know I can always make it work on all three platforms; in the worst case, I just add a little bit of platform specific code until whatever was wrong in the toolkit gets fixed. With Java, when the Java implementation doesn't work right on some platform, I'm stuck until Sun eventually gets around to fixing the problem, which may be months later, years later, or never.

From the point of view of writing for multiple platforms, Java is a disaster: it's a tool that works sometimes for cross-platform development, but you won't know whether it can get the job done until you try.

The legality of Mono along with it's incomplete implementation of C# make is pretty unsuitable for anything.

If you are willing to put up with the "legality of Java", I don't see why you have any problems with the "legality of Mono". Sun has numerous patents on Java, Sun owns most of the specifications (yes, even specifications coming out of the JCP), and if you as much as look at the specifications, you have looked at Sun intellectual property. I'll take an ANSI and ECMA standard together with a complete set of open source APIs over that any day.

As for the "completeness", Mono's C# implementation is complete and Mono gives you complete set of APIs that are not based on Microsoft's APIs. At this point, it looks like Microsoft wouldn't have a leg to stand on if they were foolish enough to challenge Mono. And that's a whole lot better than one can say about anything Java-related.

Re:Not just for linux though

[TheLastUser]

Um, ok, I want my C# app to run on Linux, oops, it doesn't work. Guess that mono just doesn't implement all the win32 "features". How about on Solaris, oops no, doesn't run their either, aix? no, irix? no, ok how about windows 98? nope.

Wonder what else it doesn't do. Does it work on my cell phone? nope, can I use it for free? no. About the only thing that it does that Java doesn't is allow /.'ers to code in C.

Its hard to believe that such a bastion of MS hate groups as /. would rather embrace an MS product like .net, than use a platform that, if not GPL, is at least given away for free by several companies, IBM, Sun, and Apple.

Before jumping on the MS band-wagon you should realize that they will never allow mono to become equal, better, or fully compatible to win32 .NET. They will move the goal posts as fast as it takes to keep their suppremacy, and keep you buying software licenses.

Re:Not just for linux though

[alext]

Just curious: have you taken steps to inform other users that Mono APIs are not based on, and thus incompatible with, Dotnet APIs?

I ask this because one could easily form the impression from Mono promotional material that it is a complete and compatible implementation of Dotnet. For example, the first sentence in the Mono FAQ reads:

The Mono Project is an open development initiative sponsored by Ximian that is working to develop an open source, Unix version of the Microsoft .NET development platform.

Obviously a well-informed and experienced developer such as yourself is aware of the real situation, but I'm sure you will agree that it would be regrettable should prospective users of Mono be misled by statements such as the above into thinking that they can first develop in Dotnet and subsequently move to Mono.

Re:Not just for linux though

[Brandybuck]

You post is a good enough example, so I'll pick on it. Nothing personal...

The question asked in the summary was "Is 'incredibly heavily used' an overstatement by Gosling"? Individual anecdotes do not demonstrate that Java is incredibly heavily used, merely that it is used. All of you telling Brian to go fsck himself for his heresy should go look up the words "incredibly" and "heavily".

Re:Not just for linux though

[gabebear]

the Mono project has done extensive background checks to make sure that they can do what they are doing without a paid license from Microsoft. One could only wish that people adopting Java had done their homework to the same degree.

Mono definately has legal issues that need to be cleared up before it should be used. Microsoft can currently kill Mono anytime they wish.

• Microsoft HAS NOT put anything under a royalty-free licence by submitting the standard to the EMCA. The EMCA stipulates that the C# standard has to be released RAND (Reasonable & Non-Discriminatory) Licence. Microsoft can start charging fees at any time for implimenting a C# VM.
• Even if they never start charging money, they have pantented the Hell out of the standard and can sue Mono for infringment.

Sun's ACSLP is a totally different story. Sun's licence is not particularly open source friendly, projects like GCJ are probably infringing on Sun's copyrights and patents and are in just as big of danger of getting killed and tainting the projects they share code with. However from a users perspective, the big difference is that you can get a SDK and VM directly and legally from SUN.

Re:Not just for linux though

[Saanvik]

What, on the portability side, does Java make "a lot harder" than C++?

Re:Not just for linux though

[JamieF]

>Linux is the best platform when you have no requirements for the platform.

Yes, Linux satisfies an empty set of requirements perfectly. Or, not at all, depending on whether the question you're asking is "how many requirements were satisfied? (0)" or " how many requirements were NOT satisfied? (0)".

OTOH, all other operating systems are equally satisfactory under these conditions... even those with no features, because they don't even exist.

Re:Not just for linux though

[SageMusings]

Your organization is training its programmers in Java?

I thought the trend was hire a programmer for a project and then fire them at the end. If you need expertise in a different language, just hire it. I honestly did not know that there were organizations that retrained its people.

Would you say this is outside the norm?

Re:Not just for linux though

[dekeji]

Just curious: have you taken steps to inform other users that Mono APIs are not based on, and thus incompatible with, Dotnet APIs?

The Mono Project itself is pretty clear about it. Like, on the left, you get the non-.NET stack in a BIG RED BOX, and on the right, you get the .NET stack in a BIG BLUE BOX. You can install one, the other, or both, depending on whether you need .NET or not. Most Linux developers and most open source developers don't need what's in the BIG BLUE BOX.

I ask this because one could easily form the impression from Mono promotional material that it is a complete and compatible implementation of Dotnet. For example, the first sentence in the Mono FAQ reads: "The Mono Project is an open development initiative sponsored by Ximian that is working to develop an open source, Unix version of the Microsoft .NET development platform."

And what is wrong with that? Ximian is sponsoring the Mono project to develop a UNIX version of the Microsoft .NET development platform. That's their business interest in it. It doesn't mean that that's all it's good for. Plenty of companies have sponsored gcc development for their purposes, but your use of it is probably completely different.

It doesn't claim that it is "complete" yet (in fact, the roadmap tells you how complete things are), although they are clearly aiming for that.

Re:Not just for linux though

[dekeji]

Mono definately has legal issues that need to be cleared up before it should be used. Microsoft can currently kill Mono anytime they wish.

With their patent portfolio and cash position, Microsoft can kill any open source project any time they wish, provided they are willing to accept the antitrust and PR backlash.

If anything, Mono is probably in a better position than other systems because this issue has been scrutinized so much.

Microsoft can start charging fees at any time for implimenting a C# VM.

If you know a legal basis for this, I'm sure the Mono project would like to know about this because they are actually quite dilligent about legal issues.

Sun's ACSLP is a totally different story.

ACSLP is just a source license; Microsoft has released a VM under similar licenses. Neither makes any difference for open source implementations or independent third party implementations because they grant you few rights.

What is a different story is the licenses on the specifications. The ECMA C# specifications are available from ECMA. But the Java specifications are available only under a restrictive license agreement with Sun.

However from a users perspective, the big difference is that you can get a SDK and VM directly and legally from SUN.

OK, so you seem to have just given up on the idea of running software based on open source systems. Instead, you choose to insulate yourself from those issues by picking a proprietary platform backed by a big company. Fine, no problem: you share that view with millions of Windows developers. I can deal with that. But please don't portray your choice as something other than what it is: the choice of one commercial vendor over another. Also, your choice has its own risks, like, for example, Sun going out of business or Sun starting to charge for their software.

Personally, I still believe that open source is a feasible proposition. Legally, I think Mono is actually in better shape than many other open source platforms because people have worried about this so much. I certainly view it as less of a risk than Java. C#'s Microsoft heritage clearly is a PR problem, however, and may mean that Mono never becomes the overwhelming success that it might become otherwise. Time will have to tell. Maybe something completely different will come along in a few years and make the point moot.

Mono/C#

[ron_ivi]

We're actually doing a Mono/C# app.

Might try Java if the Mono JVM works well, but seems Novell's focus is on C# first.

Re:Mono/C#

[jrumney]

At least Sun is not going to sue you for using Java. I'm not sure you can say the same about Microsoft and Mono once you start using the non-ECMA APIs.

Of course we use Java

[PimpbotChris]

If we didnt, do you think we would be whinging every day about it not being open source?

Java on Linux

[hardburlyboogerman]

I,for once, admit to being a newbie on Java.I have played around with the various LInux distros and haven't messed with Java too much.(Only 24 hours in a day after all).
Break out the coffee pot & caffine tabs.It's gonna be a long night.

Re:Java on Linux

[DoctorPepper]

I don't normally respond to AC's, but you do present a valid point. I am quite familiar with PHP, but at this stage in my development career, I'm not doing very much web development. Maninly desktop and client-server.

Besides, where I work, the web apps are developed in ASP :-(

If I needed to use PHP for web development, I wouldn't have a problem with learning it or using it. Until then, I am quite set on the languages front.

Careful on how you use the name "Java"

[Anonymous Writer]

You don't want to step on Sun's toes by using the name "Java" in naming something you made with it, like "Java Invaders".

Re:Careful on how you use the name "Java"

[denominateur]

Mod parent up, this is highly relevant!

Re:Careful on how you use the name "Java"

[aled]

why you would want to do that? isn't enough to put with "j" prefix abuse?

If you don't see it heavy used..

[Anonymous Coward]

..then you're not in the fucking industry.

simple as that, really. it IS heavily used(along with others).

Re:If you don't see it heavy used..

[Brandybuck]

I guess I'm not in the industry then. The only Java I use at work in the industry is this cheesy time logging program they make me use. Of course, I'm an embedded systems programmer, so I might not be in the same industry as you...

Incredible, indeed

[Anonymous Coward]

I was surprised to learn that Java is used more than Perl or C++ in projects listed on freshmeat.net.

Re:Incredible, indeed

[Anonymous Coward]

Most of the useful apps on Freshmeat are command line oriented and hence C-based. Too bad Java programs nearly always insist on a GUI. I for one would love to try out some Java command line programs.

Re:Incredible, indeed

[Anonymous Coward]

No, this is because a lot of relatively young programmers have only learned Java, not C/C++/Python/Perl/etc. in school. And because Java is hyped as being modern and cool by the media, businesses and its developers. In short Java is hypeware.

I'm willing to bet that the downloaded total of eg. Python/Perl is bigger than that of Java. Fot C/C++ this goes without saying. The nr. of downloads indicates use, not the nr. of Java projects.

Re:Incredible, indeed

[Iffy Bonzoolie]

Java is not the best for command line programs mainly because VM initialization is expensive (in terms of time). This could be possibly alleviated by having a system-level VM that was initialized at boot time or something, and programs would just attach themselves to an already-initialized VM; this would have the major disadvantage of bringing down all running Java programs if the VM crashes or one program does some naughty things. Java does have some nice facilities for seperating modules at runtime in the same VM by using ClassLoaders and such.

But, perhaps more relevantly, I think the most successful and widespread use of Java these days is on the server, which generally has no GUI unless you count web-page generation.

-If

Re:Incredible, indeed

[usrusr]

starting up a jvm just to notice that the user typed "littlejavacommandlineapp --help"? java might be not as slow as the cliche says for some things, but startup times are still less than interactive. maybe this could change with some demon thing that can just fork out when needed or something, but i could well imagine that there would be too many api blocks that had to be initialized individually for the individual configuration of every app.

Re:Incredible, indeed

[Anonymous Coward]

I wonder if all the sane people think that Java, SPF, XML, SOAP, UUDI, Aspect Oriented Programming, Six Sigma, CMM are all hype and a gigantic waste of time and money?
I should start a web site where we can light torches and realize that there is a silent majority of same people tolerating this crap because we don't realize that we can force change.

I have a dream...
We shall overcome!

Re:Incredible, indeed

[cxvx]

Java is not the best for command line programs mainly because VM initialization is expensive (in terms of time). This could be possibly alleviated by having a system-level VM that was initialized at boot time or something, and programs would just attach themselves to an already-initialized VM;

Startup time for commandline apps has impoved a lot with JDK 1.5^H^H^H 5.0.

The (albeit limited) implemetation of classdata sharing makes things run better.

All those "omg java is teh suxx0r !!1!111" people should try it once before perpetuating so called facts that stem from the days of JDK 1.O

Re:Incredible, indeed

[Thunderbear]

The VM warmup time is the major culprit here. What is needed under Linux is basically the "quick start" feature which OpenOffice and Mozilla uses under Windows.

I understand that some of this is available in Java 1.5, but this must be drawn to the logical conclusion, which Microsoft made with their java, namely that a Java-program is comparable to a c-program to launch - both for large and small programs.

Re:Incredible, indeed

[njdj]

I was surprised to learn that Java is used more than Perl or C++ in projects listed on freshmeat.net.
It isn't. More projects list Java as an implementation language than list C++ or Perl (by a very small margin, see below). But this includes projects largely written in C++ or Perl, which have a small piece written in Java. Number of mentions does not correspond with amount of use.
The most-frequently-mentioned languages on that Freshmeat page are as follows.

Language, # mentions
C, 6334
Java, 3126
Perl, 3076
C++, 3027
PHP, 2572
Nothing else is over 2000.

Re:Incredible, indeed

[Richard W.M. Jones]

Yes, I've used 'ant' which is very slow to start up, not to mention has about the worst syntax for a user-edited configuration file possible.

Rich.

Re:Incredible, indeed

[sglow]

After reading the last post I decided to do a very simple experiment. I wrote a "Hello World" java program and ran it on my Gentoo Linux box.

I would say the startup time was something like 0.5 seconds. Seemed to be faster after the first run.

Re:Incredible, indeed

[julesh]

Java is not the best for command line programs mainly because VM initialization is expensive (in terms of time). This could be possibly alleviated by having a system-level VM that was initialized at boot time.

Or using an ahead of time compiler, which is included by default in most modern Linux distributions.

Re:Incredible, indeed

[julesh]

I've used 'ant' which is very slow to start up

$ time java -jar g:/usr/local/lib/jakarta-tomcat-3.2.3/lib/ant.jar
Searching for build.xml ...
Could not locate a build file!

real 0m1.268s

Not brilliant, I guess. But that's starting it over a network connection on a 400MHz processor, using cygwin's bash which ain't exactly fast to start with. For comparison's sake:

$ time make
make: *** No targets specified and no makefile found. Stop.

real 0m0.353s

not to mention has about the worst syntax for a user-edited configuration file possible.

I ain't going to argue there! :)

Re:Incredible, indeed

[SW6]

I was surprised to learn that Java is used more than Perl or C++ in projects listed on freshmeat.net.

Ah, but how many of these projects are anything more than a logo and a large TODO file?

Re:Incredible, indeed

[angel'o'sphere]

and need 256 MB of RAM and a huge download to do the simplest thing?
A command line tool likely needs not much ram. And definitly it NEVER needs a downlaod. How silly .... how do you come to that idea?

angel'o'sphere

Re:Incredible, indeed

[angel'o'sphere]

I'm willing to bet that the downloaded total of eg. Python/Perl is bigger than that of Java.


And I'm willing to bet that Java is less than 10 years old and Perl is about 15 years old while Python is also somewhat in the range of 15 years.

Further ... your number of downloads of what? Runtime environments? Needless to say that a big deal of boxes running Java will have Perl as well? So what exactly is your point?

angel'o'sphere

Re:Incredible, indeed

[Richard W.M. Jones]

Where does the Java VM come from? It certainly doesn't ship with any of the Linux systems I use, and on them it involves a large download and a tedious installation process which doesn't use the existing package management tools and therefore cannot be automatically managed and upgraded along with the other packages. Did I mention that it isn't even Free software anyway. No thanks. I'll stick with my fast, powerful and lightweight Objective CAML programs.

Rich.

Re:Incredible, indeed

[Pharmboy]

What is needed under Linux is basically the "quick start" feature which OpenOffice and Mozilla uses under Windows.

Most geeks I know (myself included) DISABLE the quickstart feature for all apps, including DirectCD, MS or O Office and every other resident app that isn't providing a needed service. We do NOT need more programs to sit and run while they are not being used. Having the VM use a resident program would require all clients to do that, which is a tall hill to climb, for a bad idea.

Resident would be fine, I guess, if you are developing and want a faster start time, but it gives you no idea on the true responsiveness of your application for the clients who will ultimately be using the app. I just don't like the idea of having yet more resident apps consuming memory and cpu on my Windows boxes, which is already bloated and slow enough. It seems like an ugly hack, even for Mozilla or Office.

Re:Incredible, indeed

[thakadu]

Or how about a port of Linux to the JVM that could then run Java .class files "natively"?

Re:Incredible, indeed

[Richard W.M. Jones]

$ time java -jar g:/usr/local/lib/jakarta-tomcat-3.2.3/lib/ant.jar
Searching for build.xml ...
Could not locate a build file!

OK, a little bit of an unfair test because 'build.xml' doesn't exist, so presumably ant doesn't get very far.

Unfortunately (actually, fortunately for me) I've ditched any Java stuff I once had. Indeed I ditched the Java job I once had :-) So I can't do a timed test any more. But when I worked at Red Hat (on their Java CMS stuff - used to be ArsDigita), they had big complex automagically generated build.xml files that would seriously take seconds to read in. It made the build cycle more painful than it needs to be.

Nowadays I use make + ocamlc/ocamlopt and a complete rebuild of our website doesn't take more than a few seconds.

In fact (goes off the check ...)

real 0m6.157s
user 0m4.728s
sys 0m0.587s

That's the time for a complete rebuild of the website that I'm working on (35 separate OCaml files). This is on a slow Mini-ITX machine - not exactly top of the line.

Rich.

Re:Incredible, indeed

[geophile]

Java is not the best for command line programs mainly because VM initialization is expensive (in terms of time).

Which is why a Java shell is needed. Everything runs inside the shell's VM, so there is no need to load the VM for each command.

I used to be a fan of the Psion 5mx which ran Java. Startup time was horribly slow, and typing in the classpath each time was torture, so I wrote a shell for it, still obtainable here.

This shell did the right thing with ClassLoaders, so that you could edit Java source, recompile using javac (inside the shell's VM), and reload the new version of the class.

Jshell is a bit ancient, (written in JDK 1.1.4 days), but it works. And it's open source if anyone wants to continue it.

Re:Incredible, indeed

[jilles]

Tedious is standard with linux because of its packagemanagement tools which are incompatible with each other and even with earlier versions of the same tools. That is the main reason why most commercial software either supports only a very small subset of linux distributions (typically only specific versions of Red Hat) or bypass the packagemanagers entirely. That's not a Java problem. If you don't like tedious, use something else to run Java on. Linux is entirely optional. Of course if you are competent enough to get linux up and running you are more than qualified to follow the very small set of simple instructions to download and install the JRE. If you are still on a modem of course any download seems huge. But really, 10MB shouldn't be an issue any more these days, even if you are on a modem.

Of course if you download the jdk instead of just the runtime environment and an IDE you are looking at maybe 90 MB for the latest version of eclipse and another 40MB for the j2sdk.

Then the freedom issue. Yes, the SDK from SUN is not open source (though it is available for free for both commercial and non commercial use). However, open source JDKs and JREs are available (and are shipped with several linux distributions). If it makes you feel good, you can compile your gnu java with the gnu compiler and deploy it on your gnu server.

There is the small matter of the Java trademark which is indeed owned by Sun which and you may not stick on software without their permission (Just like the Mozilla foundation owns & controls the trademark for Mozilla). In practice this means that software that does not pass SUN's tests cannot be called Java. These tests are somewhat controversial and if that is what you meant by "not free" I don't disagree with you.

So unlike C, C++, packagemanagers, web browsers. The Java API is well defined (by SUN and several hundreds of major industrial and non industrial partners through the Java Community Process), and compliant open source and commercial implementations are widely available. Many of the reference implementations of J2EE APIs are open source (e.g. apache Tomcat is the reference implementation for the servlet specification). In short if you are looking for open source success stories, look no further than Java.

Finding a C++ compiler that complies 100% with the ANSI standards is nearly impossible (which is why porting applications between compilers is a major PITA) and why a minor compiler version increment requires you to update most of your linux software to versions that A) compile with the new version and B) have been compiled with the new version. 2.x to 3.x of the GNU compiler was very disruptive IMHO.

There are no standards for packagemanagers and the W3C publishes interesting, recommendations which nobody, including the intended audience of webbrowser developers, seems to be able to interpret in a consistent fashion.

Re:Incredible, indeed

[dekeji]

Strictly speaking, gcj is not "Java", as defined by Sun.

But a more serious problem is that Java lacks the signal handling, terminal control, and other features that people expect of high-quality command line programs.

So, yes, you can write some command line programs in Java, using gcj, and get decent performance. I have done it. But using Java still limits you pretty severely compared to other languages, gcj or not.

Re:Incredible, indeed

[dekeji]

Which is why a Java shell is needed. Everything runs inside the shell's VM, so there is no need to load the VM for each command.

And how is that going to work with C/C++ programs? How is that going to do signal handling? Environment variables? Pipes?

Re:Incredible, indeed

[sbrown123]

Yes, I've used 'ant' which is very slow to start up


Ant build files are written in XML which ofcourse means Ant needs an xml parser in order to read the file. For some reason they picked Xerces for the job. Xerces is well known for being feature rich but also for being bloated and slow. As for the build file structure I wouldnt say Make is much cleaner.

Anyhow, someone gave you time measurements on app startup with Ant vs Make. No, they did not run Ant on a build file because you said Ant startup was slow. The reading of the build file is not the app startup.

Re:Incredible, indeed

[the eric conspiracy]

I think the most successful and widespread use of Java these days is on the server

SInce server apps run for long periods of time, VM init is also not a factor. Resistance to memory leaks and GC also seems to be a benefit in such systems.

Re:Incredible, indeed

[12357bd]

This could be possibly alleviated by having a system-level VM that was initialized at boot time or something,

The incredible thing is that after YEARS of waiting for such a simple thing, still is not here. Incredible indeed.

Re:Incredible, indeed

[gl4ss]

yes but the guy i'm replying to seems to keep it justified that any java commandline app is slow because some complex apps are slow to load complex files!

trolling indeed!

Re:Incredible, indeed

[gbjbaanb]

well actually, yes.... SOAP for example is basically obsoleted by microsoft now (use the new .net networking stuff they say, with wizards to migrate those old soap apps).

For some of the other stuff, like CMM, you won;t find that being used outside of big, big business.

Re:Incredible, indeed

[Screaming Lunatic]

Java is not the best for command line programs mainly because VM initialization is expensive (in terms of time). This could be possibly alleviated by having a system-level VM that was initialized at boot time or something...

You mean like the operating system? The VM is redundant. Built out of spite for Microsoft. IBM had the BIOS and they had control. Microsoft built the OS on top of the BIOS and they garnered control. Sun built the VM on top of the OS and tried to garner control.

The VM is not any more useful than the operating system itself for a language like Java that is not quite high-level as Perl or Python and has envy of low-level languages like C++.

Words of wisdom for Sun and open source enthusiasts. Don't hate your enemies, it blinds you. Java is a choice forged in the pools of hate.

And once again, everybody sing it with me:

Java is not platform independent, Java is a platform. Java is not platform independent, Java is a platform. Java is not platform independent, Java is a platform. Java is not platform independent, Java is a platform.

Re:Incredible, indeed

[alext]

Are you referring to Dotnet Remoting? Or is this something else / another name?

Re:Incredible, indeed

[Curtee]

It's interesting that you suggest a VM that starts at boot time. One of the things in the somewhat near future of Java (currently being prototyped) is a sharable VM, which will run as a daemon. Each new java program will connect to the daemon and run within a single VM, rather than starting a new VM for each app. This would be done through the Isolation API (JSR 121 )

It will be interesting to see how this changes the usage patterns of Java. The claim at JavaOne this year is that jumping into an already running
VM reduces startup time by 96% for non-GUI apps, and 66% for GUI apps.

Re:Incredible, indeed

[gbjbaanb]

I wasn't really paying too much attention - you'll find the details in the VC++ .net express beta 1 that's just come out. I think it was in the 'whats new' pages.

erm... I tried to find it, but as is the way of these things, I can't now.

Re:Incredible, indeed

[Iffy Bonzoolie]

I think this could be done with the existing APIs, albiet with some annoying limitations. I had not heard of the Isolation API, but it looks like it takes the heirarchical ClassLoader concept a step further, allowing a programmatic interface to various runtime aspects of the modules. Using sibling ClassLoaders, I believe, already allows for isolation of static data and providing different classpaths.

The trick is that you would need some kind of native (or at least non-java) stub that finds the VM process and convinces it to execute the specified application. It would be great if this was built into the standard java binary, but it could easily be written as a seperate little application.

Also, as someone else mentioned, you also need to take the shell environment where the command was executed and provide that for the new application running in the existing VM. AFAIK, there's no way to do that using the existing API. I didn't actually see anything for that in the Isolation API, either, though.

Another thing is: without these Isolate changes, System.exit() from inside an app is gonna kill the whole VM... eheh... hmm...

I notice that this Isolation API is not included in the 1.5.0 beta2 javadoc... does that mean we'll be waiting for another year or two for these to be rolled in to the following release? Yeesh.

-If

Re:Incredible, indeed

[Sj0]

Though I do like Java quite a bit, from the ultimate compatiblity which means that I can run crucial apps on Windows 98/2k, BeOS, OS/2 Warp 4.0, Linux, and others(which I don't nessessarily have installed at the moment ;) ), to the "oh my god, you mean that works the same way?" joy of developing under it, there can be no doubt that it IS slow to load. Want proof? Switch javac.exe to the Jikes compiler from IBM. You've just cut your compiling times down to a fraction of the speed. How? Jikes is written in C.

Re:Incredible, indeed

[alext]

OK, thanks, will take a look.

Re:Incredible, indeed

[JamieF]

>>Which is why a Java shell is needed.
>And how is that going to work with C/C++ programs?

What a red herring this is. But, I'll play along anyway.

It could just ignore them, because those aren't part of the problem domain. Rather than trying to reinvent the wheel, it could do something new and different, and let existing tools continue to do a good job at what they were meant for.

Alternatively, it could duplicate something like sh, and behave similarly.

You suggest that Java can't run C or C++ programs, cannot "handle signals", cannot manage environment variables, and cannot manage pipes. Why? To my knowledge, all of these except for fine control over signal handling are readily addressed by java.lang.Runtime and java.lang.Process.

Unless you really care deeply about precise signal handling behavior you'd probably not need to go into undocumented territory (sun.misc.Signal and sun.misc.SignalHandler). Of course, if you got all of these things, you could then gleefully complain that this shell is not portable, since those concepts don't exist on all of the platforms that Java is available on. (Try and guess why they aren't documented.)

Re:Incredible, indeed

[Thunderbear]

Thank you for making it clear to me that the QuickLaunch facility is an incorrect metaphor.

Actually the JVM is more like the Linux Kernel, as it is needed for each and every Java-program and the slow start time is the main reason that I believe that small Java-apps have not yet found into the standard programs of Linux.

I think this would change if the JVM "quick launch" feature was an intergrated part of Linux.

Re:Incredible, indeed

[Pharmboy]

I think this would change if the JVM "quick launch" feature was an intergrated part of Linux.

Probably won't happen tho. Linus is pretty big about putting only things in the kernel that needs to be in the kernel space. I get the feeling that support to launch Java apps would only be allowed in user space, NOT kernel space, for security reasons. This means it would have to a daemon in linux, which is pretty much the same a quick launch task, its a resident application. Windows often puts this kind of stuff in the kernel, but Linux doesn't.

I am just saying that if they put a stub of Java in memory all the time, to make launching java apps faster, lots of us would disable it. Any program that you ran that sat there to make starting a java app start up faster is the same, whether you call it a quick launch, daemon, etc. It is still an ugly hack to compensate for a slow program, imho.

Re:Incredible, indeed

[angel'o'sphere]

The original poster was of the opinion that typing a command would cause a download.

Of course you need to "downlod first" if you want to run a Java command line tool. But thats true for every language ... PERL, bash, Python .... OCaml, C++/C.

angel'o'sphere

Java / Linux used at least at some places...

[herberts]

Hi,

my team is in charge of the technological foundations for all the Internet related apps pushed by our employer. Linux / Apache / Tomcat is used EVERYWHERE for all our online banking and trading systems.

Access to the legacy system is also done in Java.

I also clearly think we're not alone doing so.

lots

[primus_sucks]

I work at a fortune 500 company. My present Java project is hosted on Linux and it's planned that all upcoming projects will be as well. We are even looking at Mono for hosting our legacy ASP apps, but all new development is Java on Linux. I guess someone is tired of getting viruses that disrupt our network.

I Use it Daily

[cmacb]

I'm hooked on the stuff. If I don't have a cup first thing in the morning the whole day is shot.

I think Java should be free. Down with Starbucks!

Re:I Use it Daily

[julesh]

I've heard it said that it's becoming very difficult to acquire Java (or at least Old Brown Java, the most well known variety) these days. Apparently, the Japanese are buying so much of it, that the rest of have to make do with Aged Timor instead. It makes me wonder if what I buy from my supplier as OBJ really is. Still, there isn't much difference in quality between the two, so I can't really complain, even if I could find out they were wrong.

I know what he means

[arvindn]

Start up a JVM process and you'll find that it makes incredibly heavy use of resources. That's what he means, incredibly heavily used ;-)

Re:I know what he means

[Decaff]

Start up a JVM process and you'll find that it makes incredibly heavy use of resources.

As even the latest VMs can run in only a few megabytes of memory, and as (see recent slashdot stores) can give speeds comparable to C++, and the most recent VMs allow VM sharing - you can make use of the same VM for more than one program, you statement is false.

Re:I know what he means

[Saruman_The_Smartass]

I know you're trying to be humourous, but in my experience it seems the Linux Java JVM seems slower than its Windows counterpart. Is there any way to tune the JVM to be more efficient?

Re:I know what he means

[cxvx]

and the most recent VMs allow VM sharing - you can make use of the same VM for more than one program, you statement is false.

You don't really share a JVM, at least not on Sun's latest implementation (doesn't the Apple Implemenation actually share the JVM? I'm not sure).

What does happen is that all the core classes get memory mapped to a file at startup, which is then marked readonly. Subsequent JVM's can then also use the same mmapped file, allowing for faster startup and diminished memory usage. This process is explained in detail here.

Re:I know what he means

[Decaff]

You don't really share a JVM, at least not on Sun's latest implementation

You are right.

Re:I know what he means

[IamTheRealMike]

Does that mean you still have the overhead of storing the JITCd code blocks in memory for each process?

Re:I know what he means

[cxvx]

Does that mean you still have the overhead of storing the JITCd code blocks in memory for each process?

Judging from what is said in the atricle I linked, I'd say no:

Re:I know what he means

[cxvx]

Woops, should have hit "preview". What I wanted to say was:

Judging from what is said in the atricle I linked, I'd say no:

Second, since the shared archive contains class data in the form in which the Java Hotspot VM uses it, the memory which would otherwise be required to access the original class information in rt.jar is not needed.

Re:I know what he means

[Jon_E]

Take a look here I think you'll find that many things tend to be tuned more toward Solaris environments first.

Re:I know what he means

[deanj]

Apple's work was contributed back to Sun for inclusion in the next release (I think...might be the point release after that).

How many projects?

[Simon (S2)]

Just have a look at the projects hosted on sf.
There are 12588 projects in Java. Right behind the 13922 in C++ and the 13785 in C.

So I guess, Java IS used a lot.

Re:How many projects?

[Taladar]

This statistic says nothing about the real use of any of these languages. It just tells us how many people started projects in one of the languages but it does not tell us about the success. They might be abandoned right after they started a few lines of code or the might be very active and have a few thousand lines of code.

Re:How many projects?

[Azghoul]

True, but that snapshot view does provide a look into the popularity of the languages from a developer's point of view. You can probably assume that the "real use" of each language is equal, meaning statistically the same number of C, C++ and Java programs were dumped after a short while.

"Success" doesn't matter so much in this context, just how popular they are. I have to admit I'm surprised (and pleased, since I suck at all things pointer-related :) ) that Java is so close in this case.

Re:How many projects?

[realprog]

And even then Java has about 12588 projects because of the lower-entry level. You also see a lot of projects written in java because you have whole bunch of people who see the libraries & say.. whoo, I can put together an opensource project. I remember going through the list, and wondering shouldn't there be a minimum complexity/standard of projects before they get hosted ??

Re:How many projects?

[deanj]

That's the stupidest reasoning I've ever heard. Lower-entry isn't the reason people are putting projects up like that. By that logic, if people want easier entry into OS projects, they'd code in PHP.

People code in Java (or PHP) because it's what they choose to get the job done. It's not like there are tons of people yearning to do OS projects, and they think the easiest way to get in is by using language A or B or C.

Pretty much exclusively Java

[pivo]

I work for a company that produces a J2EE application server and J2EE web applicatons, so I'm pretty much exclusively Java and exclusively Linux. I've been using Java on Linux for work for the last five years.

Re:Pretty much exclusively Java

[TyrionEagle]

Yeah, my company is almost exclusivly Java apps on Linux servers.

This is where Java shines, on the server side. And not using Swing!

Re:Java / Linux... tomcat?!

[herberts]

Well we do not accept money from anonymous cowards ;-)

Java and OSes

[furball]

Organizations building web applications will pick a technology (Java, PHP, Perl, etc.) and then the OS to support it. No one in their right mind picks the OS then the web technology. That's just nuts.

Wal-Mart for example went with Java and Linux for their website in their early history. It's on Java and Solaris x86 today. Now what is it about Solaris x86 that could convince a cost-conscious organization like Wal-Mart to make the switch?

With Java development, the OS is completely marginalized. The question is which OS is the operation group in the organizations in question willing to support.

Re:Java and OSes

[jrumney]

Wal-Mart for example went with Java and Linux for their website in their early history. It's on Java and Solaris x86 today. Now what is it about Solaris x86 that could convince a cost-conscious organization like Wal-Mart to make the switch?

I don't know about Solaris x86, but I have found a small (5 - 10%) performance hit running Java server apps on Linux 2.4/x86 compared with both Windows/x86 and Solaris/sparc. I think it is due to the way the OS does threading (Linux threads seem heavier), but I'd like to see if 2.6 makes a difference.

Re:Java and OSes

[bmj]

I agree. I think Java is heavily used in the *nix world, because of platform mobility. I've worked on Java enterprise projects that started on Linux and then moved toward Solaris (because the company had more cash). And as people have pointed out, the majority of "enterprise" type apps are being written in Java. People are still writing "applications" and utilities in other languages, but I think it's safe to say that Java rules the roost on *nix for enterprise apps.

Re:Java and OSes

[sql*kitten]

With Java development, the OS is completely marginalized. The question is which OS is the operation group in the organizations in question willing to support.

Hmm, it's less simple than that. Java is designed to run well on processors with lots of registers, like the SPARC, which has some very efficient hardware for sharing registers (you "see" 16, but 8 overlap with the stack object "above" you and 8 "below", so you can shift data around very very quickly, no need to unload and load). On the other hand, Java on Win32/x86 is way faster, because people have invested a lot more effort in making it so.

So the OS may be marginalized (Oracle has exactly the same effect) but the hardware decision becomes more important (ditto with Oracle).

Re:Java and OSes

[pivo]

At least it used to be that the Windows JDK was better tuned for performance than even the Solaris JDK, which always seemed a little odd to me.

Recently, we've measured better performance from Linux than the same hardware running NT. Of course, that's our application server and our applications. Not a conclusive benchmark to be sure, but certainly a very large application (12K+ source files, 3.3 million lines of code).

As far as x86 v.s. sparc, how did you arrive at the performance hit conclusion? Are you looking at raw numbers or cost per some performance unit?

Re:Java and OSes

[jrumney]

As far as x86 v.s. sparc, how did you arrive at the performance hit conclusion?

Very subjectively :-). The sparc box (450MHz Ultra 3) seems to be of comparable speed to a 800MHz P2 running Windows. If the Windows JDK is better tuned for performance as you say, then it may be that the Linux and Solaris JDKs are similar speeds and it is the sparc machine that is faster rather than the JDK or OS. Since it doesn't have a CDROM, it is a bit of a pain to install Linux on the sparc just to check.

ermmm hold it folks

[sofar]

not all of us enjoy java. I have a measly p3-1ghz with 192mb of ram and when mozilla and a few other apps have filled it up for every-day use even the *smell* of java makes me sick, my lappy starts swapping and mozilla crunches to a halt.

That's just j2 plugins in my browser... openoffice with java takes 60+ seconds to start, and you think java is widespread?

seriously java might be nice but for some things it really isn't. Everytime I start a solaris admin tool using java I think "okay it saves sun development time". But in Linux? no way.

I wouldn't even touch java with a 10ft pole.

Re:ermmm hold it folks

[msobkow]

Sounds like the same whiners who complain if some ancient piece of hardware isn't supported in the kernel any more, even if it was off the market and essentially obsolete years ago.

When you have something vaguely resembling a 5-year old system with at least 256MB RAM, then you'll have a right to complain about performance. Until then, you're just penny-pinching junk hardware and it's your own damned fault you have performance problems.

Re:ermmm hold it folks

[Decaff]

openoffice with java takes 60+ seconds to start, and you think java is widespread?

Open office is not Java. Java can be used in open office to write extensions, and to provide links to database via JDBC, but Open Office will run perfectly well if you don't have Java installed.

If Open Office is slow, its because Open Office (written in C++) is slow.

Re:ermmm hold it folks

[Taladar]

If a C app runs fine on that machine and a Java one does not, what does this tell us about Java.
On High-End-Systems everything runs fine, the real differences in performance and efficiency are only seen on old systems or on systems which run more than a dozen (Java) applications at once. The latter would be the case if more of our software would be converted to Java. You can only afford the bloat of Java on a fast sytem because 90% of your apps are NOT written in Java.

Re:ermmm hold it folks

[arose]

Uuuuh. Years , how old .

Re:ermmm hold it folks

[deanj]

Man, spend the bucks on some memory before you start complaining about performance of ANYTHING. Next thing you'll be saying is that emacs sucks because it doesn't perform well in a system with 50mb of swap space....

It's your system that's performing badly; get some more memory. Even if you don't do a thing with Java, you'll be better off.

Re:ermmm hold it folks

[deanj]

Where the hell are people getting this logic from? It doesn't tell you squat about Java, any more than any other app does. That's like saying "my embedded system usings ASM language, and it's great, and this damn C program hogs memory resources, therefore it sucks".

You might have plenty of reasons to dislike Java, but spreading FUD like this doesn't get your argument any further along.

Re:ermmm hold it folks

[njcoder]

When I first started developing in java back in the late 90's we didn't even have p3-1ghz machines and things ran well. I remember doing java app server development using a tool built on netbeans on a 133mhz laptop as well as a 300mhz desktop and things ran well considering. Now with the imporvements to the jvm's over time and more advanced hardware I'm still surprised to hear people complain about the performance of java.

Re:ermmm hold it folks

[sofar]

I'll bite your flamebait:

When you have something vaguely resembling a 5-year old system with at least 256MB RAM

2 years ago this was a top notch configuration. BTW my laptop is 3 years old, not 5

and I just don't have the money lying around you jerk, some people work hard to make a living.

Re:ermmm hold it folks

[msobkow]

I call bullshit.

I've had to support far too many business laptop users over the past 5 years to believe for a second that such paltry memory was "top of the line". Maybe for an obsolete model discounted to get it off the shelves.

Aside from that, you can always spring the whole $30 it would cost to toss in another 256M.

If you knew my finances, you'd realize how far off base the "money lying around" comment is. Neither your poverty nor my finances justifies blaming products for requiring more resources than we can afford.

Complaining you don't have the computer power is like blaming a trailer manufacturer because you need to upgrade to an F250 from an Escort in order to be able to tow it. It's not the trailer manufacturer's fault you can't tow it.

Flamebait? Damn straight -- I'm tired of listening to users bitch that their ancient crap won't run new software, and whining that they can't afford to upgrade. That is neither mine nor any vendor's fault nor problem.

The hardware did what was needed when you bought it -- don't blame every one else just because your requirements changed. You should have allowed for that when you bought the machine in the first place. And I betcha it still does what you originally bought it for.

Personally?

[cloricus]

Well I guess I use Java apps a lot. I am forced to use windows for some applications so to feel at home I tend to search for cross platform programs when I need some thing. These tend to be Java based. I then install them in Linux and windows and it all works out. I would say that 3/4th of my every day programs that I use are Java. Though that could just be me. :P

It's heavily used in some areas.

[arcade]

Java is indeed heavily used - in some areas. It's in extreme usage "server-side", and many people develop applications in Java - for servers.

On the client, however, you'll find it far less often. I use a java client when no other alternatives exist. Java has always been an incredible memory hog for me. I don't like using java on the client. It's mostly slow and unresponsive.

Personally I vastly prefer to use C or C++ programs, as they tend to be much nicer to use. In addition, they tend to have the same interface as the rest of the programs in my desktop environments. ;)

Re:It's heavily used in some areas.

[primus_sucks]

Yes Swing blows on the desktop. Here are some great altenatives:

SWT - awesome windowing toolkit developed by IBM
wx4j - Java bindings for wxwindows.

Re:It's heavily used in some areas.

[julesh]

I don't like using java on the client. It's mostly slow and unresponsive.

That's mainly the fault of AWT's poor event handling model. Java programs that are written with interfaces built ground-up without using AWT tend to be just as responsive as C/C++ programs, and much more responsive than applications whose UI is built in a scripting language.

Re:It's heavily used in some areas.

[Tim C]

Java has always been an incredible memory hog for me. I don't like using java on the client. It's mostly slow and unresponsive.

While that's relatively true, in absolute terms it really depends on the spec of your machine. For instance, I use JBuilder at work, and on my machine there it's plenty responsive enough. Of course, I have a 3GHz P4 with a gig of RAM; on my old P2 450 with 512MB it was rather more painful.

Re:It's heavily used in some areas.

[deanj]

SWT blows. It's a rewrite of the very broken AWT stuff Sun never should have written in the first place.

I run swing apps all the time that work fine, but
If you're worried about Swing performance, run it with the OpenGL perference turned on.

Re:It's heavily used in some areas.

[primus_sucks]

run it with the OpenGL perference turned on.

Sure that what I'll tell all my users when I ship them a product.

SWT is not a rewrite of AWT. From the SWT project page:

SWT avoids the use of a separate peer layer as is found in the Sun AWT class library, thereby gaining increased speed and space efficiency at the cost of some amount of implementation flexibility

Re:It's heavily used in some areas.

[deanj]

Sorry, but it's a rewrite from the perspective they did exactly the same stupid thing AWT did in the first place below the covers.... Native libraries that have to be ported to each platform, and all that entails. That's why the SWT portability sucks between platforms, and don't kid yourself that it isn't there. It might be a bit better now, but it's the same stupid mistake as before. Gosling even commented on this during a keynote at JavaOne.

As for telling your users what to do.... well, that's up to you, but mine never see the "java commmand". If you're doing that, then there's a big problem. Of course, since you're using SWT, you don't have that option anyway.

Mine just click a link or run a script, simple as that. They never even see the java command.

Actually....

[Anonymous Coward]

Linux is heavily used in the Java community...

Exactly - Java is not about the O/S

[msobkow]

While I do cross-platform C/C++ development as well, when I need to make sure it's cross platform, I use Java.

Portable, standardized language and interfaces are what gives Java it's power. The community process has provided a reasonable pace of new feature integration, and has abandoned a few implementations that weren't really "ready", much as an orphaned code fork would be.

Open sourcing Java would be a mistake. Unless protected by a strong consortium of members (JCP) or by a strong backer who refuses to sell out to any one interest (M$ platform-specific extensions), Java would rapidly fragment into several code forks and become essentially useless.

It may take time to get features in through the JCP, but it also ensures there are no hastily implemented hacks making their way into the system. Quite frankly, the vast majority of OSS projects which don't come from Linus, Apache, Mozilla, or IBM have proven to be an absolutely disgusting mess of poorly and un-documented code. Java's embedded documentation is an elegant solution to the problem of keeping API manuals and source in sync, but it seems most OSS developers still haven't evolved past the "what, you can't read code?" mentality of the teenage "l33t" programming snob.

OSS means no sanity checks on feature creep, portability verification, documentation verification, regression testing, and all the other enterprise-project aspects of development that make it a useful technology. I've lost track of the number of times I've encountered platform-specific hacks in OSS code that weren't properly #ifdef-bracketed, or which just completely incompatible with other O/S implementations.

In short, Java is critical because it is portable and managed. The fact that Linux is supported is important from a rollout standpoint, but the underlying OS is (and should remain) irrelevant.

Re:Exactly - Java is not about the O/S

[Taladar]

I am working at a Java Project at the University and I have found Java to be an absolute nightmare when it comes to consistency of implementation. I agree with you in that the idea of Java was good, but the implementation of the language has absolutely no aspects of a beautiful/easy-to-use language. I could name dozens of things I encountered in the past few weeks but I will name just a few: -primitive types and associated classes: When I want to store a variable of one the primitve types like int (the ones you use in every class) you have to wrap them into a class (Integer) which has no way to change the Value later. So everytime I want to e.g. increment a counter stored this way, I have to convert it back to int, increment it und create a new Integer-Object to store the incremented value back into my container-class. -If I want to compare two Classes I have to use the equals-Method instead of a simple operator-overloading which would enable me to use == -When I retrieve an Object from a Container it is a java.lang.Object instead of the type I stored which totally negates the advantages of static typing -Attributes of a Class are not totally protected against access from the outside (I have to work with old code that makes heavy use of this) In short, Java is critical because it is portable and managed. I worked a year as a system administrator after school and I can tell you Java is nowhere near it's theoretical Portability in the field. Once I had to replace a couple of hundred JRE because one important (Java-)Software the Company used produced lots of errors on 1.3.1_04 and ran fine on 1.3.1_02. When I started the programming project for the University I mentioned above I had to install Borland Together (for UML which we had to use). I tried to install it but the InstallAnywhere insisted on using its 1.3.1 dynamically compiled JRE which did not run on my glibc 2.3 system. I had to manually unpack the installation package, use another JRE 1.3.1 to install (the installer insisted on the old version, i had installed 1.4.2 at the time). When I tried to use the JRE 1.4.2 with it later (by editing the start-shell-script) the exporting to images of the diagrams stopped working. Long story short, Java is not portable nor compatible to another version of itself, which would be no real problem if it you had the source of the old Java-Program you wanted to use but since almost all Java-Programs are closed-source this poses quite a big problem as soon as someone wants to use more than one Java-Program on his/her computer.

Re:Exactly - Java is not about the O/S

[Taladar]

And now with correct layout:

I am working at a Java Project at the University and I have found Java to be an absolute nightmare when it comes to consistency of implementation.

I agree with you in that the idea of Java was good, but the implementation of the language has absolutely no aspects of a beautiful/easy-to-use language.

I could name dozens of things I encountered in the past few weeks but I will name just a few:

-primitive types and associated classes:
When I want to store a variable of one the primitve types like int (the ones you use in every class) you have to wrap them into a class (Integer) which has no way to change the Value later. So everytime I want to e.g. increment a counter stored this way, I have to convert it back to int, increment it und create a new Integer-Object to store the incremented value back into my container-class.

-If I want to compare two Classes I have to use the equals-Method instead of a simple operator-overloading which would enable me to use ==

-When I retrieve an Object from a Container it is a java.lang.Object instead of the type I stored which totally negates the advantages of static typing

-Attributes of a Class are not totally protected against access from the outside (I have to work with old code that makes heavy use of this)

In short, Java is critical because it is portable and managed.

I worked a year as a system administrator after school and I can tell you Java is nowhere near it's theoretical Portability in the field. Once I had to replace a couple of hundred JRE because one important (Java-)Software the Company used produced lots of errors on 1.3.1_04 and ran fine on 1.3.1_02.

When I started the programming project for the University I mentioned above I had to install Borland Together (for UML which we had to use). I tried to install it but the InstallAnywhere insisted on using its 1.3.1 dynamically compiled JRE which did not run on my glibc 2.3 system. I had to manually unpack the installation package, use another JRE 1.3.1 to install (the installer insisted on the old version, i had installed 1.4.2 at the time). When I tried to use the JRE 1.4.2 with it later (by editing the start-shell-script) the exporting to images of the diagrams stopped working.

Long story short, Java is not portable nor compatible to another version of itself, which would be no real problem if it you had the source of the old Java-Program you wanted to use but since almost all Java-Programs are closed-source this poses quite a big problem as soon as someone wants to use more than one Java-Program on his/her computer.

Re:Exactly - Java is not about the O/S

[angel'o'sphere]

Hm ....

-If I want to compare two Classes I have to use the equals-Method instead of a simple operator-overloading which would enable me to use ==

If that is a problem to you, yoou should probably try to understand what the difference between "==" and .equals() is :D

BTW: in C or C++ you have the same distinction. Its called comparision by value and comparision by address, == checks for same address, that means same object. .equals() is user defined and you define "equal" as you need it for a certain type.

Together is also available as zip file, probably you should just have tried to unzip that one instead of running an InstallShield.

Regarding the incompatible versison ... you whine about 1.3x versus 1.3y .... we are at 1.5 beta now, that one fixes all your complains about int versus Integer and Container classes.

To be fair: all you complaines are somewhat valid, but: don't you think other people had the same trouble with C++ compilers? At any given point in time there where allways about 100 more different versions of C++ compilers plus environments around than we have now Java implementations. Problems like you pointed them out are rather rare!! And you could help yourself ... in C++ times it was often very difficult or impossible to help your self under such circumstances.

angel'o'sphere

Re:Exactly - Java is not about the O/S

[martin-boundary]

Quite frankly, the vast majority of OSS projects which don't come from Linus, Apache, Mozilla, or IBM have proven to be an absolutely disgusting mess of poorly and un-documented code.

Come now, what a piece of total FUD. So only commercially backed OSS is worth anything? What are you, a shill for some business outfit which shall remain nameless? By far the most important OSS project is GNU, and it doesn't even rate a mention from you. WTF? What about the BSDs?

The commercial players are merely standing on the shoulders of the community, picking and choosing what they like and more often than not making a mess of it. Need I remind you of the absolute debacle the rpm package system is, compared to Debian's? What about the semi functional, buggy system management tools each vendor (Mandrake, Red Hat, you name it) bundles with their distro, only to be abandoned and redone differently in the next version, and on and on.

There's certainly absolute utter crap in both commercially backed and hobbyist software, but it's way less simple than Linus, Apache, Mozilla + IBM versus the rest. Most great OSS is NOT company backed, just people doing their best to make something that *works*, however long it takes to build it and damn those share prices.

Re:Exactly - Java is not about the O/S

[furball]

-When I retrieve an Object from a Container it is a java.lang.Object instead of the type I stored which totally negates the advantages of static typing

I't s retrieved as java.lang.Object but that's just typing (is-a relationship). The object still retains its original typing information; hint: cast it.

Java 1.5 addresses this issue.

Re:Exactly - Java is not about the O/S

[MrWim]

BTW: in C or C++ you have the same distinction. Its called comparision by value and comparision by address, == checks for same address, that means same object. .equals() is user defined and you define "equal" as you need it for a certain type.

in C++ == will check for the same address if both side of the operator are pointers to things. If they are objects or references to objects it will do a value comparison based on a user specified function called operator==().

Re:Exactly - Java is not about the O/S

[Dr. Evil]

C++ has this nice thing called Operator Overloading, "==" can be assigned to a method. Java does not do operator overloads, it's a PITA for people who are used to having the feature.

Just to give you an idea, you could take a class like CheeseDoodle, and assign an operator== such that if a CheeseDoodle instance is compared with an integer, it will call a method which compares CheeseDoodle.quantity with the supplied integer. But if a CheeseDoodle is compared with a PotatoChip, you could choose to write a method which would declare it true or false depending on various properties of the particular instance of the CheeseDoodle or a particular instance of the PotatoChip.

Suddenly your
if (cheeseDoodle.quantity().isEqual(thingamajig))...;
if (cheeseDoodle.snackfoodindex().isEqual(potatoeChip .snackfoodindex()))...;
becomes :
if (cheeseDoodle == thingamajig) ...;
if (cheeseDoodle == potatoeChip) ...;

Yeah, it can be abused an obfuscated, I think that might be why Java avoids it, but it is damn handy.

Re:Exactly - Java is not about the O/S

[manavendra]

-primitive types and associated classes:
When I want to store a variable of one the primitve types like int (the ones you use in every class) you have to wrap them into a class (Integer) which has no way to change the Value later. So everytime I want to e.g. increment a counter stored this way, I have to convert it back to int, increment it und create a new Integer-Object to store the incremented value back into my container-class.

First of all, you dont *have* to wrap primitive types into classes. Java provides wrapper classes for all primitive data types, so you can treat them as objects if necessary. However, for most number crunching usage, you are advised to use primitive types.

-If I want to compare two Classes I have to use the equals-Method instead of a simple operator-overloading which would enable me to use ==

Right, and why would you want to overload an operator? This has been one of the hotly debated topics in Java, but the bottom line remains that the creators of Java did not think it appropriate to hide a method call (of the overloaded operator). This clarity of method invocation also maintains the readability and consistency

When I retrieve an Object from a Container it is a java.lang.Object instead of the type I stored which totally negates the advantages of static typing

What? well first of all, "static typing" implies type checking during compile time, and not run time. Secondly, when you create Containers, you want them to be generic containers that can contain any type of object and not just a particular type, and hence Containers accept and return java.lang.Object, which is the base class of all types.

Attributes of a Class are not totally protected against access from the outside (I have to work with old code that makes heavy use of this

Huh? What do you mean? Did you even read up on the access modifiers available in Java?

I won't even comment on the rest of your post, but your post smacks of supreme ignorance about basic concepts of Java. It may not be the best language (and it doesn't say it is), but trolling it because of improper usage, is unjust and foolish

Re:Exactly - Java is not about the O/S

[Azghoul]

You might have had me until this: "OSS means no sanity checks on feature creep, portability verification, documentation verification, regression testing, and all the other enterprise-project aspects of development that make it a useful technology."

OSS is a methodology, not a technology.

And to claim that only "enterprise projects" are "worthy" somehow is complete arrogance.

While I agree that having centralized control works, there are quite obviously many other ways of doing things, I think to call it the only route to success is foolish at best.

Re:Exactly - Java is not about the O/S

[hyfe]

I could name dozens of things I encountered in the past few weeks but I will name just a few: -primitive types and associated classes: When I want to store a variable of one the primitve types like int (the ones you use in every class) you have to wrap them into a class (Integer) which has no way to change the Value later.

You can't change the value of an Integer because it's an immutable class. This means that since it can't be changed, there is never any need for more than one object which each value. This means that regardless of how many times you do 'new Integer(5)' you'll only create one object with many pointers to it.This can be a very desirable property at times.

If you really can't pass the primitive around itself, create your own container class for the primitive. Its no big deal.

If I want to compare two Classes I have to use the equals-Method instead of a simple operator-overloading which would enable me to use == -

My java skills are starting to get rusty, but doesn't == check if it is the actual same object, while .equals checks if the contents are the same? Sounds pretty well defined and simple to me, and it isn't like .equals is the longest hard-to-read word ever..

When I retrieve an Object from a Container it is a java.lang.Object instead of the type I stored which totally negates the advantages of static typing

When choosing somewhere to store the whatever you're taking out you implicitly casting it anyways though. This was one of the things that surprised me too at the start, but I've yet to meet a situation where it really complicated the code, and I'm sure somebody smart could explain why they're doing it that way :)

Re:Exactly - Java is not about the O/S

[spen]

Operator overloading is a PITA for those of us who have ever had to debug code that has been obsfucated by overloading '==', '+', or any number of other operators so they don't behave the way you expect. In my opinion, saving the few keystrokes by typing 'foo == bar' instead of 'foo.equals(bar)' is not worth the pain inflicted when you don't know if/where '==' has been defined. It turns into a real pain when you're working on large projects with large inheritence trees. With Java it's pretty easy to track down the definition of '.equals'. In C++ with polymorphism it gets really weird figuring these things out. If you use operator overloading in C++, make sure all developers on the project adhere to a convention for semantics.

Re:Exactly - Java is not about the O/S

[TRACK-YOUR-POSITION]

You know, you can make non-cross platform code for Java. You can call Cocoa classes on Mac OS X, and I think there are some sort of gnome bindings in Java. You can use JNI to call native crap wherever you want. You can do lots of platform specific things in Java--which is good, because sometimes you need to do things only available on a given platform. When I'm running a GUI program, I don't care that this program was designed to work on all platforms--I want it to integrate well with the platform I'm on at the time.

So the whole Sun fear of "embrace and extend" is completely moronic. You can ALREADY extend Java in completely incompatible ways. After open sourcing, Sun's Java standard will still remain the "real" Java, and we know this will be the case because if it were not, then Java would have already lost control. So, if you're a developer, and you care if you're code works outside of Linux, then you'd better use Sun's (or possibly IBM's) Java implementation. And that's how it will be until the day no one cares about Sun Microsystems--a day that will come much sooner if Java continues to stay restricted and everyone's forced to move to Mono.

On the other hand, Java's pace would probably faster (and we wouldn't have had to wait forever for generics.) if it were open. Standards are just as important if not more to Mozilla as to Sun, but being open seems to work well for them.

It would certainly allow Java to be targetted to more obscure platforms. God help you if you want to write once, run anywhere other than Windows, Sun, Mac, or Linux/x86.

It would also mean that I wouldn't have to go to Sun's painful web site and hunt down the SDK and documentation past all the click-thru licenses. At the very LEAST it would be nice if sun let other people distribute their still closed java implementations. Of course, that would just be nice, it wouldn't be enough to head off platform irrelevance.

OSS means no sanity checks on feature creep, portability verification, documentation verification, regression testing, and all the other enterprise-project aspects of development that make it a useful technology. I've lost track of the number of times I've encountered platform-specific hacks in OSS code that weren't properly #ifdef-bracketed, or which just completely incompatible with other O/S implementations.

Yeah, that never happens in closed source software EVER. I actually agree with you that the language choices of OSS aren't all that grand (though lots of languages have embedded documentation, and the ones that don't can have it added with seperate tools)--but if you want everyone to start using Java instead, opening the source is the only way. No one wants to dedicate their time and energy for free to something a corporation has complete legal control over--unlike Mozilla/Apache/Linux, in which the corporations have merely de facto control. To be honest, Sun has made so much noise about their Open Source debate that I can't see how anyone could have any respect for them at this point if they don't announce a plan to open it reasonably soon.

Re:Exactly - Java is not about the O/S

[chewy]

following my recently adopted "software-as-an-organism" viewpoint, it seems like Java (or Sun specifically) allows open-source (the only part of the organism that really seem "alive") to grow atop it, providing the open source world with what they need (portable and managed!) and encourage extension to their system.

quite a good way to stay alive methinks...

brings us to the point. java -needs- open source to adopt it :) and has already succeeded in great ways.

rant generated by chewy

Re:Exactly - Java is not about the O/S

[cyclop]

Think you have missed the point. Ok, writing portable C or C++ needs some effort. But what about Python,PHP,Perl,Ruby and so on?

I code Python, and I found it to be amazingly portable and self-consistent. Exactly the way you want it -write on a machine to use on a completely different machine. I know the same holds for other interpreted languages. Python,PHP and Ruby are also much more coder-friendly than Java. Sure there are occasions in which Java is needed (probably because it is best supported and has more ready-to-go libraries), but I don't think it's the last word about portability. And Java crunches too much memory.

And what about the .NET thing? I don't know very much about it, but now that the OSS community can rely on Mono, it's getting hot, isn't it?

Finally, I never found a decent Java desktop application. Why?

Re:Exactly - Java is not about the O/S

[AArmadillo]

Uh, maybe you want to use your own type, like an Int class that holds a *public* int, instead of a java.lang.Integer wrapper class.

You should never be forced to break encapsulation in order to meet the requirements of the language. Of course, you should never be forced to make a class just so you can store a primitive type in an array, either.

Well yes, you have to call equals(), unlike in C++. Now why is this a problem? BTW I assume you want to compare two *objects*, not two "Classes"

Although equals isn't implmented too badly (even though it is easier and more intuitive to type == than object.equals(object)) compare the following two pieces of code for testing if one object in an array is less than another:

if(((Comparable) array.get(0)).compareTo((Comparable) array.get(1)) == -1)

if(array[0] < array[1])

The second is more intuitive, faster to code, less prone to syntax errors, and better in every way, shape, and form than the first.

Re:Exactly - Java is not about the O/S

[SnapShot]

FYI, your shouldn't assume -1/+1 from a compareTo. The contract is that the result will be less than or greater than 0 for not equals.

Re:Exactly - Java is not about the O/S

[sporty]

-primitive types and associated classes:
When I want to store a variable of one the primitve types like int (the ones you use in every class) you have to wrap them into a class (Integer) which has no way to change the Value later. So everytime I want to e.g. increment a counter stored this way, I have to convert it back to int, increment it und create a new Integer-Object to store the incremented value back into my container-class.

You probably should be using privatives all over the place. Use the object wrappers when you want storage. The wrapper objects are immutable for a reason. It sounsd like you are using them wrong.

-If I want to compare two Classes I have to use the equals-Method instead of a simple operator-overloading which would enable me to use ==

Operator overloading was left out for a reason.

-When I retrieve an Object from a Container it is a java.lang.Object instead of the type I stored which totally negates the advantages of static typing

Wrong. It's a superclass of object. Just cast it back. The reason you dont' get back the class you ask for is because the containers allow mixed storage at the current moment.

-Attributes of a Class are not totally protected against access from the outside (I have to work with old code that makes heavy use of this)

Define protected. You should be making them private. Yes, you can use reflection to unprotect them, but it's 1. dumb to do so, since it negates design. 2. it takes a lot of work.

When I started the programming project for the University I mentioned above I had to install Borland Together (for UML which we had to use). I tried to install it but the InstallAnywhere insisted on using its 1.3.1 dynamically compiled JRE which did not run on my glibc 2.3 system. I had to manually unpack the installation package, use another JRE 1.3.1 to install (the installer insisted on the old version, i had installed 1.4.2 at the time). When I tried to use the JRE 1.4.2 with it later (by editing the start-shell-script) the exporting to images of the diagrams stopped working.

So you are blaming Sun/Java for Borldand's issue? Let's blame intel and amd for windows issues. Mind you, other languags have the same problem. Perl, pthon, php. If the langauage interperter has a bug or issue for your platform, then you won't get anywhere. And mucking around with the internals which you clearly didn't fully understand, you break stuff. It's true of any system. Linux, Apache, Perl..

And for the record, java typically is very portable. You can typically unzip it to a dir, in the case of unixes, and go. It's only when you go into things like JNI where incompatability arises.

Re:Exactly - Java is not about the O/S

[gbjbaanb]

no, the poster said that c++ operator== will compare pointers. That's all the reference to pointers required.

operator== defined on a class compares objects. The default operator== will compare object addresses, primitives, etc. It cannot compare object contents as it doesn't know what's inside the object. C++ gves you the power to declare that object-content comparison and from them on can use it transparently.

Incidentally, the compare-by-reference in Java, compares pointers, you just don't get to see the memory.

Re:Exactly - Java is not about the O/S

[mark-t]

That is exactly why Java avoids it.

But I do not think operator overloading abuse would be as common in Java as it was in C++ even if Java supported it. I suspect that a lot of the reason why people use operators outside of their original context is because the C++ leader, Bjarne Stroustrup, did exactly that himself when he created the iostreams library, and used the > as I/O operators, a _completely_ different paradigm from their original purpose, which was to shift values either to the left or to the right. In my opinion, he should have simply conceded that I/O wasn't going to be possible to do with existing operators without violating semantic compatibility.

With Java, that wouldn't be happening, so people wouldn't have a cruddy example to follow. If Java supported operator overloading, I also suspect that a certain degree of darwinism would play a factor in this, and people who tried to use operator overloading in stupid ways would find themselves quickly ostracized from the common Java programming community.

BTW, it's worth noting that Java _does already have the '+' operator overloaded for their String class.

Re:Exactly - Java is not about the O/S

[jeremyp]

Java does not have operator overloading, but it does have overloading in general. i.e. you can define multiple implementations of the equals function depending on argument types if you like. So we're really arguing about notation.

Although I miss it in Java, I do have one issue with operator overloading:

cheeseDoodle == thingamajig

and

thingamajig == cheeseDoodle

conceptually should be equivalent. If you've overloaded the == operator on cheeseDoodle but not thingamajig, this can clearly not be the case. The equivalent in Java

cheeseDoodle.equals (thingamajig)

whilst theoretically having the same problem does have an asymmetry that might get the programmer thinking about it.

Re:Exactly - Java is not about the O/S

[dasmegabyte]

Operator overloading is commonly abused and it is always obfuscating to people who don't implicitly know your classes. It may be easier for you to type == to compare the value equality of two disparate methods, but in reality you're changing the context of the language just so you don't have to type as much. Coming in to the codebase from the outside, I have no idea that you overloaded the = method unless I go in and check the source code -- which besides being a waste of time partially defeats the purpose of using objects.

Considering that in modern code completion IDEs, == and .equals take about the same effort to type, I love Java's way of enforcing sparate operations for testing value equality and reference equality. It takes time to get used to using .equals(), .compare() and .append() to replace ==, > and +, but it's worth it.

Incidentally, I recently switched from Java to C# and started overloading operators again. I wish I hadn't. We have three methods in our collection structure that reference objects by value. All of the ones I wrote implement an indexer which selects the members of the collection by their foreign integer ID (the only useful value for referring to a specific object). All of the ones written by my coworker, who doesn't seem to understand the concept of reading comments, are indexed by position in the structure (completely useless as the resort themselves on the fly). He never used the indexer, instead relying on an unoptimized FindObject method that performed an iterative search. Therefore, his code was always slow...and every time I would reference one of his objects, the data would be wrong or null.

I could place the blame on him not using our agreed upon syntax properly, but really it's on the confusion over the overloaded [] operator. If we'd just settled on FindByPosition and FindByReferenceID, we'd never have had a problem.

Re:Exactly - Java is not about the O/S

[gabebear]

I find operator overloading a nightmere and I'm glad it's not in Java.

woo hoo! I can write "if (Object1==Object2) Object1++;" but I have to go back and look at the class that is hopefully commented to tell what == and ++ do for the objects. Having functions like .equalTo() is a LOT clearer and the incrementer operator is rarely usefull in a class.

just my 2 cents

Re:Exactly - Java is not about the O/S

[dasmegabyte]

Oh, and I just realized what you are doing is kind of wierd. You are testing for two separate concepts and claiming that you can do that with ==. You can. But this is major fucking sloppy and no faster than doing it this (arguably) better way, which doesn't confuse the reader as to what the == is actually testing for (it's obviously not reference...which is what == SHOULD be testing).

In this example, you would create in your SnackFood interface a pair of virtual methods: isQuantityEqual and isIndexEqual. Both methods would be overloaded, and could take as a parameter either a SnackFood object or an integer.

Thus, testing snack foods, you'd use cheeseDoodle.isQuantityEqual(thingamajig) or cheeseDoodble.isIndexEqual(potatoChip). Very simple. Very legibile. And the poor == operator doesn't find itself performing completely different tasks depending on what's on either side of it.

Re:Exactly - Java is not about the O/S

[cag_ii]

OSS means no sanity checks on feature creep, portability verification, documentation verification, regression testing, and all the other enterprise-project aspects of development that make it a useful technology.

I think this is more project dependant. Any well done project, OSS or not, should have an implementation of these features. If a certain project does not, it's not OSS thats to blame. I think the Apache projects are a good example of how OSS projects should be done, and set an attainable goal to be aimed for for new OSS developers.

Re:Exactly - Java is not about the O/S

[TheLastUser]

If your main concern is the number of buttons that you have to push to produce the source code, and you are not concerned with clarity, then I suggest the following:

if (c.e(t))...

Re:Exactly - Java is not about the O/S

[MassacrE]

operator overloading is statically determined, so you can only support both methods with overloaded equals if the compiler knows that cheeseDoodle is a CheeseDoodle at compile-time. Otherwise, you have to make equals(Object) look at the type of the argument and determine which subtype equals to call.

Re:Exactly - Java is not about the O/S

[ansible]

Regarding the incompatible versison ... you whine about 1.3x versus 1.3y .... we are at 1.5 beta now, that one fixes all your complains about int versus Integer and Container classes.

And how long has it taken to finally fix these issues? Years and years and years. Sheesh.

Oh, and unless you're like stupid or something, you're not going to use a beta for any kind of serious SW development. You've got to test it a while, after the feature freeze, to see if you can move to it. And if all the platforms you want to run it on support it, etc.

I've used Java a bit, and while it isn't bad for certain types of SW development, I haven't been very impressed with Sun's stewardship so far. I'd like to see what the community can do.

Re:Exactly - Java is not about the O/S

[Taurine]

You would greatly benefit from reading "Effective Java" by Joshua Bloch. Its an excellent book that enabled me to take advantage of a number of things that I had previously found greatly annoying.

Most of your complaints merely illustrate your level of understanding of the language. For example your frustration with the immutable nature of the wrapper classes (Integer etc) only shows that you don't understand the advantages of immutable objects. If you did, you would see that the advantages greatly outweigh the frustrations. These are the kind of things you can learn from "Effective Java".

Re:Exactly - Java is not about the O/S

[SillyNickName4me]

Complete and utter rubbish.

Maybe your statement would be believable when you could point at any relevant projects that got severely fragmented....

For now, companies like this one can tell you a lot about the cross platform availability of Java.

Matter of fact is that unless SUN opens up their license regarding distribution of binaries and allows actually using ports done by others then SUN, JAVA will become irrelevant and/or fractured.

That it is available on YOUR platform of choice doesn't make it cross platform.

Re:Exactly - Java is not about the O/S

[iwadasn]

just overloadd the .Equals(object) method to take any type of object you reasonably expect it to be compared to. == is kept around because you often want a quicker means, like this...

public boolean Equals(object o)
{
if(this == o)
{ return true;} .....
}

This is quick in one of the common cases. Helps with string interning and such as well. I've seen == operators overloaded so they throw null pointer exceptions when compared with null. This puts you in the damned if you do, damned if you don't situation.

Operator overloading is one of those good ideas that is only useful in the hands of the experienced and competent, by whome it's used rarely. It is however often used by the foolish and incompetent, as "It's really cool!!" and that's where you get into trouble.

I think on the whole it's better that it's been left out. It causes nothing but problems in C#, from my experience.

Re:Exactly - Java is not about the O/S

[msobkow]

No, that is my honest opinion of the code I have seen. Even for OSS projects, vendors have their existing documentation standards which their developers are used to following. They document their code by habit, and because it is required for a release.

The vast majority of OSS code has no such checks or requirements on the release process, and it shows. Without proper documentation, people cannot use the library properly.

For example, perhaps you could explain why the various config attribute strings available for Xerces (both Java and C/C++ versions) are not documented anywhere, forcing one to go through the code to find out what the options are. Yet that is what I consider a well documented OSS project.

Developers detest documentation. Fact. Unavoidable, plain, simple fact. After 20 years in the industry, I've never worked with anyone (myself included) who would do proper documentation unless it was mandated and monitored to make sure it was done.

Within 5 years in the industry, I'd learned the lesson that current documentation is critical to picking up and using or maintaining an application. No one except a home hacker has the time to read through code to figure out what an API is supposed to do, or what it's options mean.

Nor have I ever met anyone who had spent more than 10 years programming who hadn't realized that themselves. It's only the new programmers and those who have never had to maintain a system they'd never seen before who grasp the importance of documentation.

Eventually you will learn, but in the meantime, you're just totally out to lunch thinking it has to do with commercial backing. "Commercial" only comes into it in that they mandate documentation standards so they'll be able to use the software they've paid to help develop.

If it's "wrong" for investors to expect to be able to use the software they pay to help develop and maintain, OSS is a dead end. No one in their right mind gives away money to a bunch of coders just to create undocumented code.

There are exceptions -- I did paint an intentionally wide swath of projects as being problematic. Several GNU modules are well-documented, for example. But as you couldn't identify the obvious examples of good documentation, you've just shown how little you actully work with the code itself. Your little tantrum about commercial support is just red-herring flamebait, without the knowledge to back it up.

Re:Exactly - Java is not about the O/S

[JamieF]

I haven't seen anybody mention this so I thought I ought to:

In Java, == and Object.equals(Object) mean different things. == compares two object references and evaluates to true if they are the same. Object.equals(Object) compares two objects and evaluates to true if their value is the same. == will tell you about identity, while Object.equals(Object) will tell you about value equivalence. Value equivalence is something that the class author has discretion over, so it's necessarily something you'd want to override. reference equality doesn't change, so you don't need to.

If you were to (somehow) overload == so that it did a value-based comparison of objects, that would obscure the ability to determine if two references pointed to the same object. This would a Very Bad Situation.

I'm not arguing for or against operator overloading in general, I'm just pointing out that == and Object.equals(Object) mean different things in Java, and those are both necessary things.

Re:Exactly - Java is not about the O/S

[AusG4]

The commercial players are merely standing on the shoulders of the community, picking and choosing what they like and more often than not making a mess of it.

Now, now. Technically, the commercial players were the ones to develop most of the tools that the "community" is now duplicating in an OSS model.

While there are countless examples of innovation in the OSS world, a lot of the projects are just OSS clones of already available and vastly more mature commercial products. While I think this is a good thing, just who is standing on what shoulders here?

Although I agree with the sentiment that some of the commercial players are only paying lip-service to the concept of "open source", I find open source zealots who don't understand the enormous imporantance of commerical software companies equally annoying.

Re:Exactly - Java is not about the O/S

[mcc]

So the whole Sun fear of "embrace and extend" is completely moronic. You can ALREADY extend Java in completely incompatible ways.

I think from Sun's perspective this is not a problem because JNI, or things like Apple's cocoa bridge, are fairly insular. You don't *have* to adopt software with a JNI component, and if you do this you pretty much agree that you're being hardware tied to some extent.

I think Sun's worry about "incompatibilities" have mostly come from worries over silent, endemic incompatibilities. Things like that early Microsoft java VM where the API implementation randomly switched the call order for H and V values. That's a much more insidious problem because rather than hardware tying it introduces hardware incompatibility. If someone tries to run a Java program with a JNI component on the wrong platform, they get a "can't run" error and they know to contact their vendor. If someone tries to run a java program on a platform with a VM incompatibility, and it sort of works... well what do you do there? First off that's far more embarrassing to the Java platform, because instead of "your program was hardware-tied", it's "your program didn't work right".

Second off it's far harder to fix; with an incompatibility issue with JNI or some other method of "escaping" the Java world, the incompatibility issue is modular and quarantined at least to some extent. The fix there would be to switch out the native module with a compatible one, which may not be easy but is at least doable. An incompatibility where different VMs may behave differently with respect to a single piece of java code though... how do you deal with that? That's not something you can fix by swapping out the incompatible portion, it infects the entire problem. THIS is what Sun is worried about-- limiting the areas where you break WORA to quarantined modular components, not enforcing WORA under all circumstances-- and it's something that has *has been a problem with Java in the past*, with some of Microsoft's "extentions" to Java.

Of course there are ways around this, and I'm not saying Sun is being totally reasonable, but this is basically what Sun's problem here is I think. Note that they're being very tight-fisted about this compatibility thing not just at the source level, but also in terms of who's allowed to be certified as adopting to the Java standard. From what I have heard it is very hard even to get the Java certification suites if you are trying to create a compatible implementation of Java, because they're trying to make sure all Java implementors conform to the standard.

Re:Exactly - Java is not about the O/S

[angel'o'sphere]

that:

Oh, and unless you're like stupid or something, you're not going to use a beta for any kind of serious SW development. You've got to test it a while, after the feature freeze, to see if you can move to it. And if all the platforms you want to run it on support it, etc.

Depends heavyly on your timeframe and on the features that ebta offers.

JDK 1.5 is beta since at least half a year. IDEs with support for part of or all of the features of JDK 1.5 (e.g. CodeGuide from Omnicore.com) are around since at least 15 monthes.

The application I work on will need at elast one more year coding .... and if I did not have used JDK 1.5 featues t would be likely iver 2 years of coding. I guess JDK 1.5 will be around 1.5.3 and JDK 1.6 will be beta when I'm finished with my app.

DEFINITLY: I use a beta JDK to speed up my development. 1.5 compilers can generate byte code for 1.4 VMs ... so even in case I run into trouble I can write libraries or sub modules in 1.5 and use in the trouble area 1.4.

Bottom line: as long as you are not working with life critical stuff, a beta may save you a hell of a time.

angel'o'sphere

Re:Exactly - Java is not about the O/S

[Dr. Evil]

I agree with you wholeheartedly, although:

Operator overloading is commonly abused and it is always obfuscating to people who don't implicitly know your classes...

It can do the opposite too... on a team, you can standardize on "FindByPosition", but in the rest of the world, it could be anything from "getHandleByIndex()" to "find()". It's kinda-neat to be able to just go "hey, let's see if he overloaded the operator[]"

...but as everyone has been pointing out, Java probably did learn a good lesson from C++. I love operator overloading, but I don't fault Java for making their decision not to use it.

Re:only on embeded

[furball]

Do your research. Gosling is a crreator of Oak. It's true that Sun bought out the company that built Oak but Gosling was the visionary behind the entire concept.

Java on Linux for All

[Red_Winestain]

I'm involved with a commercial, web-delivered application, and we use Java served from Debian GNU/Linux boxes. Java was picked because our market is education, we need to support Macs and Unix as well as Windows.

The key, though, is that we've found we get the best results (e.g., as close to running universally as possible) by compiling on Linux (as opposed to on a Wintel box or a Mac box). Folks using anything from Mac OS 8.1 and Win95 to the latest thing all have access.

Re:Java on Linux for All

[JamieF]

>we've found we get the best results (e.g., as close to running universally as possible) by compiling on Linux

So when you *compile* your Java app on Windows or Mac OS, the resulting .class files are less compatible with your target web clients than when you compile it on Linux?

I think you need to rephrase that.

Or, perhaps you can explain why the .class files that come out of the compiler on Windows are different from the ones that come out of the compiler on Linux, and further that this is why your web app is more compatible with client OS's and browsers.

Maybe you're using an unusual compiler? I dunno. I've never heard of anything like this.

Re:Java on Linux for All

[Red_Winestain]

we've found we get the best results (e.g., as close to running universally as possible) by compiling on Linux

So when you *compile* your Java app on Windows or Mac OS, the resulting .class files are less compatible with your target web clients than when you compile it on Linux?

I think you need to rephrase that.

No, I don't need to rephrase anything. What we want is to have the class files run universally regardless of the customer's OS, browser, and JVM. We've found that a class file compiled on my Debian box using Blackdown's port of Java works (i.e., runs) whereas class files compiled with other compilers sometimes don't work (i.e., does not run on some combinations of OS/browser/JVM).

Part of this (maybe almost all of this) is that many cash-starved educational sites (our market) still use Win95/Win98 with Microsoft's JVM, or they still use Netscape 4.* with Netscape's JVM, etc.

Disclaimer: I obviously haven't tried all possible combinations of compilers/OS. Blackdown's Java on Debian works for me.

The scope of Java

[Peaker]

It seems that the usefulness of Java is limited to web applets/cellphone-apps and other specific things.

Judging from its popularity, it seems people are applying Java elsewhere. Why?

Java does not excel in performance, expressiveness, simplicity or power. It does not have generators, closures, dynamic typing and powerful dynamic features.

Why prefer Java over Python in the general case? If your answer is performance, why not choose Pyrex or C for the performance-critical parts, for a much better/faster result?

Re:The scope of Java

[Thunderbear]

From my experience, you can use Java to build enourmeous applications, and you have the tools (eclipse for one) to do so.

Those who say "Why not use Perl/Python/Bash/Whatever instead of Java" have clearly not tried writing a large application with them.

Re:The scope of Java

[Taladar]

From my experience, you can use Java to build enourmeous applications

It is exactly this type of application that should not be build. If you can not partition your big project in several small parts you should reconsider your design.

Re:The scope of Java

[nicolas.e]

partition your big project in several small parts

That's exactly what oop is for.

Re:The scope of Java

[the eric conspiracy]

Judging from its popularity, it seems people are applying Java elsewhere. Why?

Massive libraries, super development tools, tremedous skillbase availability, vast 3rd party support, large literature on best practices etc. etc. etc..

It does not have generators, closures, dynamic typing and powerful dynamic features.

Language features of marginal value (in some cases like dynamic typing the features can even be harmful to software reliability, making testing more complex and increasing the liklihood of runtime errors).


Why prefer Java over Python in the general case?

Vastly superior toolchain starting with design and ending with installation and deployment. End of story.

Re:The scope of Java

[Peaker]

Massive libraries, super development tools, tremedous skillbase availability, vast 3rd party support, large literature on best practices etc. etc. etc..

What libraries does Java have that are inaccessible to Python (Especially with Jython being avaialable)?
The development tools available for Python (xemacs, komodo, and various other IDE's) are all considered great. I have not personally used them and those of Java, have you? Can you write a few advantages of these tools during development?

The skillbase is surely a business factor when choosing Java. But when most create their own project, they can choose the language best fit technically - and that is not Java.

3rd party support and literature are not exactly lacking in Python and other alternatives either so that is a weak point as well.

Language features of marginal value (in some cases like dynamic typing the features can even be harmful to software reliability, making testing more complex and increasing the liklihood of runtime errors).

That is a common myth. Trusting the type-safety given to you by the compiler is not enough. You need to have run the code at least once to verify it is valid, and for that you must write unit-tests. If the code is not type-safe, then running it once in a dynamic OR static language will find the fault.

To say that generators, closures and other features not found in Java have marginal value is a sign of ignorance. Can you please describe those features and how they are typically used?

To underestimate the dynamic power of Python is also a sign of ignorance. Can you implement PyInvoke in Java? I challenge you to apply an RPC so easy to use as that.

Vastly superior toolchain starting with design and ending with installation and deployment. End of story.

Please describe why Java is superior, instead of uttering a chain of buzzwords.

Re:The scope of Java

[Peaker]

You may think that Java is only used in applets/cell phones, but that is not even its primary ussage
I figured so, I was wondering why.

1) Scripting languages such as Python and Perl run at (and this is a very rough generalization, of course) 10% the speed of C++. Java runs at 80-90% the speed of C++. Unlike scripting languages, Java is compiled to very efficient native code as your program runs (this is part of the reason for slow Java startup time, the bytecode->native compiler is running at that point).

Have you tried psyco? A JIT compiler for Python. In some cases it makes Python code run faster than the equivalent straightforward C code.
In others, Python code still runs with very comparable speeds to C.

2) While you CAN write code more quickly in scripting languages, scripting languages don't scale well to large projects (by this I mean that development time slows down, not runtime performance). Right around the time when you hit ~1000 source files, you start to realize the value of static type safety.

Python's expressiveness is so great, that you typically get 10-to-1 reduction or more in code size between C++ and Python. The powerful abstractions in Python make this non-linear in Python's favor. I do not have data about the relation between Java and Python, but it is likely similar, as C++ and Java take around the same amounts of code to perform similar tasks, given the existence of libraries.
Thus a "large Python project" functionality-wise is quite a small one relatively to the equivalent Java one. I have written a lot of Python code, and scaling up is actually very easy in Python, as it is in every sane language in a sane environment of good developers.

3) Not having to do manual memory management really does save you a lot of development time over C++. This may not be apparent to you in a small 1-2 person project, but just wait until you're working in a 10-person project and the dumbass down the hall accidentally deletes the object you still have a reference to (or forgets to delete and then you have a memory leak).

Indeed, but writing 100% of a program in a low-level language like C++ is a thing of the past (and of the ignorant). You should typically write 10% (or less) of the code in a low-level language, because that code executes 90% of the time. In these small pieces of library code, memory management is not typically a big deal.

4) The standard API is very handy. Java comes with something like 10,000 classes built in. You're clearly not going to use these classes for the core of your project, but they're very useful for all the side things you have to do. Need to parse XML? Built in. Need to send an entire object graph over a socket? Built in. Need to draw a curve with anti-aliasing? Built in. Need to have 2 threads put stuff into a queue while a third takes stuff out? Built in. Need to load a JPEG or talk to a database through SQL? Built in. It goes on and on and on.

Funnily, all of the things you mentioned (except the anti-alised curve, not sure about that one) are also built-in in Python. So again, I can't see why that would be a factor.
Especially moot seems your point that for "side things" Java libs are great. These little "scripts" and "side things" are the classic example where Python is so much better than Java. Show me the code of any such "side thing" in Java, and I shall show you the much-simplified and more-powerful Python equivalent.

5) The tools are incredible. I was an emacs guy for ~10 years but I was willing to give up my keybinding memory because the IDEs on the Java side are so damned amazing. Check out IDEA (or Eclipse if you're broke). It grays out variables that you're not using. It lets you highlight a block of code and hit a key and it makes a method out of the code, replacing the previous block with a method call (and in the latest beta, it detects duplicates of the code block and also replaces those with the method call). Accident

Re:The scope of Java

[Peaker]

Python has always scaled up well for me so far.

I admit to have only done medium-sized projects in Python, but in actuality, the vast majority of projects are of that size.

I do not anticipate any difficulties in scaling up Python (or any other sane language) programs, as they can always be broken to small interacting, largely-independent parts - which can be verified and tested separately.

If anything, Python's powerful abstractions make this easier as applying design patterns becomes near-trivial without the type-hassle.

Re:The scope of Java

[the eric conspiracy]

(xemacs, komodo, and various other IDE's) are all considered great.

Not by me and most other people. Emacs is not a real development environment. Komodo is built on Mozilla for crying out loud.

What libraries does Java have that are inaccessible to Python (Especially with Jython being avaialable)?

According to Jython.org jython requires JVM 1.1 or 1.2. This means Jython is seriously trailing modern JVMs and the libraries they support.

Can you implement PyInvoke in Java? I challenge you to apply an RPC so easy to use as that.

PyInvoke is a trivial application in version 0.1 distributed on SourceForge. Go implement EBay (1 billion transactions/day) on Python and I'll be impressed.

But when most create their own project, they can choose the language best fit technically - and that is not Java.

So Python is used only in non-business environments by one-man teams??

Trusting the type-safety given to you by the compiler is not enough.

Sun is adding parametric types because 10 years of real-world use has shown that the cases where the compiler cannot check type safety are a major contributor to runtime errors in production. The fact is that modern applications are so complex that it is IMPOSSIBLE to fully runtime test them in an economically feasible amount of time. This is the real world fact. Unit testing is only a small part of the testing needed. Dynamic typing adds major problems. Period.

Can you please describe those features and how they are typically used?

Yes. Can you?

Please describe why Java is superior, instead of uttering a chain of buzzwords.

Here are some specific toolchain items that Python is missing or only has low quality equivalents of: JBuilder, Eclipse, Rational Rose, TogetherJ, Web Start, Maven, Ant, JProbe, OptimizeIt, Hyades, WSAD, InstallAnywhere, Jakarta Project.


3rd party support and literature are not exactly lacking in Python

Amazon searches (books):
Java Programming: 1913 hits
Python Programming: 53 hits

Python is seriously lacking.

Re:The scope of Java

[Thunderbear]

I admit to not having written medium-sized projects in Python.

I am pretty sure that writing libraries (which is what small, largely-independent parts basically is) is not enough for a full application.

I have found that the various facilities in a modern IDE helps program development immensely, and that Java has some very high quality IDE's. I do not think that Python has as many - that alone makes Python less suited for large scale developemnt (which is where IDE's really help, since you cannot keep it all in your head).

Gradual shift into Java

[terrymaster69]

Not intended as troll - I work at a multinational financial institution. While most of our trading systems need incredible speed, and are done in C++, there is a firm-wide push to develop most of our server processes in Java. I am not a Java fanboy, but for many applications, Java is just easier to manage. To get code up and working quickly, Java is great. (if you're in the unfortunate position to have to write windows apps, C# is pretty quick as well) Lusers are lusers in any industry, but traders are generally more thickheaded than most, and they like to have software that works "pretty well" yesterday rather than perfect in 3 months.

Multiplatform App Development

[DaRat]

My company uses Java for multiplatform client-server application development (oil-gas industry vertical market) on Windows, Linux, and Solaris. Because of the need to include some native libraries (in C++ and, ye gods, Fortran (damn old scientific types)), the resulting code isn't a completely easy port, but it's hell of a lot easier than if we used straight C++ and GUI library of platform. I don't know why we didn't look at Qt, probably perceived licensing costs (I'm just an interaction designer).

Excuse me?

[warrax_666]

Maybe you are unfamiliar with the concept of the '/' character, but where I come from it is commonly used to denote alternatives. As in: most people use either C or C++.

Re:Excuse me?

[Dr. Eldon Tyrell TC]

Obviously the OP felt like something called "C/C++" is "the heavily used language" ... I did not read "languages". ;-)

Re:Excuse me?

[SavvyPlayer]

C++ can be thought of as a preprocessor for C, and with few exceptions retains C as a subset. One often (usually) finds C embedded within C++ programs, so C and C++ are for all practical purposes not alternatives -- they are symbionts. Of course none of this is to suggest that expertise in one implies expertise in the other. On the contrary, it is often the lack of C++ expertise that leads to the intermingling of C and C++ logic.

Re:Excuse me?

[iamacat]

Although it may be possible to write binary search using OOP, it's not a good idea. Each programming style has it's own optimum uses. For small code blocks, use flow control statements. For medium-sized code, use functions. For large modules, or ones heavily reused in your code, use classes. LISP tried to replace flow control with function calls, yet this didn't become the dominant programming model. People who swear by it end up using functions like apply that implement flow control statements like foreach.

So for me C/C++ is simular to Java/JavaBeans, C++ being a facility to organize C code on high level.

Re:Excuse me?

[theguywhosaid]

I understand what you mean BUT
would you agree that "C/C++" expresses a different relationship than say "Pascal/LISP"?

Re:Excuse me?

[ClosedSource]

"One often (usually) finds C embedded within C++ programs"

Not in my experience. Perhaps you mean that some people write portions of their applications in C++ in non-object-oriented style. Just because a scrap of C++ code could be compiled by C compiler, doesn't mean it's C code. Some lines of C++ code could be compiled for Java too.

Re:Excuse me?

[voodoo1man]

LISP tried to replace flow control with function calls, yet this didn't become the dominant programming model. People who swear by it end up using functions like apply that implement flow control statements like foreach.

It really should be noted that McCarthy first invented flow control statements in Lisp. The main difference between foreach and map (apply is used to apply a function to some arguments) is the scope of the variable to which each is bound, modularity concerns aside. Pretty much any Lisp aside from Scheme and derivatives has imperative, block-scoped iteration constructs as primitives.

Re:heavily used!?

[SirPrize]

X crashing is almost always a sign that the display driver is at fault, and not the application. True, the application might have tried to do something unusual, but it is then the task of the display driver to respond in a correct way, and ensure that X continues running. Applications, running on X with a proper driver, should not have any capability to crash X.

incredibly heavily, not most heavily

[AnEmbodiedMind]

He said "Java is 'incredibly heavily used' in the Linux community", not that it is the "most heavily used language".

A subtle but important difference.

Java on Linux

[DoctorPepper]

I use Java on all four of my main platforms: OS X, Linux, FreeBSD and Windows. I tend to use it for projects that are larger than I would feel comfortable doing in Perl. An added benefit is they are cross-platform, just like Perl.

I started using Java in 1997 on Windows, and it followed me when I expanded into different operating systems.

I really like C, and use it for some work-related and recreational programming, but when the "rubber meets the road" and I need to get something done within a short time frame, I turn to Perl and Java. Perl, mostly for data parsing jobs, and Java for the more "permanent" programs, especially for graphical network clients.

I've been using Java JRE's since 1.02, and they have really grown in power and speed over the years. I have no problems using Swing apps on my 800 MHz iMac or my 1.7 GHz Celeron Linux system. They even run very well on my 533 MHz Celeron running Windows 2000. While they may not have the raw speed of a native app written in C or C++ (especially graphical apps), the performance I get is more than adequate for the job being performed.

Re:Stop crying, let's start working!

[Daengbo]

Damn straight!

Gosling is right

[Anonymous Coward]

Gosling is right in that many people that don't want to work with Windows but want to make a living developing software embrace Java because it gives them the opportunity to work in their favourite environment - Linux. That is at least true for myself. I consider myself in the Linux fold, like Gosling says, and I develop Java. Having said that, there are very few client side java applications I use, but for server side stuff and web applications, Java is great.

It seems that every time Linux is discussed on Slashdot, everything revolves around KDE, Gnome, office suites or editors...

Java command line tools

[harmonica]

Java is not the best for command line programs mainly because VM initialization is expensive (in terms of time).

True, although this has improved over time.

I have written a number of command line utilities, and while the first call to one of them requires some patience (five to ten seconds), subsequent calls to any of them are just as quick as native programs because the JVM program and the runtime environment are in file system cache. I use those tools a lot and so I don't mind the first call being slow.

I should try some day to compile one of them using gcj. Haven't looked at that in a long time.

Re:Stop crying, let's start working!

[Svennig]

The reason for this is that Sun charges very high license fees for people wanting to develop JVMs. This is why there is no JVM for FreeBSD yet (or so I have been told).

Anything that carries the Java name must be java compliant. To be java compliant it must have passed the Java TCK published by Sun. The TCK is only available to licensees.

I don't believe that open sourcing Java is a good idea - if anyone could fork the codebase in any way they want versioning becomes an issue and you potentially loose cross JVM compatability, not just cross platform.

Java on Linux was a priority for Sun

[Decaff]

The volume of Java use on Linux can be judged by taking a look at the operating systems that Sun directly provides Java VMs for: Solaris, Windows and Linux. This has been going on for years, even before Sun's recent 'conversion' to Linux use. This was because of demand from Linux developers. It makes sense: Most server-side coding is now done in Java, and the fastest growing server operating system is Linux.

Re:Java on Linux was a priority for Sun

[jrumney]

I think the reason those three platforms have Sun JVMs is:

• Solaris - Sun is the OS vendor.
• Windows - Microsoft can't be trusted to produce a compatible JVM
• Linux - There is no single vendor, and the community will not produce a closed JVM.

For other OS's, the OS vendor produces the JVM (usually licensing Sun's source code as a starting point).

Re:Java on Linux was a priority for Sun

[aled]

The community has produced several open source JVM, what they haven't produced is a full java standard library.

Re:Java on Linux was a priority for Sun

[Decaff]

Linux - There is no single vendor, and the community will not produce a closed JVM.

The JVM is not closed - the source code is available. Just because it doesn't conform to some Linux distributors definition of 'open' does not mean Java is 'closed'.

Its not that the community won't produce a JVM - there are several out there: Kaffe, SableVM. Its just that they aren't compatible with the java test suites.

LDAP Browser

[Anonymous Coward]

I regularly use the LDAP Browser, which is written in Java, since it's the best free LDAP browser/editor I know of.

Java, because it has that many good working libs

[the_emmy]

I'm using Java when ever possible (i.e. when I have to choose the plattform). The two main reasons for this are:

• There are many very great libraries. E.g. OJB is a great database layer and SWT can create nice GUIs. All these Apache Common Tools are also very great and allow quick application development.
• Eclipse is the best IDE I ever saw. The great refactoring features and the hot code replace speed up development immensely.

Sometimes I'm not the own who chooses the plattform of a project. In the last years these projects were all .NET/C# projects. .NET/C# is not that bad, but some libs are bad documented (e.g. ASP.NET) or limited (ADO.NET -- one cursor open per connection ?!?!) so you have to build workarounds and own libraries. Also the development environment is not bad, but it has no refactoring, eats memory like hell and is dog slow.

I don't use Java

[Dr. Crash]

Very simply, I have no place appropriate for Java.

It doesn't fit on a microcontroller (like a PIC),
it doesn't have multiple inheritance,
it requires the right JVM,
it doesn't have a #include to keep parameterizations in one file,
it is actually write-once-debug-everywhere,
too many things in Java are only available as precompiled packages (open source in Java is a very rare thing)
and doing anything interesting in Java requires a native method anyway (hello, C!).

I use C instead. It's truly run-anywhere.

(for those that claim that "multiple inheritance is obsolete and I should be using "implements", remember that "implements" really means is "here is a routine with the same name, that we gaurantee is _different_ source code and will therefore NOT be bug-for-bug equivalent to the code you thought you were getting. Have a nice day and thank you for using Java".)

Re:I don't use Java

[cxvx]

too many things in Java are only available as precompiled packages (open source in Java is a very rare thing)

In your list of pretty run-of-the-mill statements, that must be the must ridiculous one.
Anyone who has done some serious development on Java know that you can develop entire apps using only open source software (except the core classes), as there are many libraries for all kinds of things (webservers, application server, (embedded) databases, or mappers, image libraries, ...) available.

As a few people here have mentioned already, Java is the 3rd most used language in Freshmeat projects.

Re:I don't use Java

[aled]

It doesn't fit on a microcontroller (like a PIC)
So what? who says Java is the right tool for that? on the other hand Java is used in a lot of embbeded projects.

it doesn't have multiple inheritance
Thank God for that.

it requires the right JVM
C programs when dinamically linked to runtime require the right version of runtime library. So?

it doesn't have a #include to keep parameterizations in one file
Include is a Bad Thing. Modern languages don't do that. It even makes compiling slower!

it is actually write-once-debug-everywhere
Not true for us. We develop web apps in windows and deploy in windows, as/400 and linux without touch a line. Some other desktop apps require native libs but we need to recompile only those, the Java part is the same.

too many things in Java are only available as precompiled packages
I don't know what are you talking except for some database drivers. IBM AS/400 drivers are open source. Anyway you can just any precompiled library because there is no need to recompile them. That's a Good Thing.

(open source in Java is a very rare thing)
Not true. In fact in every of our projects we use just core Java libs, open source libs and our own.

Re:I don't use Java

[Dr. Crash]

First off, half of what I do requires that the hardware be CHEAP. A dollar per CPU is too much if you're making something that retails for under twenty bucks.

Second, I (and various people I trust implicitly) -have- been through "write once, debug everywhere". Sure, you can say "wrong JVM, tough luck". - but what if the target platform doesn't HAVE that nice shiny (closed source) JVM your binary (commercial) package uses.

It doesn't even need to be _costly_- just closed source. For example, Frink (the programming language) is free to use, but closed source. It's also in Java. And I can't run it on my NEW Zaurus PDA, because it was compiled against an OLDER (?) Different (certainly) JVM. So, I'll probably end up re-implementing Frink in C. Or just not using it.

Or worse... two packages, both commercial, both closed source. Different JVMs. Been there. Done that. Cancelled the project. With C there _is_ a chance that it might work. With Java, good luck.

And - if you can't handle multiple inheritance, well, you aren't a Real Programmer. Or rather, you might be a fine coder, but you're no System Architect.

Consider the following Real Life Scenario: Rare bug manifests itself in a method. You fix it. But did you fix the other N bazillion places where that same method is implemented (mostly by cut and paste, because most programmers are lazy)? Heck, can you even _find_ all those places?

You're just fallen into a version-skew hell dimension and there's no easy way back.

With MI, you fix the bug ONCE, in ONE place, and the problem is fixed.

And yes, I was dealing with this 17 days ago, according to the changelog. This isn't a theoretical scenario, I ended up hand-reviewing about three thousand lines of code. Not fun.

Re:I don't use Java

[aled]

And I can't run it on my NEW Zaurus PDA, because it was compiled against an OLDER (?) Different (certainly) JVM.
I googled a little and it seems that you are trying to use a full J2SE (standard edition) desktop app in a PersonalJava or J2ME (micro edition) JVM which are meant for differents apps. Just because has a Java somewhere doesn't mean you'll get to run any Java app. There are different specs for J2ME and J2SE, it's has nothing to do with the version, the same way Oracle isn't expected to run in your PDA. The app must be developed to the platform. In Java that means J2SE for PC and servers and J2ME for phones/pdas.

And - if you can't handle multiple inheritance, well, you aren't a Real Programmer.
Real Programmers don't use languages, they change the bits in memory by hand. Everyone knows that.

Consider the following Real Life Scenario: Rare bug manifests itself in a method. You fix it. But did you fix the other N bazillion places where that same method is implemented (mostly by cut and paste, because most programmers are lazy)? Heck, can you even _find_ all those places?
Well, one can program bad in ANY language. I have found that C programmers tend more to copy and paste because of not using OOP. Most C++ programmers I found understand perhaps 50% of the language, no one I have found (in person) that uses MI. Java programmers tend to reuse some more because they start by learning inheritance. Your milleage may vary.

Macromedia's Coldfusion

[Tom Walder]

My company uses macromedia's coldfusion extensively, the latest version is a J2EE application. The linux version has proved to be incredibly reliable. Other CF users might like to comment on their experience ??, but I think this a very good example of how good the linux/java combination can be

But it's such a bitch to install...

[Karora]

We do a lot of Open Source work, but by far the bulk of it (especially for enterprise level applications) is done with Perl.

Of course if we were "bigger" or writing "bigger" applications, Java starts to see some advantages, but the biggest hurdle is to actually get a reliably installable version.

Sure, we can download it from IBM, or from Sun, or from Blackdown, but they all have differences of opinion, differences of quality and differences of ideals.

We use Debian for all of our systems, and every other damn software package we run is built and works for Debian, and plays nicely with everything else. But not Java. There's no standard place that it gets installed - to the extent that some packages will successfully identify that you have it, and others won't. It isn't in synch with the libc or libgcc that's current at any point in time. Since I upgraded my laptop to Mozilla 1.7, Java no longer works: not that it was ever particularly reliable.

So while there might be some wonderful advantages to building applications with Java, the general flakiness of my experiences with applications written to use it, means that I can't develop for it, because I can't inflict that flakiness onto my clients.

Partly, of course, this flaw is because Debian's approach to licensing means that something with the shackles around it that all JVM's will have, will never be part of core Debian. In fact though, that's mostly the case for any distribution, even the commercial ones, because they are all depending on open-source licenses for all the rest of the environment, and to be in synch with those, you have to be part of everyone's standard install.

Commercial distros must have to put lots of effort into making their setup work with their chosen JVM, rather than sticking the horse in front of the cart and making their chosen JVM work within their environment.

I sure would like to see an DFSG free implementation of Java, and I don't understand why this entails Sun "losing control" of the standard, and why they are in such a panic about allowing that to happen.

Re:But it's such a bitch to install...

[cygnus]

I sure would like to see an DFSG free implementation of Java, and I don't understand why this entails Sun "losing control" of the standard, and why they are in such a panic about allowing that to happen.

i don't think Sun's at all worried about any implementation of Java... they're worried about losing control of the specification of Java, and having it get fragmented by Microsoft (and maybe others, who knows). they do have some cause for alarm... it's not like Microsoft ever went after Perl or Python like it did Java.

Re:But it's such a bitch to install...

[fusey_2004]

Personally, I feel its a case of using the best language for the job. For example, scripts are better with bash or Perl. Java's not even in the ballpark here, as there is a lot of UNIX-specific stuff that it can't do (well, without native methods anyway) -- things like chmod, signals, forking, etc. Java has its niche too -- servlets come to mind. I think its more or less lost the advantage it once had of web-based applets, if just because of the size of current Sun versions. The licensing of current Sun implementations of Java means that it can't be distributed with a GNU/Linux distribution. There is a DFSG implementation of Java -- see GNU Classpath which is licensed under the GPL with a licensing exception. This is coming on in leaps and bounds, and is now starting to run basic Swing applications. Eclipse is even starting to work, to a degree. There are plenty of Free JVMs to go with this, such as SableVM, Kaffe and gcj (how these merge with Classpath varies, however). Full links are on http://classpath.wildebeest.org/planet/ Debian testing and even stable has some of these. Currently, the existing Java packages in Debian are being moved towards main as they are tested with Free implementations (http://java.debian.net/index.php/MovingJavaToMain ) There is certainly room for plenty more contributions! Depending on Sun to release an implementation is a bad idea -- even if it happens, it will be on their own terms.

Re:But it's such a bitch to install...

[deanj]

I think this says more about the difficulty of getting apps in general running across distros than it does Java specifically.

We've had problems getting just plain old C++ apps working across the various different distros because of the differences between them.

Thanks for the point about Java on Debian though... we've done some preliminary work with our C++ OpenGL apps on there, which worked OK, after some tweaks.

If Java doesn't work well there like you say, I'll recommend we go to another distribution instead.

Re:But it's such a bitch to install...

[bcrowell]

Yep, same deal on FreeBSD. Every other piece of software I use works just fine within the FreeBSD ports/packages system, but because of the licensing issues, Java is a huge PITA to install, and the same for OOo. If you want to install binaries, you have to visit sun's web site, give them your hat size and mother's maiden name, click through a licensing agreement, download a gigantic binary tarball, and then rinse, lather, and repeat a few times because they won't let you complete the process in one step.

Installing Java or OOo from source is a disaster, too. Again, the licensing keeps you from doing it within the normal FreeBSD ports system, so you have all this time-consuming stuff to do by hand, and then the port may not actually compile. Last I heard on comp.bsd.freebsd.misc (a few days ago), the only people who said they'd gotten OOo to compile from source said that they had to edit some of the code.

Re:But it's such a bitch to install...

[KidSock]

"Installing Java" for Mozilla isn't a problem with Java it's a problem with the Java plugin for Mozilla which breaks because of Mozilla not Java. If you cannot install Java (the runtime) then I'd be concerned if you were given the task of installing a light bulb.

Re:Stop crying, let's start working!

[furball]

You mean this FreeBSD JVM?

The TCK is not available to licensees and there is not a cost to developing JVM's. Case in point, Kaffe is a clean room JVM implementation. They pay nothing to do development. They can't call it Java until they pass TCK but even they agree they lack key features of a fully implemented virtual machine.

Re:I'm usiging the original

[Decaff]

All other points are either a draw or worse than C++.

Try this:

1. Get your compiled C++ Linux excutable.
2. FTP or SCP that binary to a machine running a different operating system.
3. Type the command to start the executable.

Doesn't work? Then perhaps Java does have some advantages.

OK, let's stick to the same operating system. You upgrade to a 64-bit processor. Does your executable automatically run 64-bit with optimisation? No? Another advantage for Java.

Java and Linux a good long term solution.

[jellomizer]

Using Java and Linux is really a great long term solution that allows can keep you TCO down for a long period of time including migration to normally incompatible systems. For most companies they are afraid to change their platforms because all their custom applications will not work on the new platform or will have a lot of problems. That is where Linux and Java come in. Linux as an OS runs on many different platforms x86, PPC, Sparc, ARM and more. Java can run on many different OSs. So if they wanted to switch to a different hardware platform then all their software will still work or if they don't like linux any more then they can switch to an other OS without loosing their applications. That is the Beauty of Linux and Java it doesn't put you in a Box of what you need to run and who you will need to pay to keep you business going.

Re:Java and Linux a good long term solution.

[Taladar]

You will have to pay the company that wrote your Java-Apps to debug them on the new platform.

Re:Java and Linux a good long term solution.

[aled]

You mean you don't test your non-java apps when installing into a new platform?

Re:Java and Linux a good long term solution.

[jellomizer]

Compared to paying the company to rewrite it for a new platform. For every app wrote. Or pay to debug a couple apps that have a fiew glitches.

Re:OSS Mono to take over?

[dnaumov]

"Java is not open source. This means that no-one can ship java with a Linux distro - you have to agree to a multi-page EULA before you can use it."

Thats funny seeing as SUSE and Slackware DO ship SUNs JDK.

Java & Linux

[Z00L00K]

I'm a Linux user and am using Java for two reasons:

• Reasonable stable code (at least in the later versions).
• Binaries are portable between most platforms

There are some drawbacks with Java too:

• Brain-dead memory handling. - I as a programmer can't control or supervise the memory management
• Resource-hungry, especially when GUI:s are present.

In all, this means that when resource consumption is not an issue, Java is a good choice, but when I want something lean&mean I'm using C, or even script-programming.

Ah, yes, but

[warrax_666]

then you could take it to mean : The most heavily used language is either C or C++ (but not a combination of the two). Such is the curse of natural language. :)
I know this doesn't square with the original poster's second sentence, so I'll concede that you're probably right that TheCoop doesn't grasp that C and C++ are indeed quite different languages (syntax notwithstanding).

But just to get back on topic: It seems to me that Free/OSS server code is heavily slanted in favour of C and not C++ or Java. Actually, I can't think of a single Free/OSS server that's written in C++. And I can only think of one Free/OSS server written in Java, namely Freenet. Quite sad, really, since there are still lots and lots of buffer overflows and sprintf vulnerabilities being found every day.

Re:Ah, yes, but

[jsoderba]

The Firebird SQL server (based of Borland's Interbase) has been ported to C++. Actually, most C++ server software I know of tends to have a Windowsish background.

Re:Ah, yes, but

[gabebear]

It's because Microsoft's C++ classes are well laid out. I learned C++ after Java, and one of the things that bugs me most about C++ is that there is no master base class. All of MS's C++ classes have a master base class. You can actually use inheritance the same way you do in Java if you are using only MS's classes. Anyhoo, since I don't even own a Windows computer that does me no good, but having a good template library more than makes up for no base class.

If Sun put their JVM under a GPL licence that the Java app population would explode.

Re:Ah, yes, but

[E_elven]

Why the hell do you need a 'master base class'? If one is needed, one is provided. If not, adding one is just useless noise.

Re:Ah, yes, but

[gabebear]

Java has corrupted your mind

Yep! I'm a Java Nut.

Re:It is the nanobots making him say that...

[Decaff]

What would we lose if all Linux Java apps suddenly disappeared?

The ability to develop for one of the most widely used server systems (Linux) in the most widely used server-side development language (Java).

Java is the most heavily used in business

[Anonymous Coward]

You are probably right that C and C++ are more heavily used by Open Source developers.

If we look at the number of jobs being offered, however, it appears that Java is now the number one language used in business, having passed C and C++ sometime in the last two years.

For example, here are the current numbers of job listings at Dice.com:

8284 - Java

5714 - C

4993 - C++

7967 - C OR C++

Re:Java is the most heavily used in business

[Anonymous Coward]

Except you need to somehow combine the C and C/C++, and C++ and C/C++ to get a more accurate representation. No matter how you combine them, Java is not number one.

MOD PARENT UP

[ydnar]

Funny, insightful, whatever.

Corporate rock^H^H^H^HJava still sucks.

And if we're talking heavily used, let's talk about Bittorrent. Written in Python. Runs on whatever OS spins your daisies. Doesn't take a half hour to fire up the VM.

I dont understand...

[marinebane]

if Java is is so good why dont they program it in Java?

Re:I dont understand...

[cxvx]

if Java is is so good why dont they program it in Java?

I know you're trying to be funny, but they (they meaning IBM) have: It's called the Jikes RVM

From the link:

A distinguishing characteristic of Jikes RVM is that it is implemented in the Java programming language and is self-hosted i.e., its Java code runs on itself without requiring a second virtual machine. Most other virtual machines for the Java platform are written in native code (typically, C or C++). A Java implementation provides ease of portability, and a seamless integration of virtual machine and application resources such as objects, threads, and operating-system interfaces.

Re:I dont understand...

[marinebane]

yep i knew that, was just trying to be funny

Re:Stop crying, let's start working!

[Svennig]

Thats exactly my point. I can't write Java and have it guaranteed to compile and execute the same way on any of those JVM's that you point out. Hence they arent true JVM's.

Oh yes you can make a little hobby project that compiles java into native code but without the accreditation of passing the TCK and being certified as a true JVM, businesses and others wont use it!

There is an interesting piece on Anne Thomas Manes' weblog, which I shall copy below:

I was talking to Toufic Boubez yesterday, the CTO of Layer 7. Layer 7 provides a Web services policy and security management appliance, and they use a hardened Linux operating system. I asked him why he doesn't use BSD. And he said

Because there's no decent JVM for BSD!

If Java were truly open source, then this wouldn't be a problem. You could just take the source and compile your own JVM for BSD. But no. If you want to create a JVM for BSD, you have to be a licensee of Java (big bucks!). None of the current licensees of Java has an incentive to develop a JVM for BSD, hence no JVM

The key here is decent.

in my daily work...,

[bogaboga]

...as a dy trader, there is no way I could manage without Java enabled on my system. What I did though, to move the entire java directoty to a windows partition from where I mount the executable. This helps me a lot since, when ever a [new] distro is out, I do not have to re-install Java. I simply specify my old windows based path to apps like Konqeror and the rest, then life continues. All in all, Java is a blessing to me.

Re:I'm usiging the original

[arose]

The Free Software world tends to use Perl/Python/Ruby/TCL for this kind of compatibility. Mono also seems to be gaining ground rapidly. But there are also a lot of free Java software, sadly most of the apps I've tried don't run in GCJ.

Re:Stop crying, let's start working!

[arose]

If only more Free Software authors would test their software with GCJ...

Re:Stop crying, let's start working!

[furball]

That's factually incorrect. The FreeBSD group is a Sun licensee (not big bucks). They simply lack people to work on the beast. I'll give you a hint. If you actually looked at the FreeBSD page I linked to you'd realize they have a whopping *1* person working on it.

Java 1.3.1 is pretty solid on FreeBSD.

As for compiling Java, there's a language spec out there. I've taken code and compiled with IBM, Sun, and MS compilers and it went just peachy. All the code I wrote since '97 compiles clean on IBM, Sun, and MS compilers. And amazingly they all work the exact same way on the different platforms.

Bottom line: Licensing the JVM code doesn't cost you big bucks (see also, FreeBSD). Using different vendors doesn't require you to do anything fancy with Java source code or run time environments (see also, Apache Org.)

Corrected SourceForge link - language statistics

[Anonymous Coward]

Corrected link:

SourceForge Projects by Programming Language

From the page:

- C (13785 projects)

- C++ (13922 projects)

- Java (12588 projects)

That's very interesting. Even though I'm a Java supporter, I was surprised to see so many Open Source Java projects.

As a non-programmers...

[bushda]

...the only thing that I can think of that my wife and I use Java for is when we play Yahoo Pool against each other. I also used to use it for Limewire before I became too paranoid to use that anymore. Oh - maybe for OpenOffice.org too.

FWIW I've been using Linux as my desktop OS for 3 or 4 years, and my wife has been using it as her desktop OS for the past year. The idea of actually buying software is more and more foreign every day. ;)

Re:I'm usiging the original

[Taladar]

Now, try this:

-download your 500 kb Java app
-try to run it

Doesn't work? Then perhaps native code has some advantages.

Ok, let's say you have a preinstalled JRE. You upgrade your JRE and half the features in your Java App stop working. Your second Java-App needs the new version? Too bad.

I don't develop any Java software, but....

[EnglishTim]

I don't develop any Java software, but my current editor of choice is Jedit, a Java-based editor. I use it every working day on Linux.

Just about every programmer I know...

[Baldrson]

Almost every programmer I know ( and I know quite a few having been in the business for 30 years ) describes programming with Java as about as much fun as having bamboo shoots shoved under their fingernails. Some like C, some C++, some Objective-C, some Perl, some Python, even Jython and Javascript and assembly (for really tight embedded stuff) but when it comes to Java they are virtually unanimous about the fact that its unnecessarily verbose and even pedantic with boilerplate vs performance rendered to programmers, owners and users of programs written in the infernal language.

All of them do almost all their work in open source environments.

Re:Just about every programmer I know...

[aled]

Yeap, 30 years of use, you need to replace your programmers after 25 years, you know.

Re:Just about every programmer I know...

[Baldrson]

Ok, I'll let the guys in their early 20's who hate Java know you said that. Maybe they can find another line of work.

PS: Actually, I was chosen as a mentor by a high school and tell young programmers that programming is a profession where they'll have to either reinstitute clan-based living, including arranged marriages, so they can compete with India on a pure cost-of-reproduction basis, or wait for companies that utilize Indian talent heavily, like Sun, to die.

Re:I'm usiging the original

[cxvx]

Ok, let's say you have a preinstalled JRE. You upgrade your JRE and half the features in your Java App stop working. Your second Java-App needs the new version? Too bad.

Care to back this up with some facts? If Java has done anything, it is trying to stay backward compatible too long. Not a single method that has been deprecated has been removed. There are quite a few Java developers that would like to see the JDK cleaned up of those.

For example, even the entire Swing library hasn't been updated to use JDK 1.2, eg., it still uses Vectors instead of Lists, just for keeping the backward compatibility.

I do use Java

[harmonica]

it requires the right JVM

Most people use the latest JDK and that's it. No problem. A C program also requires the right compiler unless it's trivial or you want to descend into ifdef hell.

it doesn't have a #include to keep parameterizations in one file,

It has import.

it is actually write-once-debug-everywhere,

Actually, it's not. At least not everywhere. In my Java experience since 1996 I've yet to see that debug everywhere nightmare. And I've touched a lot of operating systems and Java software projects. Maybe I was lucky. But debug everywhere? Ridiculous. But it's a catchy phrase to spread around if you don't really use Java as you claim in your subject line.

too many things in Java are only available as precompiled packages (open source in Java is a very rare thing)
and doing anything interesting in Java requires a native method anyway (hello, C!).

Tough. If people don't want to provide source code, that's their decision. I've used binary C and C++ libraries all the time. As long as they're documented, that's okay. And yes, some things requires native calls in Java. But very few, really. If you catch yourself using JNI all the time you may have picked the wrong language for the project in the first place. Java isn't right for anything.

(for those that claim that "multiple inheritance is obsolete and I should be using "implements", remember that "implements" really means is "here is a routine with the same name, that we gaurantee is _different_ source code and will therefore NOT be bug-for-bug equivalent to the code you thought you were getting. Have a nice day and thank you for using Java".)

I claim that multiple inheritance is overestimated by some because a thing is rarely two or more other things. You get other problems with MI like the diamond of death.

Me personally...

[CFBMoo1]

I use the following java based apps at work constantly on my linux box:

* jEdit
* Squirrel
* Eclipse

At home I make good use of jEdit as people use notepad in the GUI. Commandline though I use vim/vi.

Stop whining about code forks, everybody

[blackhedd]

Java already is "forked," by Sun itself! There has never been a release that didn't break something in a prior release, with the result that shipping anything written in Java to a lot of heterogeneous users is a major hairball. You have to specify the exact Java build(s) that your code will run on, and it's up to your users (or YOU when they call you for support) to make sure that the six other back versions floating around on their machines aren't screwing you up. If you want to bundle a JRE with your code to make it idiotproof, Sun makes you take out a license.
An open-source Java might pick up forks along the way, but FOSS is market-driven in the sense that only really good ideas will get and keep a following. And the best ideas will be widely supported. Look at Apache and all the others. The vast majority of "forks" are for very special purposes and don't end up stranding all that many people when they die out.
On balance, open-source Java is the best of all worlds.

java offers good design and standards

[louzerr]

I've been through C++, Perl (still use perl quite a bit for quick scripts), and on the web PHP and ColdFusion (yuck!). But java offers so much more! First, it's object oriented - not "can be" but "is". Second, there is a TON of development in java, so there are libraries for just about anything you can think of. Third, when it comes to JSP/Servlets, it is not tied to a single vendor like ColdFusion (our previous internal web app platform at work), so we can use Tomcat today, and potentially move our apps to WebSphere in the future without completely rewriting them. Best of all, the apps I write can easily be developed, compiled and tested on my Windows workstation just as easily as on my linux machine.

Plus, consider the power of two java utilities - jUnit (http://www.junit.org/) and Ant (http://ant.apache.org/). With a single command on the command line / xterm, my cvs code downloads locally, my classes are built, unit tested, and then packaged into distributable forms! What did we do before java?!?

yeah, look at all the forks of perl/python, etc.

[Xtifr]

Portable, standardized language and interfaces are what gives Java it's power.

Yeah, because gods know that no other language has ever been portable or standardized.

Unless protected by a strong consortium [...] Java would rapidly fragment into several code forks

Just as has happened with those other highly portable, standardized, cross-platform languages like Tcl/Tk, Perl, Python, etc. (Oh wait, I forgot, there are no other portable, standardized, cross-platform languages, my mistake.) Yeah, clearly, every language that isn't under the rigid control of corporate-owned constortia is instantly subject to massive forking by the dangerous denizens of the dark side. Open-sourcing computer languages makes the baby jebus cry!

Java's embedded documentation [...]

Oh, yeah, too bad the perl coders couldn't come up with something like that years before java even existed! Come to think of it, I think the perl guys borrowed it from lisp! Oh well, it's clearly an advantage of Java and of no other language!

And the best part about using java? It's low-level C/C++-like syntax and data structures means that you get to write many times more lines of code than you would need to to code the equivalent in tcl or perl or python. Why is that good? More money for programmers to write and (especially) to maintain all that extra code!

Java, with the support costs of a low level language, the run-time overheads of a high-level one, and the benefits of neither, is clearly the best choice. Just try it, and you'll be sayin', "Wow! I gotta get me some o' dat!"

Whoops, sorry, was I waxing sarcastic again? :)

Oh yeah, and all three of those other languages I mentioned have all settled on a single cross-platform GUI toolkit to share (Tk). How many GUI toolkits are fighting for dominance in the java world these days? I stopped counting after three. Boy, that there's some good standardization!

Aaaanyway, I don't want to bash java too hard. I actually think it's a pretty decent language overall. I just get so tired of people who think it's God's Gift; people who usually don't have a clue what else is out there. Java's ok, but it ain't All That!

Re:I'm usiging the original

[cxvx]

You do realize that C++ code can be recompiled to take advantage of a 64 bit word size. What you're missing is that the JVM, in its quest for ultimate portability, defines a fixed 32-bit size for your common integer type. Meaning that java applications do not take advantage of 64 bit precision on 64 bit machines.

The philosophy of Java is, that if you need 64 bit precision, use a datatype that uses 64 bits. IMO, it is a great advantage of Java that the primitives are declared so precisely.
It sure beats the "how large is an int exactly" mess you get in c/c++.
How long did it takes most linux programs to become 64 bit clean? This was never a problem for Java apps.

Re:I'm usiging the original

[Decaff]

-download your 500 kb Java app
-try to run it

Doesn't work? Then perhaps native code has some advantages.

Why shouldn't it work? Why should size of the binary have any relevance?

You upgrade your JRE and half the features in your Java App stop working.

I you could give an example of where half the features (or indeed, any significant features) in
a java app stop working when a JRE is upgraded then I might consider this a useful comment. Of course this doesn't happen. I'm not saying that nothing ever changes in an JRE upgrade, but for virtually all apps, it makes no difference. Even huge systems like Eclipse run perfectly well on the 1.3, 1.4 and 1.5 versions of Java.

Ease of use sometimes requires minimizing features

[NeoBeans]

I agree with you in that the idea of Java was good, but the implementation of the language has absolutely no aspects of a beautiful/easy-to-use language.

I totally disagree that Java has absolutely no aspects of a beautiful/easy-to-use language. I think you're neglecting the fact that when Java burst on the scene in '95, it provided a simple means to write cross platform applications in a way C/C++ did not out of the box.

I worked on a satellite system for NASA written in C++ that was originally spec'd to work on five UNIX platforms. Keep in mind this is in the days before Linux became widely adopted... and this system was a major headache because:

• Because of the lack of POSIX compliance between the platforms, we were in #ifdef PLATFORM_NAME hell. Heck, even when we tried to performance tune the application, we wound up with gobs and gobs of #pragma directives and custom code to either work around bugs in a target platform, or just improve performance (for example, by aligning data structures to specific address boundaries).
• Byte endian issues had to be solved at a fine-grained level, requiring each developer to write their own serialization/de-serialization code. At least until we began using Rogue Wave's Tools.h++.
• Helping folks manage deployment of their applications meant learning how each separate platform managed dynamically linked libraries. In fact, I recall silly bugs caused by circular dependencies in APIs we used that often required juggling the order of libraries during linking.

This is not to slam C++ in its current incarnation, but to point out that when Java first arrived on the scene, the restrictions and smaller set of APIs made it easy to ramp up developers who could then build cross-platform applications much quicker.

As for your specificpoints, let me explain where I disagree:

-primitive types and associated classes: When I want to store a variable of one the primitve types like int (the ones you use in every class) you have to wrap them into a class (Integer) which has no way to change the Value later. So everytime I want to e.g. increment a counter stored this way, I have to convert it back to int, increment it und create a new Integer-Object to store the incremented value back into my container-class.

Primitive types are (IMHO) a bit of a hack in Java, but they behave much like primitive types in C++. Granted, lacking generics (pre-Java 1.5), Java cannot support arbitrary collections of primitives, but consider this: if you want to store and manage collections of primitive types, couldn't you write your own class to either "wrap" the primitive type? I'd also recommend wrapping the Collection you're using to simplify the mutators.

-If I want to compare two Classes I have to use the equals-Method instead of a simple operator-overloading which would enable me to use ==

I can't count how many times I ran into incompatibly defined flavors of operator overloading in "mediocre" C++ code where bugs in operator overloading introduced logic errors that were hard to find.

Inn the case of equals(Object) versus the == operator, consider this: in Java they have two completely different purposes. If you want to compare two object references to see if they refer to the same object, use ==. If you want to compare the contents of the objects they refer to, use equals(Object). Consider the ambiguity and potential for flaws when the operator's behavior could be changed to deviate from comparing references to Objects!

This is a case where I believe that removing a feature from a language makes it easier for developers to avoid dealing with obscure bugs while trying to get an application done.

-When I retrieve an Object from a Container it is a java.lang.Object instead of the type I stored which totally negates the advantages of static typing Solved in Java 1.5 with Gener

It's great if you're not an API implementor

[subStance]

Sun have made the API licensing of Java so developer-friendly that it makes the life of the API implementors hell.

For example - I've implemented a servlet container, but in order to get the test kit for it, I had to sign a contract guarding the contents of the license - I can't tell you how draconian the conditions are, because the conditions themselves are protected.

Sun have pulled off the PR dream scenario - screw over a minority that helps them (the implementors), gag them so tightly they tell you everything is alright, and everyone still sees Sun as the champion of the little guy.

The goals they seek (API compliance) could *easily* be achieved through more positive methods. If they want API compliance, why don't they just make the compatibility test kits so easy to get/use that anyone who downloads a non-compliant implementation of a sun api will hae the chance to know it before installation - kind of like how most GNU stuff uses "make test". It's certainly a lot better than forcing open-source implementors to sign conditions so harsh it could personally bankrupt them if Sun decided they wanted to.

Re:Why prefer java? Resilient to Refactoring..

[Peaker]

What's the difference?

You need a UT framework for all your code anyhow, if it is going to run correctly and not just run safely, so what's the difference if its a compilation error, or a UT run error?

Re:It is the nanobots making him say that...

[argent]

And what a shame that would be, all those CPU cycles currently going to the JVM and wrapper classes would have to do something practactical instead.

Re:Insightful?!?!

[3vi1]

And/or for that matter, post something funny/insightful as an AC? It blows the mind.

In the *enterprise*?

[elemur]

Well.. this sort of question will lead to the following answers:

1. I don't use Java because my machine is too slow, I don't like applets, or perhaps they use one Java app and say its ok. (These answers are from people who didn't read and understand the question.)

2. I like Java == Coffee! (These answers are from people who did read it, but were being funny.. thats good..)

3. I don't see Java used in the enterprise at all. We run a pure win32 shop and block Java at the firewall. In fact, we only drink tea to ensure we are not contaminated. (These answers are from a software company in Washington state mainly.. with a few other unfortunate exceptions as well.)

4. We use Java in the enterprise. (These answers are from people who actually work in an enterprise.)

A definition.. the enterprise does not mean your home network.. your school lab.. sourceforge.. freshmeat.. the internet cafe that you swap sysadmin services for free scones.. it means large corporate systems and infrastructures.

I haven't seen any enterprise-class system *not* oriented towards Java in a long time. Even ones not build in a J2EE model have evolved over time to support many of those components to streamline integration and development. Java has a good solid foundation in these areas, and with newer versions of the J2SE/J2EE specifications, it gets to be a richer server and client platform.

As far as Java on Linux.. I think the question should be more focused on the adoption of Linux as opposed to Java. Many places I work run many Java applications, but have requirements that Unix-hosted systems and applications must live on Sun Solaris, IBM, or other platforms. These requirements simplify management, accountability, and vendor management. That is worth a lot. Getting that Linux box online is cheaper when compared to that Sparc box, but the lifetime of supporting and maintaining the box could be higher if you are already supporting a large Sun infrastructure. This is all irrespective of Java.

Probably one of the biggest deals for Linux in the enterprise is Oracle's push and support of Linux for their entire suite of applications, and for publishing effective case stories on horizontal scaling on Linux systems. This benefits Java, as that is the primary language in Oracle-land now, but its a bigger benefit to Linux. IBM's push for Linux and Java is also very effective... (I rate Oracle higher, since they don't have a hardware issue to bring to the table, and are just pushing software.. IBM does push the software in the Websphere suite, but tends to bring hardware as well..)

So.. Linux is gaining in enterprise acceptance.. therefore Java on Linux is gaining.. but I think Java is set and has proven itself. Its Linux that is doing the proving now.

Re:I'm usiging the original

[argent]

You upgrade to a 64-bit processor. Does your executable automatically run 64-bit with optimisation?

No, it runs in native 32-bit code instead of being emulated in an optimised JVM that makes it only five or ten times slower than native code.

Not to defend C++ (that'd be like defending smallpox or herpes), but that's a silly argument.

But can Pogo work under Linux?

[Wheelie_boy]

Sure, there's lots of Java out there, and it all seems to work fine on Linux. Except for Pogo.com, whose games insist that I don't have Java installed.
And yes, it's really Java, not JavaScript.
Anyone know which of several jre's or jdk's will work? The Pogo folks don't seem to want to provide an answer.
I'm running Fedora Core 2 with Mozilla 1.6.

I use it a lot

[jswalter9]

And if Mono's libraries are as comprehensive and well designed (haven't fully investigated yet), I'll use that.

Maybe it's just me, but Java "feels" like the cleanest language around: strong types, immutable strings, very clear inheritance rules, no direct access to memory, no "shortcut" confusionisms (ala Perl)... and, OF COURSE, a way to throw all that out the window if there's a need. :)

Re:yeah, look at all the forks of perl/python, etc

[nicolas.e]

Just as has happened with those other highly portable, standardized, cross-platform languages like Tcl/Tk, Perl, Python, etc. (Oh wait, I forgot, there are no other portable, standardized, cross-platform languages, my mistake.)

Enlightened script languages, I would say.

And the best part about using java? It's low-level C/C++-like syntax and data structures means that you get to write many times more lines of code than you would need to to code the equivalent in tcl or perl or python. Why is that good? More money for programmers to write and (especially) to maintain all that extra code!

Yes, the best part. All this extra code allows the programs to be clearer, better organized... Maybe you're also one of the people who find java crappy because it forces you to catch exceptions ?

Oh yeah, and all three of those other languages I mentioned have all settled on a single cross-platform GUI toolkit to share (Tk). How many GUI toolkits are fighting for dominance in the java world these days? I stopped counting after three. Boy, that there's some good standardization!
Uhm ? For tcl only... I can name Perl/tk, perl/gtk...

And as of Java ? Except for crappy OSS projects, Swing and AWT only are used.

people who usually don't have a clue what else is out there.

Maybe you ?

Linux and Java

[Adnans]

I followed the live webcast and I would have to disagree with Lawrence Lessig on his point. His premise that Java is not being adopted by the Linux community because it's not OSS is not based on any figures and was one of the weakest stances in the debate (together with the Sun guy arguing against Open Source Java because it would make the VM not as stable as it is now). However, when I look around I see Linux and Java together everywhere! I personally use Java daily in the form of Tomcat and Eclipse. Actually, our company is deploying Java on Linux at all our customers. Most of the development team is also standardizing on Eclipse. So at least from where I'm standing at Linux and Java are quite happy together and being very productive too...

As for releasing Java under OSS, I'm all for it. I only have to look at the Apache Jakarta community for an excellent example of how (Java) technology thrives under OSS

-adnans

Re:only on embeded

[aled]

The most in webservices is the Perl and PDp

And you info comes exactly from where?

Buzzwords...

[zarr]

Yes, you're right, "Java" is a buzzword. Much like "The Internet" and "Color TV"...

Re:How about none ?

[nicolas.e]

what exactly can C,perl,python etc etc do that asssembly cannot ?

Then why are there other languages than assembly ?

Re:MOD PARENT UP

[aled]

Azureus bittorrent client is cool, runs fast, has a graphical interface and is coded in Java.
I desinstalled bittorrent after tried it.

Re:I'm usiging the original

[Decaff]

bash: java: command not found

Java is installed on 60-70% of all new PCs, and is available as a free download on almost every platform.

With a runtime the size of JRE 1.4+, there's little advantage over shipping your compiler with your package

You are confusing compiler with runtime. The JRE1.4+ runtime is just over 10mb. And, hey, you need to install it once for all java apps.

What is the

What you're missing is that the JVM, in its quest for ultimate portability, defines a fixed 32-bit size for your common integer type. Meaning that java applications do not take advantage of 64 bit precision on 64 bit machines.

These are a set of statements that don't relate.
Java, for compatibility, keeps the size of byte as 8 bits. Does this mean it can't take advantage of 64 bit processors? Of course not. There are ways to optimize all memory access with 64-bit moves as against 32-bit moves, and of course Java longs are
64-bit and Java doubles are 64-bit. The JVM can even recognise specific processors and make use of specific register sets to optimise code. All this is done at run time with no effort required from the developer.

Of course, if you want to personally keep and manage dozens of finely-tuned binaries for different versions of Intel 32-bit, 64-bit, MMX and AMD, that's up to you.

Some hard numbers

[johannesg]

Just looking at sourceforge for a moment, I see that it has 13785 projects in C, 13922 projects in C++, and 12588 in Java. That places the three languages at roughly the same level.

No other languages come even close to these numbers, although I still have some hope for the future of Euler. Actually I don't, just kidding ;-)

Re:Some hard numbers

[dmccartney]

No other languages come even close to these...

I was intrigued to see PHP ranking up there with 9391 projects.

Re:It is the nanobots making him say that...

[Decaff]

And what a shame that would be, all those CPU cycles currently going to the JVM ..

what are you talking about? the jvm is just a program like any other. What 'wrapper classes'? if you read recent slashdot articles you should have noticed that java is fast.

JVMs dont magically eat up cpu cycles or memory. Java can run on small embedded systems and mobile phones.

Re:I'm usiging the original

[Decaff]

No, it runs in native 32-bit code instead of being emulated in an optimised JVM that makes it only five or ten times slower than native code.

*sigh* This is nonsense. Its been nonsense for years. For goodness sake, keep up to date. Java is now comparable to C++ speed. Just look back at recent Slashdot articles.

But how much *good* java software is there?

[Tracy Reed]

There may be lots of java projects listed on sourceforge but I can't say I have ever downloaded and used any of them except freenet and i2p and they both have their share of java-induced problems. I regularly download software from sourceforge and other open source project sites but it is almost always C or python or perl or something. Are there any java killer apps? I've heard jakarta and tomcat and jboss are popular but they would seem to be rather niche applications, I've certainly never had a use for them nor do I know anyone who uses them although I occasionally see someone on /. or elsewhere mention them. It would seem that java is mainly used server-side. Why is that? For what reason is it not desireable for client applications? I have my own ideas but I would like to know what others think.

Re:But how much *good* java software is there?

[MaoTse]

Well, most of that stuff is interesting to web-app people. It is a simple fact that at moment there's *huge* pressure for OSS to catch up with J2EE related stuff and kill all those BEA or IBM implementations.

It is a pity all those people choose Java for that job instead of for example python ... Java is not a perfect language but is already slated to fulfill all those *beautiful abstractions* promises by academics and now industry.

Re:But how much *good* java software is there?

[Fnkmaster]

Tomcat and the other Apache Java projects, and JBoss aren't niche applications. They are important server side applications - these are the kinds of things most large companies use for a huge portion of their development work. If by niche, you mean only a relatively small fraction of people actually need to download and install these applications directly, then you're right, but they are used all the time by people accessing web applications built around them.

Java just isn't ideal for most client-side stuff - if it was used more often, more people would already have the JRE installed and set up so they could just double-click on a Java app they installed and it would run. Certainly, with SWT and the like available these days, writing decent client-side Java apps is entirely possible. Personally I still hate Swing (well, it's fine from a development point of view, I just don't like using apps written in it with a few exceptions which are all development tools or IDEs).

Re:But how much *good* java software is there?

[JamieF]

Java (or at least, the class library) has the problem of bring caught between a rock and a hard place for client application development. One the one hand, people want the download to be small, but on the other hand, developers want a full-featured class library.

One solution to this would be to have a reduced class library for applets vs. standalone client development, but Sun chose not to do this. (Right now the size of the JRE installer is about 12-15MB depending on platform.) Presumably the motivation was to have a single platform for developers to target, and to avoid a situation where users would still have to download "the rest of Java" because they only had a reduced applet runtime.

Another solution would be to get OS vendors to bundle the JRE with their operating system. For an underdog OS vendor this would look like a great idea - just bundle this free thing and you get all these apps. But for Microsoft this would clearly not be a desirable outcome, so it's not surprising that they fought it. They were eventually prevented from bundling a (slightly) crippled Java, but a strategy of just refusing to bundle Java would have worked just about as well.

A third option almost happened - get a third party to bundle the JRE. Netscape did this, and as lots of folks are aware, the Netscape Java VM had some problems. One of them was the decision to defer VM startup until the first applet was encountered, leading to the cursed "Starting Java..." lockup that froze the whole browser (if not the whole computer) for several seconds. Users got used to the idea that Java = system lockup. The second problem was just VM quality. I've spoken to a couple of employees of Netscape about this, and they both point the finger at Sun, saying that basically what they shipped was heavily based on Sun code that (according to them) was very buggy. I had a mental picture of a mostly clean-room implementation but apparently Sun and Netscape collaborated very closely on the Netscape VM and it still had lots of bugs. So developers and users got used to the idea that Java = buggy. Of course the bundle-with-Netscape strategy worked for a while anyway, but when Netscape became less desirable, it ceased to be an effective vehicle for bundling a JRE.

Hastily implemented hacks

[metamatic]

It may take time to get features in through the JCP, but it also ensures there are no hastily implemented hacks making their way into the system.

Now that's what I call comedy!

What are those deprecated classes and methods, then? Even things as simple as date and time classes and InputStreams were hacked in, then deprecated and replaced. Then there's the SAX parser, which was replaced with a totally different API...

Re:Hastily implemented hacks

[a_n_d_e_r_s]

Thats pre-JCP stuff that was bad from the start.

Re:Hastily implemented hacks

[pyrrhonist]

Then there's the SAX parser, which was replaced with a totally different API...

Oh for the love of...

• SAX isn't Sun's API.
• It wasn't replaced, Sun added JAXP.
• SAX is not deprecated.
• It's still in the JDK.

Re:Hastily implemented hacks

[metamatic]

In that case, why does the page I posted a link to list SAX as a deprecated API of Java 1.4.2, and SAX2 as its replacement?

Re:Hastily implemented hacks

[pyrrhonist]

In that case, why does the page I posted a link to list SAX as a deprecated API of Java 1.4.2, and SAX2 as its replacement?

You're kidding right? This change happened more than 4 years ago, and since SAX is a cross-platform API, other languages were affected too.

The SAX API evolved to include Namespace support for version 2. At the same time, some classes were deprecated in favor of newer classes. IIRC, the community asked for this, so it wasn't like it suddenly changed overnight. In this case, only the following classes from the entire SAX API were deprecated:

• org.xml.sax.Parser
• org.xml.sax.DocumentHandler
• org.xml.sax.AttributeList
• org.xml.sax.HandlerBase
• org.xml.sax.helpers.ParserFactory
• org.xml.sax.helpers.AttributeListImpl

The deprecated classes are still packaged with the JDK. If you're really intent on using obsolete classes, go ahead. Personally, I like being able to parse namespaces.

Again, SAX is not a Sun API. Sun updated their implementation to match the SAX specification, as did other implementors (like Microsoft). If you have issues with SAX1 deprecation, please contact the author.

Experience building a real application; which JDK?

[geophile]

At my company, we started building a new product on RH9 using Sun's
JDK 1.4.2. This worked fine through development and functional
testing. But once we started doing stress testing and scalability
testing, things got difficult.

First we hit the infamous LD_ASSUME_KERNEL problem. The JVM would
freeze up mysteriously on innocuous statements such as "count =
0". This happened in synchronized method, and the more threads there
were, the more frequently we'd hit this problem.

Then we discovered that the Sun JDKs management of memory in
conjunction with nio classes was not so good. Memory usage as reported
by Java was fine, no leaks, and then all of a sudden we'd die with an
OutOfMemoryError.

IBMs implementation seems to be of higher quality on Linux, and that's
what we're now using.

Having gone through all this, I'm still glad that we're on Java. It's
a very nice language, performance is more than adequate (for our
application anyway), the libraries are excellent, the tools are
excellent, and I'm happy not to be dealing with memory corruption
issues.

java on Debian

[olcrazypete]

Not to make this a how to, but afaik, Java is not supported on debian, due to the "non-free" nature of it. Anybody got a simple way of getting the blaim thing to install? So far I've made it very nicely, the only use I would have had lately is some crap websites that use java for rollover buttons, but every now and again you need to run an app.

P

Re:java on Debian

[Adnans]

Just download Sun's JDK or JRE and install. The distribution also comes with plugins for Mozilla/Firefox. Works like a charm.. unless of course you're a Debian purist who only wants .debs on his/here system, in which case you have bigger problems :-)

-adnans

Re:How about none ?

[HeltenHelge]

( And what can assembly do that you cannot do by screaming binary code into a microphone? :-) ) I like Java for its platform independency, and for how fast I can create a working application, but most of all I really like the API documentation! It's so accessible and comprehensible that I have never felt the need to buy a single Java book. Everything I want to know how to do in Java I can find out in a matter of minutes by browsing the API. I am proficient in C, C++, Python, O'Caml and even Visual Basic, but I use Java whenever I can get away with it.

Java vs. OSS

[RAMMS EIN]

``It may take time to get features in through the JCP, but it also ensures there are no hastily implemented hacks making their way into the system.''

However, these hacks do clean up. Virtually all influential OSS projects emphasize elegance of the code. On the other hand, the Java "we'll design everything into the language and make sure it's good approach" reminds me very much of Ada and C++, and can already be seen to a language that is 1) so bulky it's a monumental task to implement the full spec
2) inflexible; the designers assume everything will be in there, so no need for macros, etc. The result is that the language _can't_ accomodate everything
3) slow to adapt to Real World requirements

``Quite frankly, the vast majority of OSS projects which don't come from Linus, Apache, Mozilla, or IBM have proven to be an absolutely disgusting mess of poorly and un-documented code.''

Oh yeah. I agree with that. And what about the Java source code? Is that any better? I don't know, and I don't think you do, cause it's closed source. Besides the vast amount of crappy OSS, there is also a massive amount of good code, and improvements are being made accross the board.

``OSS means no sanity checks on feature creep, portability verification, documentation verification, regression testing, and all the other enterprise-project aspects of development that make it a useful technology.''

What makes you think that? The OSS community has a strong preference for elegance, as opposed to the closed source world, where creeping featurism seems to be the standard. OSS tends to be more portable, too. Documentation is an issue, but it hasn't been getting in _my_ way very much, so I would imagine the same goes for others. Verification and testing, I think that OSS definitely has more potential there. If that potential is not being exploited, that seems a matter of choice rather than necessity.

``I've lost track of the number of times I've encountered platform-specific hacks in OSS code that weren't properly #ifdef-bracketed, or which just completely incompatible with other O/S implementations.''

And in Java, you can't even #ifdef at all; all platform specific code is going to be compiled in on every other platform. Incompatibility with other platforms is caused mainly by the lack of support for standards that _do_ exist. It's kind of like using Cocoa or win32 interfaces in Java. The good news is that, in OSS, these things can actually be fixed, and they will be, if the software becomes desirable enough.

I have to say that I think your post was a very bad one, with nearly all your arguments flying back in your face. Please be a bit more thoughtful in the future. That goes for the moderators, too. /pedantic

Re:Java vs. OSS

[msobkow]

"And what about the Java source code? Is that any better? I don't know, and I don't think you do, cause it's closed source."

You can download the source for the Java class libraries the same as any other developer. You'll not only find it is clean, documented, and commented, you'll find those API manuals you reference online are all embedded in the source.

Downloading the source is incredibly useful for debugging thorny issues. The code is available for that purpose to anyone, which means you can also peruse it just to see an example of documented, structured code. The fact that you can't change it to suit your whim isn't "closed" source, it's community managed source.

By claiming Java is "closed" source, you spout the same inaccuracies as Microsoft claiming that "shared" source is the same as "open". Both are a dishonest attempt to mislead and redefine terms to suit your political agenda.

We use open sourrce Java

[ahmetaa]

In our current project we use Java. This is a big project with possible thousands of server, tens of thousands client installation. Platform portability was not our main concern, but it is a bonus. open source tools are very good in java. there are aproximately 20-30 open source libraries we are using, but not the GPL ones. Apache, BSD types mainly. Some are: Tomcat Hibernate and related libraries Spring Lucene Webwork Hessian Apache commons Dom4j Log4j Velocity some codehaus apps. i prefer java anywhere. because it is strong, has many open source libraries and easier to use.

Re:It is the nanobots making him say that...

[argent]

I don't read slashdot to learn if Java is fast, I run Java applications and applets to learn if Java is fast. And, well, it isn't. What's fast is modern processors: you can't buy a slow desktop computer any more, and you can hardly even buy a slow handheld. Java is reasonably slick on the desktop because you've got cycles to burn... but it's not fast, nor efficient, not small.

And while that doesn't matter that much on the desktop any more, it sure as heck matters on servers.

I'm currently using an 8 year old Mac with a processor upgrade that brings it up to parity with 1999-2000 iMacs, and an obsolete-in-2002 video card. It's *still* got CPU cycles to burn on translucent windows and animations and 24-bit hi-res desktops with screen savers running in full-screen on a layer between the windows and the background. But it's barely got the CPU cycles to spend on Java... Java applications are noticably slower, not *very* much slower, not enough to make me go "OK, I'm not using Java", but enough to see.

So, hey, I can see how someone with a modern computer sees Java on the desktop as fast.

BUT...

On the server, things are different. CPU time still matters, because you're sharing that CPU time between thousands of browsers. Consider, if you like, a parallel with another web technoilogy: on the desktop, it doesn't matter if an applet is written as a shell script that forks and execs a dozen programs before it's done, but on the server side that overhead is killer... which is why people have been avoiding CGI in droves.

So, JVMs don't "magically" use up CPU cycles or memory. They do it conventionally, unmystically, and systematically.

Oh, and "one more thing": They *do* run on embedded systems and phones... using stripped down class libraries, and still I quit using Java technology apps on my Palm and deleted the VM, because it was slow enough *there* to be annoying.

The Answer

[RAMMS EIN]

``how many Slashdotters are also Java users?''

42

Re:yeah, look at all the forks of perl/python, etc

[Dj]

Um, and SWT. You forgot SWT.

And Swing is built on AWT, so you don't need to double count em.

Re:I'm not a coder....

[zarr]

I'm not a coder and from my perspective java sucks just as badly as flash...

You're right, as a client side web technology, Java suck badly. On the server side OTOH, java is King.

You should read the post above your own (by elemur). It sumarizes the sutuation pretty well. (You're in the first category btw..)

...java is propular because it is possible to create quick and dirty (spelt CHEAP) solutions to relatively minor coding challenges.

The real value of java is actually the ability to write quick (and thereby cheap) solutions to massive coding challenges.

Re:I'm usiging the original

[argent]

If Java is comparable to C++ speed, then that C++ code is doing something wrong, or C++ can be a lot slower than I ever imagined.

"look back at recent Slashdot articles"?

Ah, an unimpeachable source.

desktop java apps on linux

[Milton Waddams]

why don't distros, especially desktop ones, make java use a gtk or qt look 'n' feel as the default instead of the crappy java one? i think it's a reason why people don't use it as much. they see how crappy it looks and disregard it. windows and mac os x users don't notice that much of a difference when using the apps because the java apps have the same look 'n' feel as their other apps. java isn't slow. it may be a bit of a memory hog and it may take a few seconds to start a java app but so do alot of apps built with c++ like openoffice.org and mozilla

Depend on how you look at it

[Per Abrahamsen]

With regard to "core" code of GNU/linux, Java is only just on top-10 accodung to this analysis, which count lines of code in a distribution. But Java is much more popular for specialised situations, than for general purpose tools.

Language SLOC (%)
C 21461450 (71.18%)
C++ 4575907 (15.18%)
Shell (Bourne-like) 793238 (2.63%)
Lisp 722430 (2.40%)
Assembly 565536 (1.88%)
Perl 562900 (1.87%)
Fortran 493297 (1.64%)
Python 285050 (0.95%)
Tcl 213014 (0.71%)
Java 147285 (0.49%)

Re:yeah, look at all the forks of perl/python, etc

[Xtifr]

Enlightened script languages, I would say.

Technically, you're wrong; they're byte-compiled (except maybe tcl). But I understand what you mean. But so what? They're pretty damn enlightened! Check out, e.g., Zope before you sneer at python.

All this extra code allows the programs to be clearer, better organized.

By that logic, assembly language programs must be the clearest and best organized programs of all.

> people who usually don't have a clue what else is out there.

Maybe you?

Well, in nearly 25 years as a professional software developer, I have used (off the top of my head) assembler, basic, C, C++, forth, java, lisp, pascal, perl, python, shell and tcl, and dabbled in ADA, APL, eiffel, prolog, ruby, smalltalk, snobol and more. The biggest gap in my education is probably the functional languages like OCaml and Haskell. I think I have at least a bit of an idea what's out there. How 'bout you?

Re:OSS Mono to take over?

[downbad]

Actually, Slackware 10 does not ship with Sun's JDK.

Java Highly Used !!!

[Dozix007]

Java is used all across the Linux community !! It is used everywhere !! Why you ask ? Because it is universally compatible. If I were to write an application for a company with a mixed Win\Linux environment, Java would be the soloution. C can be used, however you have to worry about cross OS compatibility.

no "vs" there at all

[dekeji]

about the possible merits of open-sourcing Java vs the market's demand for continuing compatibility

That phrasing suggests that open sourcing would have threatened compatibility, but the exact opposite would have been the case: under Sun's processes, Java has fallen apart: several different toolkits (AWT, Swing, SWT, ...), several incompatible 3D APIs, incompatible and incomplete implementations (Sun's, gcj, etc.), several incompatible levels (J2SE, J2ME, J2EE, ...), and on and on. Even among Java implementations based on Sun's code, there are wild incompatibilities. C# and Mono are futher incompatible branches off the Java tree. Open sourcing Java could have reduced those incompatibilities because people wouldn't have had to reinvent the wheel just in order to get around Sun's licensing restrictions; something like Swing, for example, would have died its well-deserved death early on, instead of being kept alive artificially by Sun.

Of course, why any of this is worth worrying about anymore, I don't understand. Java has failed on all its promises: its promise to become a platform-independent way of delivering applications via the Internet, its promise of becoming a universal client development language, and even its promise of becoming a good server-side development language. Java hangs on in education, but as Pascal shows, that doesn't mean much. And some big corporations with too much money still try to use Java for "enterprise systems", but you can sell those guys anything.

Re:no "vs" there at all

[Anonymous Coward]

This smells like a troll to me. If you would have put a "Netcraft confirms that Java is dying" in there, I would have known for sure.

Most of these "incompatibilities" that you are citing are merely different libraries, some of which aren't even produced by Sun. Some of those libraries aren't even in competition with one another (e.g. J2ME, J2SE, J2EE). They aren't "incompatible" with one another if they aren't trying to solve the same problem.

I believe that Sun fears incompatibility when it comes to the language, not its libraries. People have been making third-party libraries for ages, and open-sourcing Java isn't going to stop that. Pointing to copious libraries and saying "Look at those incompatibilities! You might as well open up Java!" is a deceptive argument that grossly misrepresents the current state of affairs.

Re:It is the nanobots making him say that...

[Decaff]

but it's not fast, nor efficient, not small.

I think this is because you are basing your experience on Java GUI apps, which have really let Java down. The way Swing was implemented was a big mistake, but thank goodness that is not used that much these days. Try SWT, and see Java run fast.

but on the server side that overhead is killer..
That is Why Java is so widely used server side. That is why Java is so finely tuned in terms of multithreading and multiprocessing. Server-side developers aren't crazy - they use Java because its a damn good way to implement programs that handle those thousands of threads and requests per second.

Its FAST.

Palm and deleted the VM, because it was slow enough *there* to be annoying.

Most Java VMs on Palm only run as interpreters, not JIT compilers. That's why it is slow, unfortunately.

Re:I'm usiging the original

[Decaff]

If Java is comparable to C++ speed, then that C++ code is doing something wrong, or C++ can be a lot slower than I ever imagined.

Whatever. This is statement of opinion, not fact.
Write some comparable code, and try it.

"look back at recent Slashdot articles"?

There is a core of anti-Java bias on Slashdot. I assumed that if I pointed back to a Slashdot article that demonstrated Java speed, I might make some progress in countering that bias. However, there are, of course, plenty of independent studies.

Re:I'm not a coder....

[cyclop]

I can't see why can't you use some quicker language, like Python, Ruby or PHP...

nearly none

[dekeji]

Have a look at your Linux installation. Do you even have a Java runtime installed? What are the dependencies when you try to remove them? Chances are good that, even if you happen to have a Java runtime installed, you can remove it without losing any functionality you use. Compare that with, say, Perl.

Unless you have a rather unusual and specific need (Tomcat, JSP, Java homework problems, you probably will never need Java on your Linux system.

It's true that people have started a lot of projects in Java: there has been a huge flurry of "X-in-Java", where "X" is any existing piece of software, but few of those projects have been successful. And most Java projects that have yielded something useful are just Java projects to produce tools for Java programming, rather than anything any normal user might want to use.

I stopped using Java because of Linux.

[torpor]

Pretty much, for me, Java's promises have been delivered by the linux kernel, as a whole, pitched with whatever stuff i can roll with it. Write "once, run on anything" is as much about build tools as it is JIT-interpreters.

And I've always had a bit of a thing for C. The 7 or 8 Java projects I've been involved in were -fun- from a programming perspective, but it still feels like a cocktail language that gives itself its own reasons for existence.

I don't really think its safe to say that about C, which is fundamentally still 'just another assembly language'.

Complete kernel and libkits assembled with sharp C /bin's, are just as nice a package to deliver, even still, as say, a .jar file or some such thing ...

Java was a good lesson, and still is. It is a productive language. But this can be said of any language and its use in an application framework, really, and for me, the vmlinuz+/libs+/bin subsystem does what Java promises.

Amen to that...

[Phil John]

...some of our clients want real-time chat facilities on their sites (a bit like the liverperson support system), we provide this using a custom built Java chat server.

Now that we've got proper Non Blocking I/O and you don't need a thread for every connection (or to implement your own multiplexor with JNI) the memory usage of our server app has come down considerably.

Looking at the latest stats on my performance monitor it's currently dealing with 463 concurrent connections and using roughly 70 megs of memory, which on a server with 2 gigs is nothing.

Re:yeah, look at all the forks of perl/python, etc

[nicolas.e]

I actually double counted them because some stuff are quite redundant (ie Panel vs JPanel), not because they are independent.

ASF's involvement in Java

[jaaron]

Speaking of Apache's work in Java: the ASF's real concern is not an open source Java, but the ability to write open source implementation of the various specifications (JSR's). See: http://www.intencha.com/adrian/000167.php for a good blog entry on this.

Re:yeah, look at all the forks of perl/python, etc

[nicolas.e]

By that logic, assembly language programs must be the clearest and best organized programs of all.

That's not what I meant, but I think you know it. I mean that features such as strong typing, mandatory exception handling, encouraging good organisation of the source provide much more readable code.

Experience in third-world countries

[eyefish]

My experience in third-world countries is that developers are more likely to develop for an open and/or cross-platform architecture than in developed countries. In that sense I've noticed that most Linux development occurs with Java (and to some extend PHP). Another pattern I noticed is that many developers use Windows to develop Java apps and then they deploy them in Linux.

Java/Linux work for me...

[syslog]

I have used many languages on many platforms in the last 15 yrs. Pascal on mainframe. Assembler on mainframe. Pascal on DOS. C on Amiga. C on DOS. C on windows. C on Solaris. Rexx on Amiga. C on linux. C++ on solaris. C++ on windows. Perl on windows, perl on solaris, perl on linux. And obviously, Java on windows, Java on Solaris and Java on Linux.

My last 4 enterprise apps were developed on Java on Windows, and deployed to Java on Linux. Slick. Thats my fav development/deployment environment. I love it.

You argue: It takes too much resources!
I answer: So what! I have to quickly build enterprise apps that have to be rich in functionality and be scalable. Project costs are affected far more by time to develop, and developer costs are far higher than hardware. Makes no diff to me if I have to spend a few thousand dollars to get more RAM, faster CPUs etc. My project still completes sooner and is more robust than it otherwise would be.

Works for me!

Thanks,
naeem

Eclipse

[bcs_metacon.ca]

I use Java for Eclipse, so I can develop Perl in a nice IDE. That's just about it.

Java is here

[daybyter]

Lots of Java on my Linux desktop. Most UML tools are written in Java...

"vs performance"

[Baldrson]

You missed the significance of my having included the phrase "vs performance".

In context, that generates a number of ratios. One ratio is verbosity vs user-standpoint performance, or execution speed. Agreed, the JVM's may have come a long way in the last few years (or not) but first impressions stick and even though Java is a derivative of Objective-C, it is VM'ed rather than native-machine compiled so it has some inherent disadvantages. Perl, Python, Jython or even Javascript have better ratios, in this regard, even though they are all based on VMs. C++ is somewhat more extreme and in the case of C the performance penalty is even greater due to all the work that has gone into optimizing compilers for that langauge.

Learn ratios -- they're really useful. They can give you rationality.

Re:"vs performance"

[sosume]

Actually, using a VM *does* have advantages, especially in memory and object lifetime management. In certain scenarios, VM environments can vastly outperform native code.

I don't use it because of the license.

[GnuPooh]

I actually really liked Java when it was new and was a big advocate. But when it became clear that Sun was "controlling" the language and it's wasn't open then I quit using it.

Popularity vs Performance

[Baldrson]

Popularity is for politicians. Performance is for the poor suckers they tax.

Re:OSS Mono to take over?

[Milton Waddams]

i've been wondering about this. in order to ship java with a distro, do you have to pay sun some money or do you simply have to flash the EULA on the screen and tell the user to "Accept" to install?

Re: 1.5 "features"

[alder]

.... we are at 1.5 beta now, that one fixes all your complains about int versus Integer and Container classes.

It's difficult IMHO to see boxing as a fix for primitive and wrappers dichotomy. Arguably this is rather a misfeature that language will be better without. Oh sure, it'll allow transparent application of operators to primitive and wrappers, which on the surface will look nice, but without understanding what compiler produces behind the scene we will be facing much slower code pretty soon.

Always comes back to java

[jonathanduty]

The last 6 places I have worked have all been new projects where the first task was to pick a technology to use. In all of them we gave all different types of languages a fair shot, but in every one it always ended up being java. I think a big reason is:

Java has its fingers in almost every type of automated technology, from xml to web services to graphics to databases to GUIs to web. There is really good code out there that will cover all of those bases, a lot of it is free.

Project startup time is fast It seems to take less time to get a java project up and running. We don't have to worry about buying software and becoming a MS Certified partner so we can get discounts. Just download stuff and go. Sure project tools can get complicated in java, but most of my clients always opt for the simple approach (ant, maven, eclipse).

Less Restrictions I'm not saying java is 100% platform independent. But it does lend itself to less trouble than say, worrying about what version of MS Server will run both our new .NET apps and our old ASP pages and won't F#ck the registry between the 2. If I develop a JBoss or Tomcat app, I can develop it on Windows XP and deploy it on a Linux or Solaris server.

A huge user community! Java has a huge user community and since many are "open source centered", the tend to be very willing to help with an error message or a config problem. Several people in the Jakarta community do nothing but respond to mailing lists.

Speed is becoming less of an issue I admit, the first java was slower that anything... but they have put a lot of effort into correcting those problems and the new releases benchmark close to even c++ in most areas except trig functions. With process speeds and cheap memory this is less and less a problem.

I'm not saying java is the last language you will ever have to use... but in my opinion the benefits out-way the downfalls. If it saves money and time... then thats longer my boss can afford to pay me!

Re:I'm not a coder....

[zarr]

Quicker in what sense?

If you're just doing some "light" server side scripting, then one of these are probably a better choice than Java. I'm not a huge fan of jsp myself...

If you're doing something more complex, you get a lot of stuff for free with Java: Infrastructure stuff like application servers, libraries (jakarta...) and development tools. Do python, ruby or php have something comparable to j2ee?

Re: Question about Java

[colinrichardday]

Does Java have an equivalent to Python's eval()?

in Python

>>>from math import *
>>>x = 7
>>>function = "sin(x)"
>>>eval(function)
>>>0.6569865987187890 6

That is, is there a Java function that will accept a mathematical expression in a variable and evaluate that expression for a guven value of that variable?

Note: for those of you playing this at home, set your calculator's angle mode to radians.

I was there

[deanj]

I was there during that keynote, and his statement was that it was heavily used under Linux, NOT the MOST heavily used.

Re:Ease of use sometimes requires minimizing featu

[gbjbaanb]

Heck, even when we tried to performance tune the application, we wound up with gobs and gobs of #pragma directives and custom code to either work around bugs in a target platform, or just improve performance (for example, by aligning data structures to specific address boundaries).

How is this made easier in Java? Do you mean that Java magically makes said platform-performance issues go away?

Java just makes it easier to develop. Many problems are still there, only now unsolvable that is easily (?) fixed by a #ifdef

Re:I'm usiging the original

[zarr]

Not a single method that has been deprecated has been removed.

Maybe, but at least one has (intentionally) stopped working. System.getenv(String) used to return the value of an evironment variable, but will in java 1.4 always throw an exception. The reason is that it is "not platform independent enough". Due to a lot of protests, they are puting it back in 1.5.

I agree with everything else you said in your post, though :)

More than Apache

[persaud]

Pollix, a Knoppix (Debian live linux CD) derivative with Java development tools like Eclipse, Netbeans, BlueJ, JGrasp, JSwat.

See also 300+ open-source Java components.

Debian, Java, the DFSG, and the enterprise.

[chathamhouse]

Your problem is entirely with Debian's approach to Java.

I develop and assist in maintaining over 100 Debian systems at work. The debian packaging tools are fantastic. Tack on a few small scripts, and you could expend very little effort on maintaing hundreds of machines.

Until you get into Java, which just about every enterprise is. If you're serious about it, you drop almost everything that the Debian project does w.r.t java, and add the following to your sources.list file:

deb http://z42.de debian/
deb-src http://z42.de debian/

Get j2se-package, which nicely builds sun-j2sdk1.x and sun-j2re1.x packages out of the Java .bin files that you get from java.sun.com.

You then throw these packaged into your in-house repository. Redistribution of a modified JRE or SDK (like a Debian package) is prohibited by Sun's current licensing terms.

You then might want to rebuild any Debian java packages for your repository using Sun's Java, and not Kaffe or any other hacks. When developer's complain that certain classes aren't working, answering 'but there isn't a DFSG compliant jvm that will support them' is generally not the way to promote harmony at the office, or to guard your job security. RMS disagrees with this, as per his article on 'The Java Trap', but I work in a world of reasonable compromise.

Of course, being a serious enterprise user of Debian, your in-house repository will contain a heck of a lot more packages that Java. Probably because you're running Debian/stable, with a volley of backports to support more recent versions of certain packages. OpenLDAP 2.1, MailScanner, SpamAssassin, and Apache2 come to mind.

I love Debian, I just hope that the bickering over the latest version of the DFSG doesn't draw developers away, or critically delay the release of Sarge.

Did you know that the new DFSG _should_ require many standard packages exit the main distribution and enter non-free? We're talking anything MPL'ed, APL'ed, potentially reiserfs(*), and if a few posters on debian-legal and debian-devel were to be believed, even GPL'ed code (the pre-amble).

(*)Because of the mkfs.reiserfs advertisement - you get an amazing filesystem for _nothing_, yet you complain because the funding agencies are shown while mkfs is running? Get real.)

He's missing the point

[Qwavel]

Sure Java is used lots on Linux, but that's not the point.

The point is to imagine how much more Java would be used with Linux if Sun had opened it.

If Sun had opened Java at the beginning then it would have become very much part of Linux. Java would probably even be part of Gnome and maybe part of KDE. You could call this fragmentation because many of these programs would be written to Gnome/KDE API's, but these are programs that can't be portable anyway.

I believe that both Linux and Java would have benefitted hugely in this scenario, but not Solaris and maybe not Sun. And I guess that's the problem with technologies that aren't open: Java is managed for the benefit of Sun, not for the benefit of Java or Linux (if it were otherwise the shareholders would have a thing to say about it).

Re:He's missing the point

[deanj]

Open it how? To get the source? To see the bugs? So you can submit fixes? They do that already.

If people want to prove to Sun that OSing Java would be a good thing, then I think they should prove it by fixing all the incompatibilities between the various Linux distributions first. Saying that Java won't fragment if it goes OS would mean a lot more if they could fix Linux's problems first.

Re:He's missing the point

[Qwavel]

In this case I meant opening to the satisfaction of the Linux community, so they would be willing to include it in the main distributions and they would feel comfortable making it an important part of the GUI environments.

To take a technology that is controlled by Sun for the purposes of their bottom line and make it integral to Linux would be a mistake. If you think that Java is not controlled by Sun, well, who gets to make the decision about open sourcing it?

We have the same problem with TrollTech. They are continuing to develop their own custom language, divergent from standard C++.

I'm not blaming these companies for trying to make money. Rather I'm complimenting the companies and individuals who have remained true to the values of Linux, even when this meant not using some very attractive technologies. Don't get me wrong, I'm a pragmatist, but sometimes political values can end up being very practical.

Re:He's missing the point

[deanj]

No, sorry...I should be able to run my binaries without mods on any distribution. Most of the time it works. Sometimes it doesn't...and it's a bitch to fix when it doesn't. Fix that before people start preaching about "opening Java".

Insane backwards compat

[jtheory]

If Java has done anything, it is trying to stay backward compatible too long.

I'll second that... you do hear about very minor incompatibilities with very complex apps, due mostly to new bugs or old bugs fixed, but I'm still amazed at the lengths they go to keeping compatible with previous releases.

I have a bunch of applets that, until recently, still used the PRE-JAVA-1.1 EVENT MODEL. That's right, back in Java 1.0.2 when we didn't have ActionListeners and so on yet, and events were propagated up to the parent container. It was ugly, and non-scalable, and they STILL support it in the 1.4 JRE, 6-7 years later.

i moved from C++ to Java

[rexguo]

I'm a digital artist working mainly on real-time multimedia applications. My language path has been BASIC, Pascal, C, Assembly, C++, and finally Java. I've written 2 real-time demos (as in the demoscene's demo) in C/C++/asm, but now I use Java exclusively, for the past 5 years. I've never looked back ever since. There're occasional needs for JNI wrappers for native libraries, but Java gives me much more than I can ever ask of C++. The stuff on my website will prove that I'm not bluffing. Yes Java is not perfect, but it is a great evolution. So you can hear it from me: I'm grateful for Java.

slashdot poll

[sonamchauhan]

So who was right, how many Slashdotters are also Java users?

Slashdot editors, in future please accompany such articles with a Slashdot poll.

At two hedge funds

[thammoud]

that I worked for, Linux would not have been used had it not been for Java. The ability to run Java apps on Linux casued the firms to move all their enterprise servers from Solaris/Windows to Linux. Only the database runs on Solaris.

Simple math

[BeerSlurpy]

Most linux boxes today are working as web/application servers.
Most enterprise apps these days are being written entirely in java/jsp and using web services. The only notable exception to this is the microsoft small business market which uses stuff like IIS/ASP.
So yeah, java on linux makes perfect sense in the business programming world, although not in the way most linux geeks think of programming (desktop).

You get 90% of the prettyness of a windows app, lower memory and cpu requirements, no deployment costs, no upgrade costs beyond developing the upgrade and both the platform and the language are free. Obviously, using something like websphere costs money, but that is optional.

Dont Forget

[geekoid]

J#

Re:I'm usiging the original

[cubic6]

I've got a question for you, since you seem to like JIT so much...

Why the hell doesn't Java cache the compiled code between program executions? Program portability is nice, but 98% of us desktop users install an app and only run the installed app on a single hardware system. After the first time JIT compilation occurs, every subsequent JIT is a waste until some hardware parameter changes that would affect performance. Would it really be that hard to have a system-wide cache that the JVM could check when I run Ant so it wouldn't have to JIT it every time?

Re:Ease of use sometimes requires minimizing featu

[njcoder]

Performance tuning in java is about finding bottlenecs in your logic, not programming to specific platforms. The JIT compiler does a good job of optimizing for each platform it runs on.

No.

[Bill, Shooter of Bul]

c# and .net are ecma standards. There may be some question as to the use of cerrian librarys ( winforms, ect), but they have never purchansed any kind of license from microsoft. Nice Fud, though.

Re:No.

[alext]

Speaking of FUD, Dotnet is not an ECMA standard, only C# and the CLR are.

I have no illusions that, despite having personally rebutted this assertion over 50 times on /., it will continue to be made, probably by the same group of people, and, ludicrously, even as de Icaza is preparing his exit strategy from the whole Mono raison d'etre - Dotnet compatibility.

C is C++ but, C++ is not C

[willCode4Beer.com]

Different language for sure. However, the specification for C++ requires backward compatibility with C.
Thus C is C++ but, C++ is not C.

Re:I'm usiging the original

[argent]

Oh, I don't dislike Java because of slashdot. I dislike Java because it's sidetracked the development of real object oriented languages the same way C++ has. Both of them have this hard unyeilding non-OO core that shouldn't be there, and that forces you to waste time (human and programmer) creating overlaid class libraries that hide it... and add additional layers of method calls that can't be optimised away.

My example -- client and server

[jtheory]

This isn't much of a shameless plug (since there aren't many music theory teachers on /.)... but anyway, I run a website that uses all Java on the back end -- Apache Struts/JSPs -- and Java applets (w/ AWT) on the front end.

It works... server-side, Java is great, and I use it for bigger contract projects where I can test on w2k and deploy and iSeries or Solaris. Client-side, it's not headache-free, but it's been my best option so far. The applets are limited to Java 1.1 functionality, since most users just have the bundled MS JRE. But they run fine on Mac, Linux, etc..

The cross-platform aspect was one of the biggest sells for me -- I develop mostly on win2k, deploy on a Linux server. The second big sell -- no investment in software! Eclipse, Tomcat, Struts, the JDK... all of this stuff is open source or free for me to use.

No, I'm not a pure-java nut, either... I'm using PHP for a forum I'm setting up on my site, just because open source PHP forum options are much better than what I've seen in Java.

BTW - there's another Java GUI toolkit I've been playing with lately that's a nice alternative to AWT (yes, it's bad that there are so many imperfect alternatives... you learn to deal). If you need a nice-looking, very lightweight GUI that only needs Java 1.1 to work, try Thinlets (LGPL). You can build your GUI in code, or (the better way) by parsing an XML file (the XUL model).

Re:Ease of use sometimes requires minimizing featu

[maraist]

Actually, I see a lot of code that has ifdefs in java. I have no idea why you are suggesting that this horrible method of coding is not available.

Firstly, many java apps these days are built with "ant", which contains a java tokenizer for God's sake.. This performs search-replace on the java code for special tokens; often based around version of th e JVM currently compiling the code or sometimes even based on the platform.

There are apache commons tools which can ask questions like isWindows, isUnix, bla bla bla, and so you KNOW there is platform specific code running around the open-source community.

I use a java editor which is very specifically tied to a particular version of java; it will physically not run on any other version. Subsequent releases of the editor use newer version.. It's very frustrating, but thankfully it's very easy to install multiple versions of JVM's on the same machine.

Moroever, if what you want is that totally different code is rendered for different platforms, consider this. Java HATES switch statements; only integers can be applied and most everything in java is an object; (whereas in c/c++ most things are integers; easily fitting into a switch statement). Thus if you want a switch statement, the better design paradigm is to have a base class and subclass it for each switchable item. Then you choose the appropriate derived class (I personally perfer hash-table lookups).. The advantage is that ANY redundant code in the would-be switch statement can be refactored out and reused in the base class. It's more elegant design, often easier to read; provides smaller, more concise code, bla bla bla.

So obviously if you can ask the platform which environment it is, then you can choose subclasses which implement the platform specific material.. This is much more elegant than littered #ifdefs in the middle of a conditional of an if-statement.

The argument of #ifdef performance is moot in java, since you have run-time optimization.. If you have an if statement that can not possibly be true, the compiler removes it. Thus an ant pre-compiler, resolves the equivalent of ifdefs. However, the JVM itself is likely to determine constancy (generally due to a finally clause) and thereby compile-in or out even run-time configuration exclusions. The bane and bueaty of java is that you've outsourced performance to a JVM vendor.. jRock is fast but unstable (in my experience), while sun and IBM are pretty good all around.

As far as platform issues exist. Java is slightly better than perl at being cross platform neutral (though perl is catching up). These two I would consider to be the best all-around cross-platform languages.. Sure you have kiddy languages such as BASIC or pascal (or elegant ones such as lisp).. But these languages don't work well with their host OS.. They don't translate paths correctly for one. Nor do they even allow multi-threading as java perl does.

Java is not without it's flaws, to be sure.. And even the repairing of flaws have left an unsightly appendage of sorts. But once you get past memory / CPU requirements, Java is one of my favorite platforms

Lots of Java on Linux

[wonkavader]

My company uses Java a lot.

I use a Linux desktop, as does one other developer. We produce code fast and well, using Emacs, javac and a Tomcat instance locally.

The other developers produce hideous code and it takes them a long time. They're developing on an IDE on Windows.

Then we deploy all this stuff on WinNT/Win2000.

When I need to acomplish something on Linux, I use Perl. When I'm doing something for the company, I use Java. So Java on Linux, you bet.

BTW: I've been playing with Java 1.5 -- while purists might hate the arg list change, I'm singing in my cube. Thank GOODNESS. Finally!

Re:I'm usiging the original

[Decaff]

Both of them have this hard unyeilding non-OO core that shouldn't be there, and that forces you to waste time (human and programmer) creating overlaid class libraries that hide it...

I agree - I used to love developing in Smalltalk - it was elegant and fun. The problem is that true full OO has unfortunately ever been really that popular, and languages (like Smalltalk) that provide this just don't measure up: years ago, I switched to Java because it was cross-platform at the binary level, free, and fast. No Smalltalk or other true OO language I researched could compete. Java is not perfect, but I believe it succeeded because it was a sufficient compromise to attract even hardened C coders, while providing reasonable OO.

and add additional layers of method calls that can't be optimised away.

I'm not too worried about this: method calls are very lightweight, and I believe that many can be in-lined and optimised away.

Re:Ease of use sometimes requires minimizing featu

[gabebear]

Java does fix many cross-platform performance problems by leaving the optimization up to the virtual machine, it's a similar to what Transmeta does. Some People are even claiming that Java programs are faster than programs written in C++. Less biased benchmarks still put the Java VM just a bit slower than GCC and a lot slower than a really optimized compiler(Intel's).

Re:I'm usiging the original

[Decaff]

I've got a question for you, since you seem to like JIT so much.

Its not JIT that I like, its the HotSpot optimiser - it produces optimised code based on what is actually in need of optimising at run-time, rather than what a compiler guesses is in need of optimising at compile time.

Why the hell doesn't Java cache the compiled code between program executions?

Security. Java VMs validate classes and byte codes when they are loaded. Otherwise, someone could write garbage into the code cache, with exciting results.

The latest Java (5.0) does cache some system classes in order to significantly improve startup time.

You don't have to use JIT - if you want binaries compile your classes with GCJ. I haven't tried it, but I hear good things.

Once upon a time I was a Java programmer...

[HiThere]

I must admit that I was never deeply into Java, but at one point I was a Java programmer for one simple reason:
My company wouldn't buy me a C compiler. They didn't see why I wouldn't do everything in MSAccessBasic (which they paid for as part of the MSAccess database).

Since then things have changed. E.g., Python has become available, CygWin became useful. And then I switched to Linux. ... well, it's been many years. I occasionally consider Java...whenever I encounter gcj (or is it gjc?). And I consider Java superior to C in most ways, as a language. But I don't like Sun Java. File IO is too clumsy. I prefer Python, or Ruby, or D, or even Ada. (Ada strings are a real pain though. And the lack of a built in garbage collection system yields other language constructions that are...undesireable. Though they do handle problems that C doesn't even TRY to address.)

If gcj were better documented (it's been awhile since I looked, so don't take this too seriously) I might consider it more often. Those with serious java intentions seem to find swt to be an acceptable approach. And I'm sure it's easy to link to C, but when I read the documentation it didn't go into any details. Probably a few words with someone who already knew how to do it would have clarified things, but I don't know any such person.

OTOH, D seems a much better language. It was missing a good Mac port when last I checked (there was one in early beta), but it seems to combine the best features of Java and C++ with many of those from C. But for what I'm doing now, a dynamic language (I appear to have selected Python) is a better choice. So now I'm hoping that Pyrex gets some serious development effort.

Java? I'll go back to it if it ever looks like a good choice. But usually what I see is a really clumsy way of doing some very interesting things. And the things can be done in other ways.

Usage depends on performance

[chyrag]

Most of the reponses I've read (have read all the 3 and 3+ ones), have been like:
1. Yeah, we're using java, but we won't talk about
the performance. We use it only for being a cross platform software.
2. Yeah, look at sf/freshmeat. There are a lot of projects.
3. Java doesn't have so and so feature

The debate, methinks, was about Java being in heavy usage on Linux. The reason, why something would be in heavy usage, is that, the particular software would out perform it's competitors (hopefully, by leaps and bounds), and Java has issues with performance. I'm not getting into Java Vs C++ performance here, but how many enterprise software apps are being used, which are written in Java.

Java-induced problems?

[SJS]

Last time I looked at freenet, there was no obvious way to get involved with helping out with those supposed "java-induced problems". I rather think that the problems aren't java-induced at all; perhaps endemic disorganization permeates the code, too.

Why is Java mainly used server-side? Because an awful lot of the clients are browsers. Plus, in those cases where the client isn't a browser, it doesn't matter so much if the client has a memory leak, or crashes frequently -- users are used to that these days.

Currently, I'm working on a system that does have a Java client (that runs on Linux), but that's been tasked to integrate into an existing .COM client -- but by using Java, we get to use Linux and OS X in our development, even if the target system has to be something that comes from Redmond. I wouldn't touch this project with a ten foot pole if it were in C or C++, as the .COM infection would creep thru the system.

Most of the work is therefore done server-side, in Java.

If Java wasn't here or disallowed, the whole project would probably be in a mixture of C++ and VisualBasic and chasing after .NET, and no unix of any flavor would be involved anywhere in the development cycle. As it is, those of us who use unix systems have been showing the Microsoft-centric developers how much more you can get done with a reasonable toolset and a (relatively) stable operating system.

Re:Java-induced problems?

[Tracy Reed]

Stewart, you seem to be the only person who has trouble figuring out how to get involved in freenet. :) I found the lists, the IRC channel, etc. fairly easily.

Yes a lot of the clients are browsers but they always talk to the server via http so the language on the back-end could be anything. Java doesn't have any particular advantage in that respect. When Java first came out applets were the big deal because they could run in any browser on any platform and that is where the cross-platform ability of java came into play. Because you never knew what sort of machine your applet might be downloaded to. Unfortunately nobody could get Java in the browser right due to bugs and failure to follow any real standard so they downplay that now and nobody really uses applets anymore. All of the excitement is about java on the server side but that is just where you don't need cross-platform ability so much because the code always runs on the same machine.

So I am still left wondering why Java is popular on the server side of things and rarely if ever used for client side applications. Whatever happened to the office suite in Java that Sun was working on years ago?

Three Words

[EnigmaticSource]

Fortunately, you can have all the advantages Java gives you over C++ without many of its limitations, by using C#

Fixed Length Arrays

It buggers the shit out of me trying to write [portable] crypto in C# because of that (and a few other things I'll bitch about later)

Re: Question about Java

[mrjohnson]

I'd just embed python.

Just kidding. :-)

Actually, the Java solution to this problem looks a lot different. Given the need to execute unknown code, usually an interface is used and the objects are made to implement it. Then the object will always have method foo and you can pass your data that way.

Granted, that's a lot more work. There's not a lot of Java code that is shorter than it's Python equivalent....

Open Source Java projects are rare...

[Brandybuck]

Open Source java projects are rare. While the language might indeed be highly used in the Open Source community, sharing of finished products isn't.

Yes, I know there are some open Java projects out there, so don't bother listing them for me. My point is that for every open Java project there are several hundred using C or C++. Out of 250 package installed, the only Java application I have on my current desktop system is the JDK...

Re:I'm usiging the original

[SnapShot]

Agreed. In the real world which is more likely to happen?

I just upgraded to a 64 bit processor. And my application...

A. Suddenly gives my the ability to have 2^64 documents open at the same time rather than the previous limit of 2^32 documents

or

B. Suddenly all of my custom, binary files won't open properly because some programmer hard coded "4" in all the places where an byte offset over an int was required in the file.

This is a language independent problem, a properly coded C++ app with the sizeof ops used correctly should work correctly, right? However, in java, an int is an int is an int on a cell phone or on a PC or on a mainframe. Use of int correctly is, thankfully, taken out of the programmer's hands.

P.S. I love C++ (templates are cool) and I love Java (I can get so much done). I wish I had a job where I could learn Haskell or OCaml and I'd probably love that too.

novell groupwise client....

[bkirkby]

novell's groupwise client for linux is actually a crossplatform client written in java.

also, the administration tool for novell products (ConsoleOne) is written in java and runs under linux just fine.

-bk

Why java

[bl8n8r]

First of all, I was programming in C and assembly language in the early 90's. Portability was a friggin nightmare. The idea of just taking a chunk of source code and plopping it into another compiler/assembler worked well in theory, but reality was a different story. The java system is such that one *CAN* take the same source code, plunk it down onto a completly different machine, architecture and OS and achieve the same functionality and results (within reason of course).

The ability to code on one platform and run your application on anything that there exists a java interpreter for is a wonderful thing. Especially with the upcoming Exodus from the Windows platform to Linux, there will be a big opportunity for java to close the gap on cross-platform solutions.

Linux - multithreading performance - yuk!

[Richard_J_N]

I recently inherited a chat system (java clients, java server) where the server needed to run on Linux, (had been Windows). I was delighted that the server ran, without modifications, but was appalled to discover that under Linux, it required 6MB RAM on the server *per connected client* !! Apparently, this is a limitation of Java Multithreading under Linux. In the end, I re-wrote the server in PHP (php-cli, using sockets), and the result is vastly better!

Some other observations: Java isn't just "object-oriented" - it's "object-obsessive". Why can't we have, for example, a string primitive.

Also, in Swing, why is there no way to make the scrollbar in an applet's JScrollPane just stay scrolled down! It won't automatically scroll, when text is appended to the textarea, and there is no way to make it do so. There's an ugly hack, but even this isn't reliable:
mainPane.getVerticalScrollBar().setValu e(mainPane.getVerticalScrollBar().getMaximum());

I should perhaps add that I'm not a Java expert, (I learned Java specifically for that task) and I may have missed an obvious trick, despite google.

Lastly, I don't care whether Java is GPL, but please, Sun, can you fix the licensing so that it will at least play nice with the Linux distros (eg so that Mandrake can release RPMS of it).

Re:My OS guess: MC/OS

[titzandkunt]

Wrong. Good for you for trying, though.

1 Java, 1 GLX

[beforewisdom]

I have been a Java programmer for 5 years and I even had a job developing Java pass on Linux. About 3 years ago I migrated to GLX at home. Steve

A long time C++ hacker moves to Java

[wintermute42]

I've been programming heavily in C++ for many years. While I have a love hate relationship with C++'s complexity, I never thought that I would use Java heavily. But I've been working on more web services applications that access a database. The huge class library that is available with Java is a great advantage when it comes to developing these applications. Sure I can pay thousands of dollars to Rogue Wave and get some of the same features in C++ that I get for free using the Sun and Apache Java libraries. But why? The higher performance of C++ is of little use to most applications that references a database, since these applications are usually bottlenecked in the database. And when it comes to web services (e.g., XML processing, servlets, dynamically generated web pages), C++ cannot compare to Java. And then there is garbage collection, which makes develoopment faster.

There are still applications that I would not write in Java. For example, compilers or other algorithmically intensive applications that are CPU bound. There are also times when I can simplify my code by using C++ features like operator overloading (see my wavelet packet transform algorithm for example). But these applications are now in such a minority in the work I'm doing that I worry that my C++ "chops" will get rusty.

I went to a talk by Stroustrup where he discussed C++ (some cool algorithms to support linear algebra computation), future developments and C+++ vs. Java. He promotes C++ as a systems programming language. For things like operating systems, virtual machines, hardware drivers and compilers. He trumpted C++ as the most widely used programming language. What does not seem to have occured to Stroustrup is that systems level applications, where C++ shines, are a small minority of the code programmers write. My view is that C++'s star is fading.

So yeah, I'd say Java is heavily used on Linux. At work I'm part of a group developing a distributed database application in Java (this runs on top of a relational database, so Java's performance is not an issue), hosted on Linux. I'm in the process of setting up a Linux/PostgreSQL system on which to develop a financial trading application, again in Java, using XML and web services.

correction: tcl is byte-compiled

[Xtifr]

One of my associates emailed me to chide me - as the Debian tcl/tk maintainer I should know better - tcl has been byte-compiled since 8.0. I plead old age, early morning posting, and insufficient coffee. :)

Science Apps Use Java

[BoydWaters]

Well, in our field we have lots of custom software that we use in-house for scientific data-reduction and for equipment monitor/control.

So we use Java for custom applications - GUI apps as well as web services.

James Gosling and some other Sun people came out here to visit, and perhaps got the impression that everyone in science is using Java on Linux as much as we are. Shrug. We like it.

Re:Corrected SourceForge link - language statistic

[E_elven]

The statistics are a bit skewed; there are a lot of good Java apps on SF, but there seems to be a tendency of those projects to be abandoned. I suppose the 'wrong' kind of people usually develop in Java because it's easier to get into.

Java in Linux?

[malachid69]

At work, I use Java on Windows, Linux, AIX, Solaris and HP-UX (and sometimes AS/400).

At home, I use Java on Windows and BSD (no longer run Linux at home).

Malachi

Re:That's not a particularly sage musing :)

[SageMusings]

Well Spoken,

I was merely pointing out the rationale for Jython happening in the first place. It wasn't my intent to weigh in on the relative merits of it.

It's also worth noting...

[Paradox]

... that while Sun can create classes with special semantics and overloaded operators, you the developer (you know, the person doing real work and/or paying for what Sun offers) cannot.

People talk about the consistency and elegance of the Java language, and it's hooey. Sun breaks their own rules all the time to give convenient little features like String +, but developers can't do the same thing.

I can't help but wonder why. Are developers not trustworthy enough?

Gosling is right

[Bondolo]

Java and linux is a very popular combination and for good reason. Java remains the most effective way to write business process solutions and linux is often teh best way to deploy them.

I write only Java. I use only Linux.

I'm very tired of the knee-jerk "open source java" arguments. I'm Even more tired of the "Mono is morally superior to Java" argument. The JCP.org process is more than good enough for me. .NET and C# on the other hand scare me. Regardless of that "ECMA Standard" bullshit the truth is that only one company matters in the C# game and that's Microsoft. The same can't be said about Sun and Java.

Do you really believe that Microsoft would promote any technology it didn't control unless it didn't have a choice.

Try picking up haskell sometime

[lakeland]

Or my personal favourite, clean... but as long as you can write elegant lisp and prolog you should have no trouble picking up haskell, and I'd bet it will improve you programming in other languages.

Personally I can't stand ML, but then it all comes down to personal taste in the end.

Java on Linux is not too common in my experience.

[DeVilla]

As far as I know, I don't really run any java. I've installed it I think for a token website or too and I pretty much always instal gcj along with a mess of other toy compilers 'just in case I want to play with it'. I tend to block java in the webbrowser, so even then it is rare.

At work, on AIX we run a lot of java, and my experience there tells me that it would be very unlikely that I'd be running java without knowing it. It may provide a pleasent experience for the developer, but it ain't too nice to users under X, especially remote X.

And it's down right hostile to sys admins who have to maintain the apps. Juggling jre's, keeping the right app pointed at the right jre, managing network problems caused by anti-social redraw behavior of remote X, the ever recurring class path problems and the joy of upgrading the universe all at once because some genius used RMI for a corperation wide protocol.

personally...

[ak3ldama]

I really do prefer to write client apps for linux in java. I find it a good environment to write programs in and have them be very portable. Maybe eventually mono could be used, but i'm not sure it's time.

Hey, mod parent up, please

[wintermute42]

This sure does not look like a flame bait post to me. I'd say, rather, that its informative. The poster is noting that Java, currently on Solaris is popular for enterprise applications. I'd say that's reasonable. Then they note that some users are going to .NET. The fact that the poster believes that the corporate customers are not going to touch Mono in the near future is an opinion, and perhaps one that corresponds to reality.

Java based trading applications

[wintermute42]

In the case of run once applications that are CPU intensive, like compilers, there is no question that Java can be slow (see my web page on why it is reasonable to consider compiling Java into native code)

I've been working on the design of a trade engine, which can support multiple trading applications. I'm an experienced C++ developer, but for the trade engine I'm planning on using Java (running on Linux and storing transactions in PostgreSQL).

One of the core issues in many financial applications, like a trade engine, is that they must record transactions in a database. Once you start inserting into a database it is likely that the database will become the bottleneck (unless you are using something like an in memory database (e.g., like the one from TimesTen). So the performance advantage that C++ can deliver over Java does not seem to apply for database applications. Sometimes database operations seem so slow that I fell like programming in smoke signals would make no difference.

The class libraries available for Java are more extensive than any environment I've worked in. In C++ you could only match Java's library by purchasing all of Rogue Wave's libraries. And even then, Rogue Wave can be rather obscure. In addition to the huge class library, Java gives you garbage collection, which makes development faster.

Java also provides many advantages to enterprise applications. For example, you can use an application server like Resin to start up your services and to support remote calls (via SOAP). You can also have dynamically generated web pages that display portfolio postions and other changing data.

Re:Java based trading applications

[terrymaster69]

We do use timesten actually, precisely for that reason. The cache group feature to autosync with Oracle is very useful. And it is damn fast. We do have a license for all of Rogue Wave's libraries, but you're right, Java's library set is extensive (and generally well tested).

Java = Coffee.

[rice_burners_suck]

He must have been using the word Java to denote "coffee" rather than a particular computer program. If so, then I suppose he is right, because there's nothing better after a night of drinking too much alcohol than a little bit of coffee to clear up your head.

Sun Microsystems. Where do you want to go today?

you don't understand what Mono is about

[dekeji]

Before jumping on the MS band-wagon you should realize that they will never allow mono to become equal, better, or fully compatible to win32 .NET.

Before going on and on about Mono, you should at least know a little about it. Mono is a development effort producing several things: an implementation of of ECMA C#, an extensive set of bindings to open source software, and, separately, a Microsoft .NET compatible set of libraries.

If Mono stopped working on the Microsoft .NET compatible libraries tomorrow, it would make no difference to me or to most other Mono users. The purpose of the Mono .NET implementation is not to develop new open source software on top of it, it is to let Windows users migrate their .NET software to Linux. Making it easy for Windows developers to migrate to Linux is a good thing.

But most Mono development is taking place using the open source APIs: Gtk#, Gnome, open source XML tools, etc. Those are already better than Microsoft .NET and they are easier to learn for OSS developers.

Its hard to believe that such a bastion of MS hate groups as /. would rather embrace an MS product like .net

Yes, and the resolution to that contradiction is that you misunderstand what is going on. People aren't embracing an MS product, they are embracing an open language (C#) together with the open source libraries they already know and use (Gnome, etc.).

Ignorance, not malice

[RAMMS EIN]

Ok, I did not know that the class libraries where available for download. I wasn't trying to misrepresent to make my point at all. Never attribute to malice what can be explained by ignorance.

That doesn't mean I'm going to change my point, however. When I said that Java is closed source, I was not referring to the class libraries. I was rather referring to the implementation itself. I am pretty sure that that is closed source. Note that I am not making any claims about the cleanliness of that code, other than that you don't know how clean it is, so you can't say that Java is better because other language implementations are messy.

Re:Ignorance, not malice

[msobkow]

How many OSS implementations of the JVM do you need?

You don't need Sun's implementation of a JVM to have access to the spec, nor to see different (sometimes radically so) implementations of the bytecode runtimes.

For that matter, I expect the source code of the JVM itself is probably available under the same licence. I just haven't had to look that far into a debug issue yet (I avoid JNI like the plague -- it's responsible for more Java "portability" issues than anything else, at least on the server side.)

Retraining

[titzandkunt]

I can't comment on other places of work, but I guess in our case its worth hanging onto talent, mainly because our problem domain is pretty specialised. Plus we've got to integrate with other manufacturers' military information systems, which makes the problem domain tricky^2.

If someone comes in raw, as I did, it's a couple of months before they even get a solid overview of what everyone's talking about and where their bit slots into the system. The guys who are retraining know our systems inside out and they are solid, productive programmers even with the limited tools and environments used for the older systems. Java is simple and C-like enough for them to be up and running after a 5-day course, and when they hit problems thereafter, they can call on my team (who are pretty experienced with Java) for guidance. The only hurdle, and it's a slight one, is getting across how rich the environment is and how much stuff has already been done for you, compared to the sparse environment they are used to.

While there's work to be done, it would be utter madness to discard all that knowledge, experience and "institutional memory" for the sake of a week's training, plus a bit of my (and others) time.

Ironically, when this project hits the production phase and the headcount is lowered in line with the required effort, it's likely to be me and others like me, who will get escorted off the premises bearing boxes and potted plants. The retrained guys will be ticking over very nicely and by then I doubt there's anything we could do that they couldn't.

T&K

Re:Insightful?!?!

[Rick and Roll]

Because someone thinks mod points are better used as a reward system than a way of improving discussions. Moderation involves bringing the best arguments to the front while sending offtopic comments and poor arguments to the back.

Re: Question about Java

[sonamchauhan]

> Given the need to execute unknown code, usually an interface is
> used and the objects are made to implement it.
How will it execute _unknown_ code then?

A few years back, when I first learnt Perl, I had fun writing a perl CGI that took _perl code_ via a HTML form input and 'eval'ed it. I don't think one can do this easily in Java, can one?

Re: Question about Java

[mrjohnson]

You could just execute it in BeanShell...

(Of course, there'd be no testing and no security so you wouldn't want to do this anyhow. :-)