Slashdot Mirror


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

21 of 601 comments (clear)

  1. If you don't see it heavy used.. by Anonymous Coward · · Score: 4, Insightful

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

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

  2. Re:C/C++, not java by halowolf · · Score: 3, Insightful
    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 :(

  3. Re:Incredible, indeed by Anonymous Coward · · Score: 3, Insightful

    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.

  4. Re:C/C++, not java by Dr.+Eldon+Tyrell+TC · · Score: 5, Insightful

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

  5. Re:Incredible, indeed by Iffy+Bonzoolie · · Score: 4, Insightful

    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

    --
    Run a pencil-and-paper RPG campaign with your far-off friends: Gametable!
  6. Re:Not just for linux though by titzandkunt · · Score: 5, Insightful


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

    --
    Political language ... is designed to make lies sound truthful and murder respectable...
  7. But it's such a bitch to install... by Karora · · Score: 4, Insightful

    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.

    --

    ...heellpppp! I've been captured by little green penguins!
  8. Re:Exactly - Java is not about the O/S by Taladar · · Score: 3, Insightful

    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.

  9. Re:How many projects? by Taladar · · Score: 5, Insightful

    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.

  10. Re:C/C++, not java by angel'o'sphere · · Score: 4, Insightful

    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

    --
    Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
  11. Re:C/C++, not java by sniggly · · Score: 3, Insightful

    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.

    --
    Of those to whom much is given, much is required.
  12. Re:Exactly - Java is not about the O/S by angel'o'sphere · · Score: 4, Insightful

    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

    --
    Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
  13. Re:Exactly - Java is not about the O/S by martin-boundary · · Score: 3, Insightful
    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.

  14. yeah, look at all the forks of perl/python, etc. by Xtifr · · Score: 4, Insightful

    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!

  15. Ease of use sometimes requires minimizing features by NeoBeans · · Score: 5, Insightful
    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

  16. In the *enterprise*? by elemur · · Score: 5, Insightful

    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.

  17. Re:Exactly - Java is not about the O/S by TRACK-YOUR-POSITION · · Score: 4, Insightful
    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.

  18. Re:C/C++, not java by johannesg · · Score: 3, Insightful
    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 ;-)

  19. nearly none by dekeji · · Score: 3, Insightful

    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.

  20. Re:Not just for linux though by iabervon · · Score: 4, Insightful

    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.

  21. Re:Exactly - Java is not about the O/S by jeremyp · · Score: 3, Insightful

    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.

    --
    All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe