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

12 of 601 comments (clear)

  1. Not just for linux though by WebMasterP · · Score: 5, Informative

    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.

    1. 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...
  2. Incredible, indeed by Anonymous Coward · · Score: 5, Informative

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

  3. Re:C/C++, not java by Pieroxy · · Score: 5, Informative

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

  4. I know what he means by arvindn · · Score: 5, Funny

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

  5. How many projects? by Simon+(S2) · · Score: 5, Informative

    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.

    --
    I just don't trust anything that bleeds for five days and doesn't die.
    1. 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.

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

  7. Exactly - Java is not about the O/S by msobkow · · Score: 5, Interesting

    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.

    --
    I do not fail; I succeed at finding out what does not work.
  8. Re:Yes at least in Apache world by wario78 · · Score: 5, Informative
    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

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

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