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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

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

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

[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

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

[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

[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

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

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.

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

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

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]

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

[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

[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

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

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!

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

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.

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.

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.

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.

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

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

[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

[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

[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

[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

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

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.

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.

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?

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

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.

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.

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.

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

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.

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.

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.

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

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.

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

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.

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:Just about every programmer I know...

[aled]

Yeap, 30 years of use, you need to replace your programmers after 25 years, you know.

The Answer

[RAMMS EIN]

``how many Slashdotters are also Java users?''

42

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?

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

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.

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

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.

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.

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.

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.

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.