Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Take advantage of Black Friday with 15% off sitewide with coupon code "BLACKFRIDAY" on Slashdot Deals (some exclusions apply)". ×
Java Programming

The Future of Java? 624

Todd AvErth writes "Judge Motz recently ordered Microsoft to distribute Sun's JVM with every Windows product. Salon decided to pipe up about it with an editorial musing about whether or not it's too late. Most of it isn't all that interesting, but some of the comments from Ximian developer, Miguel de Icaza point to the advantage of being able to compile from multiple languages. Anyone know of any projects to compile JVM bytecode from other languages?" Update: 01/23 16:00 GMT by M : Comments were disallowed when this story was originally posted; fixed now. My mistake (although KDE3's stupid mouseover-activates-form-elements user interface, now finally fixed in the latest versions, has to take some blame too).
This discussion has been archived. No new comments can be posted.

The Future of Java?

Comments Filter:
  • by The Wookie (31006) on Thursday January 23, 2003 @11:01AM (#5143340)
    can be found here [].

    It doesn't mention SmartEiffel, though, which does generate byte codes. There are probably many others as well.
    • So where are the processors that Sun promissed that would run Java bytecode natively?
      • I thought Sun said it was possible, they never promised this. If you have a link where Sun is saying this WILL happen I'd be most interested.
        • Yes they did... (Score:3, Insightful)

          by lseltzer (311306)
          There was a whole spec for it, picoJava I think, and I believe they even got to preliminary discussions of products. But language-specific processors have always been losers and this was always a stupid idea.
          • Re:Yes they did... (Score:3, Interesting)

            by sketerpot (454020)
            But language-specific processors have always been losers and this was always a stupid idea.

            I think that it's important to draw a distinction between the Java language and the Java bytecode. The language, IMHO, isn't very good; I much prefer Python [], or if I'm developing for the Java platform, Jython []. But Java is a form of bytecode that can be compiled to from all sorts of languages, so programs compiled for picoJava cold also be run transparently on many other OSes. Although I think that JIT compilers and Hotswap optimization have made this less important, it still might be nice to have a processor that could run Java bytecode natively.

            Still, I'm not too enthusiastic about it.

      • by borkbork (30290) on Thursday January 23, 2003 @11:44AM (#5143711)
        The page you list shows a hundred or so that run on the JVM. A similar page [] for .NET shows only 27.

        Not what the marketing folks at Microsoft would have you believe, huh?
      • by malachid69 (306291) on Thursday January 23, 2003 @11:47AM (#5143735) Homepage
        I own two. I have the TINI board ( and the PTSC chip (

        Also, it is very common on handhelds and cell phones. My Handspring has Sun's JDK and IBM's JDK on it, as well as Java3D.

        Personally, I am still debating making my own PDA using an open-core java chip and OLED touchscreen.

      • They'll probably be released right around the same time that we're all wearing those Java rings that Chompers McNealy always used to talk about.

      • So where are the processors that Sun promissed that would run Java bytecode natively?

        There was a lot of talk about this in the various Java newsgroups in the mid-to-late '90s (here [] is a typical thread on the subject). From what I remember, Sun originally thought that specialized Java processors, or even coprocessors on a daughterboard, might be a good idea. But, because the Java VM is a stack-based machine, implementing it in silicon turned out to be harder than expected, for less benefit than was hoped. I think they ultimately decided that it would be more cost effective to improve the JIT than to develop a Java CPU.

        I don't have any hard data or links to back any of this up, it's just what I remember.

        • I suspect they concluded that there was no market for it. That's the real reason they were so upset with MS. By allowing more direct access to Windows then what "pure" Java allows, MS made hardware acceleration unnecessary on the dominant desktop platform.

          Thus their strategy:
          Sell Java's WORA capabilities
          Get everyone hooked on Java
          Release proprietary hardware accelerator for completive performance

          has failed.
      • by lgraba (34653) on Thursday January 23, 2003 @12:04PM (#5143858)
        Here are a few of the more notable Java Processors ones: (and has a few boards built witht the processors).

        Also, the Jazelle technology from ARM embeds a java processor section into an ARM chip:

      • I always thought that this would be a good application of Transmeta's "Code Morphing" technology []. If it can provide an x86 translation layer then I would think java would be an obvious next step, and all (most?) of their optimization techniques would still apply. Of course, if that were true they probably would have done it already, so I must be missing something.
    • I'd be more interested in the other way around - systems to compiled Java code into X86 bytecode. I like Java as a language, but I hate the sluggish speed and never use non-X86 chipsets anyways.
    • by namespan (225296) <namespan@elitemail.PERIODorg minus punct> on Thursday January 23, 2003 @02:21PM (#5145032) Journal
      Languages for the Java VM...can be found here...

      And that page has been up for at least 4 years, and comes up top on the Google search [] "Languages for the Java VM." So I think the real question is: why does the meme that Java bytecode can only be generated from javacc continue? Even if you regard most of the things on that page as academic, they're at very least proof-of-concept (and ad naseum at that, due to sheer numbers). Not to mention what the presence of clearly non- academic implementations like Jython.

      I don't know whether or not Sun intended to design Java so that this was possible or easy. But it seems pretty obvious to me: you can target a VM as easily as you can target a processor, and that's what any compiler does. Why doesn't the Java-only for Java-VM meme die?
    • by Corvus9 (300802) on Thursday January 23, 2003 @05:43PM (#5146651)
      ... can be found
      here []
      Many posters mention this page. In fact, I have spoken with other Java advocates who mention this page as proof the JVM is language-neutral. However, they do not mention that most of the "languages" on this page are Java interpreters or code generators, and nearly all the remainder are vapourware or proposals, not actual shipping products.

      Rogers Sessions took the time to investigate every single one of the projects on the JVM languages page. He posted his results to the ObjectWatch [] site. After long research, he found only 8 that were actual implementations of a non-Java programming language for the JVM. Of those 8, in his opinion not one was available or suitable for professional development.

      In his conclusion he states "I believe that Simon Phipps and other Sun luminaries have greatly exaggerated the degree of language neutrality supported by the Java platform".

      • by miniver (1839) on Thursday January 23, 2003 @10:22PM (#5148335) Homepage
        Rogers Sessions took the time to investigate every single one of the projects on the JVM languages page. He posted his results to the ObjectWatch [] site. After long research, he found only 8 that were actual implementations of a non-Java programming language for the JVM. Of those 8, in his opinion not one was available or suitable for professional development.

        Roger Sessions ... now there's an unbiased observer. Once upon a time, Roger was a CORBA spec writer, until he basically got booed out of the CORBA camp for non-performance (this spec is going to be SO good when it's finished ... really!) Then he became a COM/DCOM/COM+ apologist for Microsoft. Read through his ObjectWatch newsletters and see if you can spot any unbiased commentary on technologies; you will quickly observe a trend: Microsoft good, non-Microsoft bad. I won't say that Roger is a complete bought-and-paid-for Microsoft shill, but he gets his books published by Microsoft Press... you draw your own conclusions.

        As for the JVM's language-neutrality (or lack thereof): so what, big deal.

        There is no such thing as a language-neutral platform, be it hardware or virtual. Every computer instruction set that has been developed to date has had biases built in; it's inevitable. The system designer has certain goals, and usually has a target set of capabilities, which may only work in assembly language. Take the X86 instruction set: only a fraction of the X86 instructions are useful to a C compiler. The rest of the instructions can only be used by writing assembly language. The only hardware instruction sets that I can think of that are completely accessible by a higher level language are those that were specifically designed to implement a single language (Forth, LISP), and they make lousy targets for other languages.

        The question is: does it matter? There are very good reasons why the JVM doesn't allow pointer arithmetic and pointer casting: the designers wanted a provably secure runtime environment, so they excluded unsafe operations. So you can't implement C/C++ for the JVM; big deal. If you really need those capabilities, you're better off operating outside of the JVM and interacting via JNI or some form of RPC. That said, there are still plenty of languages that are written in Java, compile to Java, or compile directly to Java bytecodes; certainly more than currently target the .NET CLI or any other virtual machine. Use one of those, or write your own.

  • Ada (Score:3, Funny)

    by mgaiman (151782) on Thursday January 23, 2003 @11:03AM (#5143349) Homepage
    Ada has a bytecode generator. See here []

    So does that mean that my forced ada classes [] in college were useful?
  • Jython (Score:5, Informative)

    by russianspy (523929) on Thursday January 23, 2003 @11:03AM (#5143358) []

    Allows to write programs in python and compile into java bytecode. Access to awt for sure. I think there is also a port where you can write Tkinter applications in jython as well.
  • I've been waiting 10 minutes to make my stupid comment...

    If only APL [] could compile to Java ByteCode.....people still wouldn't use it.

  • Microsoft Appeal (Score:3, Informative)

    by the_Bionic_lemming (446569) on Thursday January 23, 2003 @11:05AM (#5143371)
    It's been . []
  • by smd4985 (203677) on Thursday January 23, 2003 @11:05AM (#5143374) Homepage
    I like the article, and I think it is easy to see that Java is going to continue to be a force.

    On the server side it has always been a great solution (great for building complex applications, no performance degradation with 'backend' code, and very stable and safe).

    On the client side, the MS/Sun ruling will be a huge boon to the applications side - of course developers will start building client side apps! "If the JVM is there, they will come" :) Sure Swing is a little sluggish, but when everyone is running a p4 2GHz, it really doesn't matter....

    • Sure Swing is a little sluggish, but when everyone is running a p4 2GHz, it really doesn't matter....

      At the rate of PC sales, I think it's gong to be quite some time before that happens.
    • by mooZENDog (567187) <> on Thursday January 23, 2003 @11:20AM (#5143513) Homepage
      I agree completely with your comments on the future of Java as a server side solution. JSP, servlets, and J2EE are all fantastic.

      Sure Swing is a little sluggish, but when everyone is running a p4 2GHz, it really doesn't matter....

      But it does matter, if other programming languages still run relatively faster than Java. I agree that it's not as clunky as it was a few years ago though... *shudder*

      Two things I feel you've left out are:
      1 - The embedded systems market. When I was at Uni this was being touted as the next best thing. I don't have any real statistics for you, but I'm sure Java is doing well in this field.
      2 - The mobile phone market. Pretty similar to my first point, the KVM (Kilobyte VM - a cut-down version of JVM) and related APIs in J2ME are a big player in the mobile phone business. The company I work for is developing mobile phone games, and Java has got the support of the handset manufacturers, which will give it superiority over other technologies that havn't had as good an uptake.
    • by (443482) on Thursday January 23, 2003 @11:48AM (#5143738)

      And, there should be no lack of new software because, as the article says, "Sun estimates there are about 3 million Java developers."

      ...most of which are currently unemployed...

      • by FortKnox (169099) on Thursday January 23, 2003 @11:58AM (#5143808) Homepage Journal
        ...most of which are currently unemployed...

        Perhaps you haven't looked at the market.

        Go to some job site (dice, monster, etc...). Look for C jobs, then C++ jobs, then perl jobs, then Java jobs.
        Java has been a constant hire (even during the worst parts of the IT recession). Anyone with decent Java skills can find a job, no problem.
    • by (637314) on Thursday January 23, 2003 @11:48AM (#5143743) Homepage Journal
      Will they start building client side applications? The current trend in management interfaces is for web-based interfaces with as little need for plug-ins as possible. In other words, HTML and JavaScript. Cisco has an ASP based management system on their call managers. I see many perl/PHP based management applications. Huge banks have J2EE/JSP pages on their sites.

      I've heard time and time again from developers that applets are toys, the true reason to use Java is on the [large] server side.

      Have you ever used the Zend Development Environment for PHP? It's java and doesn't feel as professional as say Dreamweaver, MS Word or standard client side applications.

  • Google Search (Score:5, Informative)

    by jaaron (551839) on Thursday January 23, 2003 @11:05AM (#5143377) Homepage
    Well now that I can finally post...

    Here's [] a nice list of languages that work within the Java VM. I'd like to point out that its a very long list.

    Also, Java on the desktop has always had issues. Everytime someone brings up the "future" of java, they tend to forget that Java's current strength is on the server side where the average user doesn't see it and doesn't know about it. Java's competition is .Net, PHP, and Python (Zope) on the server.
  • GCC? (Score:3, Interesting)

    by mmol_6453 (231450) <<moc.tenrg.liam> <ta> <tiucric.trohs>> on Thursday January 23, 2003 @11:05AM (#5143379) Homepage Journal
    Wasn't there work a while back that would allow you to mix and match gcc language modules with target architecture modules? What ever happened to that?
    • Re:GCC? (Score:5, Interesting)

      by ntijerino (306851) on Thursday January 23, 2003 @11:32AM (#5143627)
      GNU has gcj ( which is pretty cool, if not complete. Compiling java into native seems like a better idea than compiling other languages into byte code. Even if you did compile other languages into bytecode, you could then use gcj to compile that bytecode into native, so I guess it all just works.
  • by utahjazz (177190) on Thursday January 23, 2003 @11:06AM (#5143382)
    The Salon article has a link to a Language popularity study [], which points out Java is the most popular, but C# is the fastest growing.

    I find it more fascinating that Perl is growing faster than PHP. I dig Perl, but I keep thinking I need to get on this PHP bandwagon. Apparently, it's not much of a bandwagon.
    • by Sircus (16869) on Thursday January 23, 2003 @11:42AM (#5143691) Homepage
      If I start with 100,000 users and grow to 200,000 users, I grow 100%. If I start with 10 users and grow to 100, I've grown 900%. "Fastest-growing" doesn't often mean a lot. Anything that starts with 0 users and has anything more than 0 users a year later can by definition say "No language is faster-growing than us!" since they have infinite growth...
  • Java? Future? (Score:5, Interesting)

    by FortKnox (169099) on Thursday January 23, 2003 @11:06AM (#5143387) Homepage Journal
    This really perterbs me. Java's future wasn't in question when MS refused to put the JVM into the OS. Java has been successful in the IT industry THROUGH the major drought the IT industry has had.

    I work as a J2EE consultant (and consulting has taken the brunt of the recession in the IT industry) and my job has not been in danger at all. J2EE is still one of the choice languages for large, complex, dynamic websites.

    Most people that think its in question either do a "I haven't seen an applet/swing app in a while, so Java must be dying", or a "I heard about java in the past, but not recently so it must be dying". This is almost as sad as the "*BSD is dying troll"

    I also have one side note about my sig. For those that haven't tried to comment in when the story was posted, it was posted as a new 'friends only' post for a good 20 minutes (and note, michael has no friends marked, so no one could post). This just adds to my frustration that slashdot is immature when it comes to its software lifecycle. Where's the testing build (or testing at all, for that matter)? Where's the notification when changes are coming? Shouldn't the audience know when new features are added (so at least we can test them, or can be on the watchout for bugs)?
  • by HaiLHaiL (250648) on Thursday January 23, 2003 @11:06AM (#5143388) Homepage
    Although there are many other languages which can compile into Java bytecode (as several posters have pointed out), who would want to use multiple languages in an organization?

    I mean, imagine managing a project in 5 different languages. It creates major HR and logistical issues. COBOL.NET? Gimme a break.
    • by JohnFluxx (413620) on Thursday January 23, 2003 @12:17PM (#5143975)
      Many programs have lots of different languages.
      There was a game written in perl and C - perl for most of the game for garbage collection, bounds checking, etc. and C for the low level graphics to make it fast.

      Many more programs mix a really low level, low level and high level language. Games mix asm, C/C++, and lisp/prolog/made-up language. Intranets often have a mix of a javascript, java, C and some high level pure functional language (that would be like SML or Haskell) (Like lotus domino has - forget what it's called.)

      Being able to mix languages is a wonderful thing. :)
  • Tons (Score:3, Informative)

    by Tony.Tang (164961) <(gro.nh.keels) (ta) (todhsals)> on Thursday January 23, 2003 @11:07AM (#5143391) Homepage Journal
    There exist a whole pile of compilers for different languages that compile down to java bytecode.

    This page [] links to a whole whack of projects.

    To give a smattering: Forth, Ruby, Cobol, Eiffel, Prolog, Basic, Lisp, Tcl.

  • by gidds (56397) <> on Thursday January 23, 2003 @11:07AM (#5143393) Homepage
    Anyone know of any projects to compile JVM bytecode from other languages?

    This page [] lists over 150...

  • Here's a link to the original ruling, as obtained from Sorry, Acrobat foes, but it's a .pdf. :( .pdf []

    I haven't read it yet (I hate Acrobat Reader and can't find an alternative on my Windows PC), but I wonder if the ruling specifies that is has to be a Sun Java VM. I mean, all the evidence points to Microsoft's Java VM (even sans "extensions") was faster and more stable than Sun's. Would a VM that conformed to the 1.4 API but written by Microsoft be allowable? What about other 3rd party VMs? They're usually superior to Sun's as well.

    • (I hate Acrobat Reader and can't find an alternative on my Windows PC)

      When I have to use Windows, I like to use GSView [], a GUI viewing application that works with Ghostscript []. Opens both PDF and PostScript documents.
  • Lets see.....

    Java c syntax
    C# c syntax

    Java VM byte code that gets compiled and executed on the fly .NET VM IL code that gets compiled and executed executed on the fly

    Java single inheritance model
    C# single inheritance model

    Java interfaces
    C# interfaces

    Ahh.... If it walks like a duck, quakes like a duck and tastes like a duck, then it is a DUCK!

    These arguments that .NET allows "other" languages, is pure BS. Does .NET allow IL like C++? NOPE! But so long as the language behaves like C# everything possible. Well gee DUH! The same goes in the Java world.

    I like C# and I like Java, but lets leave it that they are the same darn thing! Except one was created to compete against the other!
    • Re:A duck (Score:3, Insightful)

      by The Bungi (221687)
      These arguments that .NET allows "other" languages, is pure BS. Does .NET allow IL like C++? NOPE!

      I don't think you understand what IL is. It's not bytecode, at least not in the Java sense. You can certainly write an front-end compiler to generate IL from C++ or Haskell or Scheme or FORTRAN or whatever you want. In fact, VC++ 7 does precisely that if you use the managed C++ extensions to write .NET assemblies instead of normal PE binaries.

      Further, IL is not C# specific - the notion that a language has to "behave like C#" to function within the .NET CLI/CLR is laughable at best and FUD-ish at worst. It is completely language agnostic. As a matter of fact, you can write entire .NET assemblies using nothing but IL - sorta like writing GUI applications in ASM. Not that you would *want* to do that, but at least you *can*. IL is fully documented.

      There are a few good books by Wrox, O'Reilly and MS Press that deal exclusively with IL - I'd suggest you give at least one a cursory look before posting things like these.

    • Re:A duck (Score:3, Flamebait)

      by Zeinfeld (263942)
      These arguments that .NET allows "other" languages, is pure BS. Does .NET allow IL like C++? NOPE! But so long as the language behaves like C# everything possible. Well gee DUH! The same goes in the Java world.

      That is pure bull shit, C++ is sufficiently screwed up that nobody can get it to run in managed code. However Microsoft have got pretty much every other language - Basic, Python, Eifel, Cobol, Perl, Scheme etc. to run. So the claim that .NET is language neutral is not disproved by choosing the single contrary data point that Microsoft themselves make no effort to hide. The only major languages that don't run are Common Lisp and C++, both of which have multiple inheritance which language design has been backing off from for years.

      As for C# 'copying' single inheritance from Java, COM had single inheritance from the get go. I would be very surprised if Microsoft didn't have coding rules that prohibit using multiple inheritance and compiler flags to disable it for internal use. Every large software house that tried C++ in the early days discovered that multiple inheritance led to disaster. The programs could only be understood by their original authors.

      C# borrows some stuff from Java but it borrows rather more from objective C. It also has meta-data tagging which if you know how to use it is massively useful.

      Sure C# could have been an evolution of Java in the same way that Java was an evolution of C. The only reason it wasn't was Sun's decision to insist on full control of Java and sicking lawyers on Microsoft for wanting to use it to do other things.

      Sun has repeatedly promised to make Java open and every time it has reneged. The Java Community Process was created to ensure that Sun kept control of Java, it is not an open standards process in any meaningful sense of the term. Sun retain effective control over every aspect of Java language design. The JCP is independent in the same way Vichy France was independent of Germany.

      What Microsoft wanted to do was to use Java as a replacement for C++. To do that they had to have a bunch of stuff that Java didn't have so they added it. That is how every language prior to Java has evolved. For years the standard for Fortran was VAX Fortran.

      Sun's hardware business is collapsing under pressure from low cost Linux on Intel boxes. They have failled to make any money from Java, execept by using it to drive sales of their hardware boxes to dotcoms when those still existed. If you think the SCO/Unix situation is bad just wait a few years until Sun has gone the way of SGI and their lawyers are looking to extract whatever value they can from their 'Intellectual Property'.

      • Re:A duck (Score:3, Informative)

        by AMK (3114)
        However Microsoft have got pretty much every other language - Basic, Python, Eifel, Cobol, Perl, Scheme etc. to run.
        Um, that's not true. The Python .NET work [] was an experimental effort that was incomplete, impractically slow, was never used for production work by anyone, and is no longer being developed or maintained. Perl.NET takes the existing C Perl interpreter and interfaces it so you can write .NET components, but Perl isn't being translated to CIL. The only Scheme compiler I can find [] implements a subset that doesn't support continuations.

        I don't know why no one has called Miguel on his claim that you have to translate everything to Java, but .NET provides a happy shiny world where all of the languages are well-supported. Clearly that's untrue.

  • Languages Using JVM [] covers :
    • Scripting Languages for Java
    • Interactive Languages
    • Non-interactive Languages
    The google search JVM languages [] turned up a ton of stuff. Jython [] seems to be the most popular scripting lang for the JVM. -Peace
  • Apple Cocoa (Score:5, Informative)

    by MouseR (3264) on Thursday January 23, 2003 @11:07AM (#5143399) Homepage
    Apple's Cocoa framework, based on Objective-C, has all been exposed to Java.

    Both languages share so much of the same concepts that both languages can call in each other, allowing a project to be composed of both Obj-C and java.

    Given Apple's recent extensions to Obj-C, the so-called Objective-C++, you can actually mix C, C++ and Obj-C source code in the same file and interchangeably make cals to and from C++ classes and obj-C classes. Then, calling Java is nearly as trivial.

    These changes are finding their way back into the GCC compiler, which is the standard compiler for the Project builder environment.
  • by zaqattack911 (532040) on Thursday January 23, 2003 @11:07AM (#5143403) Journal
    I think it is important to make this distinction. Don't fall victim to Salon's BS. Granted they have a talented team, and they are good writers. But so help me I am sick an tired of their political twist on everything, and their constantly playing devils advocate on every topic. The more leftist they get.. the more they alienate many of their readers.

    Heh.. ok now that my rant is over...
    What if Sun goes under? This could be a good thing. What if the java platform became GPL ? I think this is an important distinction to make.

    Perhaps the only thing holding back the Java platform is sun holding onto it.

    I have nothing to say about .NET :)

    • What if the java platform became GPL ? I think this is an important distinction to make.

      If the entirety of Java were placed under the GPL, including all of the Java API libraries, it would KILL Java because it would mean that virtually every Java program distributed would have to be released under the GPL as well. Even if you think this is a good thing, most businesses wouldn't. They'd run screaming from Java.

      This is exactly why the runtime .NET APIs under Mono aren't GPL.. Only the tools themselves are.

      • No it wouldn't. Does Emacs being GPL'd mean that everything you write in Emacs being GPL'd?
      • ... ava were placed under the GPL, ...virtually every Java program distributed would have to be released under the GPL as well.

        Oh, FUD and nonsense. Perl is GPL, and nobody has even hinted that this means that perl programs must be GPL'd. Tcl and TK and GPL, and the same applies. If you bother to read the GPL, you'll find language that explicitly covers things like libraries (which is what the JVM amounts to), and it is made clear that GPL licensing for libraries doesn't extent to things that use the libraries.

        Methinks people are falling for Microsoft's anti-GPL propaganda.

        Actually, this isn't a frivolous worry. I worked on projects at several companies, including Digital, where the lawyers advised strongly against basing any products on Sys/V or any ATT libraries. They thought that ATT's licensing did imply that if you linked to ATT's libc.a, then ATT could claim to own your software. The story seemed to be that the lawyers thought this could be challenged in court, and you'd probably win, but if ATT wanted to press the issue, it could cost you a decade and a billion dollars to get the case decided. Better to go with BSD or OSF or roll your own (or now use linux), and be safe.

        This was widely believed at Digital to be the primary reason they went with other kinds of unix. It was much of the reason that the BSD gang decided to eliminate ATT code from their system. It was also a serious concern among the GNU people, which is why they explicitly address the issue in the GPL.

  • Jython (Score:5, Informative)

    by dbarry (458863) on Thursday January 23, 2003 @11:07AM (#5143405)
    Anyone know of any projects to compile JVM bytecode from other languages?

    Jython []
    # Dynamic compilation to Java bytecodes - leads to highest possible performance without sacrificing interactivity.
    # Ability to extend existing Java classes in Jython - allows effective use of abstract classes.
    # Optional static compilation - allows creation of applets, servlets, beans, ...
    # Bean Properties - make use of Java packages much easier.
    # Python Language - combines remarkable power with very clear syntax. It also supports a full object-oriented programming model which makes it a natural fit for Java's OO design.
  • I Think... (Score:4, Funny)

    by FireChipmunk (447917) <> on Thursday January 23, 2003 @11:08AM (#5143415) Homepage
    I Think Sun are really a huge problem
    I Think Garbage Collections are too much on my mind
    I Think dumps have got a lot to do with why the world sucks
    But what can you do?

    Like a red rain, beating down on me
    Like a Linus line, which won't let go of my brain
    Like C#'s ass, it is in my head
    Blame it on java
    Blame it on java
    Blame it on java

    I Think slows are gonna drive us all crazy
    And write once, run anywheres make me feel like a child
    I Think crapyness will eventually be the downfall of civilization
    But what can you do? I said what can you do?

    Like a red rain, beating down on me
    Like a Linus line, which won't let go of my brain
    Like C#'s ass, it is in my head
    Blame it on java
    Blame it on java
    Blame it on java

    Like a red rain, beating down on me
    Like C#'s smile, cruel and cold
    Like Linus's ass, it is in my head
    Blame it on java
    Blame it on java
    Blame it on java
  • I think that processors were too slow for widespread adoption of some killer apps. MS killing it for a few years was a great thing for Java. Now, I can program my multi-platform apps to my heart's content and not have to worry about run-time load speeds (well... for dial-up...).
  • by (637314) on Thursday January 23, 2003 @11:10AM (#5143429) Homepage Journal
    when you think about it, MS is really trying to kill java... and in more ways than just the JVM stuff. If you ever visit the MSDN, you might see many items for converting your java code to C#, reasons to use C#.

    Take away the business side, what are the advantages of using java versus C#? Looking at Mono it seems to marry both technologies -- correct me if I'm wrong, but they want to compile both.
    • by Simon Brooke (45012) <> on Thursday January 23, 2003 @11:31AM (#5143612) Homepage Journal
      Take away the business side, what are the advantages of using java versus C#? Looking at Mono it seems to marry both technologies -- correct me if I'm wrong, but they want to compile both.

      I'm prepeared to bet a great deal (well, my career, in fact) that Mono will never reliably run .NET applications produced by Microsoft (or indeed by other people using Microsoft tools). If you write for the JVM, you will have a reliable ful-featured runtime both on Sun platforms and on platforms which compete with Sun platforms. We know this from Sun's historic behaviour: Java runs extremely well both on Linux and on IBM RS/6000 boxes. If you write for .NET, you will never have a reliable, full featured run time on any platform which Microsoft sees as a serious competitor. We know this, too, from Microsoft's historical behaviour. The leopard has not changed its spots.

      • by gorilla (36491) on Thursday January 23, 2003 @12:18PM (#5143981)
        I'd be prepared to bet that Mono running .NET will never reach the reliability & security given by Java on Unix/Linux at that same point in time. Microsoft has always had a model of putting software onto the market, then fixing it 5 or 6 revisions down the road. This was acceptable when products were isolated, however in a system where related interactions occur, this means that you never really get a truely stable environment.
  • Not worth the effort for a whole new story, but MS is appealling the judge's decision in the MS vs Sun case, reported by Cnet []. MS claims that the injuction (Remember, the case has yet to be settled; the judge, though, deemed that Sun may be victorious in the case, and thus ordered the inclusion of Java as part of the injunction for Sun) would "inflict serious harm" in the various Windows products it would need to include Java in.
  • In reality, most OO languages or languages that can support an OO paradigm can be compiled into JVM byte code. Several projects support that notion. I know, for example, that Python can be compiled to JVM byte code.

    You do not, however, see a lot of demand for this. The reason is simple. Organizations do not want the complexity of managing dozens of programming languages. Ideally, they would like to hire only Java or only C# developers and have those developers be able to manage all of their code.

    In the real world, of course, companies have an existing investment in multiple languages. They have old COBOL, VB, C++, C, etc. systems to maintain. This fact is used by the C# crowd as an argument for the need for a multi-language VM (which Java is in spite of their arguments to the contrary). In reality, however, it would be foolish to take a working, monolithic COBOL system and stick it in a .NET runtime environment. That's a lot of work for little benefit.

    It is a much better design practice to build a facade around that system and enable interaction through that facade. When people do this, they do not end up "throwing out their investment" as Miguel suggests. They instead empower themselves to retain the investment as long as it makes sense and replace it it makes sense.

    In other words, I am saying that, all else being equal, even for .NET people support for multiple languages will prove to be a non-feature. If it were, people would be using that feature of the Java platform. I know that .NET advocates make the claim that .NET bytecode better supports multiple languages. It is true that it is marginally better. Nevertheless, it still carries a bias towards C#. In other words, languages a lot like C# will be supported easily and languages much unlike C# will be harder.

    • It's true... managers aren't interested in all the fancy technical feets that can be accomplished. The bottom line is they want to make money, and certain buzz words will move them towards different technologies. Java, .NET, both buzzwords. My guess is that a lack of knowledge in both will yield a 'who cares, just do the work' attitude. If they have a background in one, they will probably be slanted in that direction.

    • What exactly is there in Java that allows one to build "complex applications"? I hear that from Java and OO fans all the time

      They also have Perl and shell scripts for scripting, Tk for tool interfaces, Expect for testing and automated interactions... and on down the line. Hiring someone to primarily code in C++, or Java or whatever is acceptable if the product is in a particular language, but if the potential employee sits in front of me with only that language to his credit he's not getting the job. The ability to use the right tool for the job is the most important aspect of being able to code.

  • by Spencerian (465343) on Thursday January 23, 2003 @11:12AM (#5143446) Homepage Journal
    It's never been too late for Java, any more than its too late for other less popular but powerful languages. Just because Perl is around doesn't make TK, or AppleScript, or Python any less useful, for instance.

    I've found that Java is great for complex applications that need cross-platform ability when programmers can't spend too much time in making that compatibility happen. Mac OS X is among the strongest Java clients around, and it shows every time I download a raw JAR and just use it. YMMV, but Java has a lot of warmth left in its cup, and, if other platforms aside from MS continue to support, we'll all get free refills.

    (Sorry for the many metaphors. Haven't had my cup of coffee this morning--ack, I did it again...)
    • by GroundBounce (20126) on Thursday January 23, 2003 @01:32PM (#5144639)
      Your point about speed of development is a very good one.

      I am currently developing a custom database and data collection package that MUST run both on Linux and Windows 2000. As well as the intrinsic functionality, it has a significant GUI component as well. Equally important, I don't have a lot of time to get it done. I considered many options, including C/C++ with QT, vxWindows, GTK and other "cross platform" toolkits, perl, and others. In the end, Java won the day for several reasons:

      1. Java plus Swing is the closest to truly cross platform of all of the options. I have written around 6000 lines of code so far and less than a dozen have to be changed to account for differences between Windows and Linux, even though the program does some relatively low-level things like directly accessing modems through serial ports. In addition, the Swing GUI looks EXACTLY the same on all platforms. GUI toolkits which try to give you "native" L&Fs often need tweaking between platforms to look good. Once you get a Swing GUI looking good on one platform, you're done.

      2. Java has an extremely complete and easy to use interface to SQL DBMSs (JDBC) which works the same on all platforms.

      3. Sun's online documentation is very complete and easy to use (this can be a big plus with speed is important).

      3. The higher level nature of Java compared to C/C++ (e.g., automatic memory management, better runtime checking) make for extremely quick debugging. I am achieving operational code with many fewer iterations than I ever did with C/C++. Java may be slightly slower than C++ because of these features, but this particular program is not pushing the performance envelope, so the faster development time is much more valuable.

      This is the first sizable project I have programmed in Java, and overall I'm very happy with the results so far. A year ago, that's something I'd never have guessed I'd be saying.
  • We have an OEM who delivers certain applications to us that are developed in Java. These are ordinary-looking, double-clickable Windows and Mac applications. What can I say? There's nothing TERRIBLY wrong with them, but they're slow to start up, clunky-feeling, sometimes don't refresh the screen properly, have various minor UI inconsistencies with the underlying platform, and so on. They simply do not look or feel like first-class native applications.

    Yes, yes, yes, I know that theoretically these problems could all be solved, and that no doubt it's because they're not using version the latest version X.0165 of Java GUI technology flavor Y... and it's all Microsoft's fault... and so forth... ...but, still, in practice the actual cross-platform Java applications I've seen are very unimpressive and are not good advertisements for Java as a cross-platform GUI development methodology.

    And I still experience a feeling of dread whenever I go to a web page and see "Applet loading..."
  • by ShatteredDream (636520) on Thursday January 23, 2003 @11:14AM (#5143462) Homepage
    My first two programming classes were in Java. I really think we would have had more fun learning the same concepts in Python. The thing that I've come to love the most about Python is that it doesn't force you to build an entire class just to test a feature. It's a great language to encourage CS students do their own experimenting with.

    I'm personally ambivalent to Java. I like it for some things, but the only real reason I want to learn it is because so many use it. I just recently discovered wxPython and think it's probably easier for me than Swing or AWT.

    The best thing that could come from Java for development as a whole IMO is Javadoc. If that tool were extended to support C++, C#, VB.NET, Python, PERL, etc it would make everyone's lives easier. Seriously, has anyone seen better documentation than Sun's Javadocs from something so big and complex as Java's libraries?

    I'm really excited about Mono because I really like VB.NET and C#. I think the ability to use any language you want with the same libraries is a very important strength that .NET has over Java. I know there are other languages that __can__ targe the JVM, but Sun doesn't exactly seem to be pushing that. I'll never understand why though. Java could be made into their platform's equivalent of C# and they could develop their own clone of VB for Java. Hmmmm VB-J? It'd be great if they'd build VB and ObjectPascal compilers that target the JVM.
  • by Anonymous Coward
    But de Icaza disputes such claims. "There's a lot of crack being smoked," he said. "I'm going to tell you what it is -- there are very very very hard parts in .Net, extremely hard parts to do, and those are the things that got standardized. The binary file formats for .Net applications, that got standardized. Everything else that was easy didn't get standardized, but the important parts did."

    Please tell us miguel how *easy* it is to port Windows Forms to wine (which is floundering) or how *easy* it is to port all of the web services/ to Mono? Time to face the music, Mono/.NET will never be a cross-platform solution unless the application developer chooses to cripple/contort herself and her code.

    And when Microsoft comes down like a ton of bricks with all the patents on _NON_ECMA_ stuff you guys are doing then what will you do? How hard will it be to explain to all Ximian's customers that the next great version of Evolution will be delayed because Ximian put in a bunch of ADO.NET cruft and now has to rip it out because Microsoft wields the patent club against an Outlook competitor.

    Now multiply this scenario by the size of Miguel's ego and you might begin to understand what a catastrophe this could be for FOSS. Miguel is a _weasel_ and he is star struck with Microsoft and hell bent on duplicating all the API's (for god knows what reason).

    It is time for the Free Software company to recognize miguel for what he is ... a slimy underhanded guy who would like nothing better than to get desktop linux addicted to these non-ecma Microsoft API's with the irrational belief that Microsoft won't hurt him cuz he has befriended the MS.NET developers.
  • Universities (Score:5, Interesting)

    by SnAzBaZ (572456) on Thursday January 23, 2003 @11:14AM (#5143472) Homepage
    I think Java's future can only get better, not because of the recent ruling against Microsoft - which to be honest I don't think is all that important. Rather, the fact that all the universities (at least over here in the UK) seem to be adopting Java as their main language for Computer Science and related courses. It won't be long before a whole generation of enthusiastic Java coders emerges.

    Another issue is that as linux becomes more widely used, code that can easily be run on multiple os's becomes far more valuable. And developers may turn to Java for this reason, especially with all the cheap, fast, hardware we're all running nowadays where speed and efficiency arn't as important as they used to be in many situations.
  • They failed to mention the biggest advantage to using Java - a company can develop a front to back end solution completely using Java. Admittedly, this should be achievable using C# now, but I think this is what companies are interested in rather than any cross platform abilities of the code.

    Also, it always irritates me when they ask only the most biased people imaginable whether such-and-such a technology is going to survive. It's like asking the Pope and the Ayatollah which is the best religion...and leaves us no clearer as to what is really going to happen...
  • perljvm (Score:3, Interesting)

    by tommck (69750) on Thursday January 23, 2003 @11:17AM (#5143494) Homepage
    Brad Kuhn's project, perljvm has been around for a long time. (Yes, that [] Brad Kuhn [])

    And, coincidentally, I went to college with him, so I have to give him a plug :-)


  • by cwills (200262) on Thursday January 23, 2003 @11:18AM (#5143503)
    Well, not quite two (1 1/2 maybe :)

    NetRexx "compiles" down to java bytecode, but it does it by compiling into java first. NetRexx allows you to use any Java class.

    NetRexx was developed by the IBMer who developed the Rexx programming language. It has a fairly easy syntax, provides some very powerful/easy to use string parsing facilities.

    You can pick up a copy of NetRexx (available for download from

    The other language is Jcon which does compile directly to the javabyte code. Jcon is a "Java" implementation of the Icon Programming Language.

    To quote the website: Icon is a high-level, general-purpose programming language with a large repertoire of features for processing data structures and character strings. Icon is an imperative, procedural language with a syntax reminiscent of C and Pascal, but with semantics at a much higher level.

    If you poke around deep enough in the history of Perl, you will find references back to Icon.

    Details of Jcon (and download) can be found at the Icon home page at then follow the link to Java-based "Jcon".
  • Not really feasable (Score:3, Informative)

    by Temporal (96070) on Thursday January 23, 2003 @11:23AM (#5143551) Journal
    The Java virtual machine is very much designed around the Java programming language. I have heard about other languages being able to compile to it (isn't there an Ada -> JVM compiler?), but basically the language has to be lucky and use the same general feature set. Compiling C++ to the JVM would not be reasonably possible, since the JVM does not support raw pointers (for a good reason: if pointers were allowed, it would be impossible to verify that a Java applet was safe to run locally).

    Microsoft's CLR (common language runtime; part of .NET) defines a virtual machine which can run many languages, while posessing the verifiably secure properties of Java bytecode specifically for those languages which make such verifiability possible (basically, languages without raw pointers). If you want a VM that supports multiple languages, the CLR is really the best option right now.

    Personally, I am not convinced that such a common runtime is always an advantage. The CLR basically defines its own machine language, with all the basic instructions you'd see in any other assembly language. I don't like that approach because it is too low-level, and makes optimization harder. Allow me to explain...

    It is a rather common misconception that bytecode-compiled languages must necessarily be slower than native compiled languages. The opposite is actually true in many cases. If you are running your bytecode on some sort of interpreter, then yes, it will be slower, but typically bytecode is re-compiled to native code at runtime. When this happens, the compiler can perform all sorts of optimizations specific to the host machine, OS, and the exact library set in use, which would be impossible if the software were distributed as native code. Thus, the code actually ends up faster... in Java's case, it can approach the speed of C, which is surprising considering all the abstraction in the Java language -- based on the languages alone, you would expect Java to be much slower.

    Anyway, getting back to the point, higher level bytecode descriptions allow more optimization on the host machine. I am actually desiging a programming language right now, and my bytecode is only a little more than a parse tree. I like it that way. :)

    Just think of the language runtime like a library. Different programs use different libraries. What's wrong with that?
  • AspectJ (Score:3, Informative)

    by twisty (179219) on Thursday January 23, 2003 @11:24AM (#5143563) Homepage Journal
    The newest progression after object oriented programming seems to be Aspect Oriented programming. At the world famous Palo Alto Research Center, AspectJ was developed to compile AOP software into Java Bytecode. []

    Of course, it's not a true departure from Java... it even recommends that program filenames end in .java . It can compile java code, but not the other way around.

    • Re:AspectJ (Score:3, Informative)

      A better URL for all aspects ;-) of Aspect-Oriented Programming is this [].

      BTW, when compiling standard Java, the AspectJ compiler produces the same bytecodes that are produced by a standard Java compiler because the same compiler is used.

      The first incarnation of the compiler produced Java code that was then compiled by a standard Java compiler. The second produced bytecode directly, and the current version -- I believe -- uses a modified Eclipse compiler.

  • by jeremy_a (747) on Thursday January 23, 2003 @11:26AM (#5143579) Homepage
    I think people make a bigger deal of MS shipping Java than they should. Java on the client has been in pretty sad shape for a long time, yet Java's popularity has grown. It's used a lot for server-side applications, and apparently in embedded applications as well (although I'm not as familiar with that side of things). Whether or not MS ships a decent JVM on Windows doesn't change this -- Java will continue to be used just as it is today.

    Does it make a difference for Java on the client? Maybe. Although most of my Java work has been on the server side of things, I have written a couple of Java client apps as well. But those were for use inside the intranet, so it wasn't a big deal to require users to install a JVM. It certainly won't solve all of Java's client-side problems. Performance is much less of a problem than it was in the early JVMs, but most Java clients are still slower than their native counterparts. Perhaps more importantly, there are quite a few bugs in the GUI libraries (both Swing and AWT) that make it difficult to write highly polished applications. And with Swing you get problems with the look-and-feel not matching the native platform, which is a problem for some. But I think that part of the reason why these are still problems is because Java on the client hasn't really taken off -- maybe more of these issues will get solved if people start looking at Java as a valid client platform (because MS is shipping it with Windows) and start writing more client apps.

    But regardless of whether it makes a difference, I think the ruling does make sense. MS had a contract to provide a compatible JVM, and they didn't hold up their end of the contract. (At least that's my understanding -- I don't know the complete details of the contract.) Therefore they should have to make ammends -- maybe it is too late to "save Java" on the client, but it shouldn't hurt.
  • JVM plays rough (Score:4, Insightful)

    by varjag (415848) on Thursday January 23, 2003 @11:26AM (#5143580)
    Miguel de Icaza point to the advantage of being able to compile from multiple languages.

    As a person who've got a feel of writing JVM-targeted compilers, I'd like to notice that it makes extremely poor target for other languages. JVM was designed explicitly for Java, without any other language in mind. Thus, writing translators from other languages takes certain number of convoluted tricks.

    If your source language has closures, true lexical scoping, multimethods or multiple inheritance, JVM is clearly a suboptimal vehicle, unless you want to bend over a lot. From performance standpoint, its stack-oriented machine isn't optimal either. JVM architecture also leaves no easy ways to implement proper tail-recursion.

    CLR is likely a much better target, but even that one, designed for interoperability from scratch, has some rough edges for non-mainstream programming languages.
  • by samael (12612) <> on Thursday January 23, 2003 @11:31AM (#5143621) Homepage
    I know that multiple languages can compile to Java Bytecode.

    Can anyone tell me if one Java-compiling language can use objects written in another one?

    To me, this was a major advantage of .NET, and I'm wondering if Java can do it too.
  • by japhar81 (640163) on Thursday January 23, 2003 @11:40AM (#5143677)
    (although KDE3's stupid mouseover-activates-form-elements user interface, now finally fixed in the latest versions, has to take some blame too).

    Responses that are sure to follow:

    • Should have used GNOME
    • This was fixed 6 releases ago, upgrade from .0001 to .000009.
    • GUIs are for lusers, use the CLI
    • You should rewrite this in perl
    • You should rewrite this in COBOL
    • You should rewrite this in python running on top of a JVM inside a VMWare session of windows XP which is running inside a VMWare session of Minix.
  • by The Famous Brett Wat (12688) on Thursday January 23, 2003 @11:43AM (#5143707) Homepage Journal
    Slightly off-topic, but I'm in the process of perusing the job ads again, and based on the proliferation of J2EE/EJB and other Java stuff I'm seeing, I think that Java is the new COBOL. Not that the languages bear any similarity whatsoever, but Java seems to have found a niche as the new lingua franca of business apps. It has competition, to be sure, but based on the history of COBOL, I would be so bold as to put my pundit hat on and say, "Java programming will be a safe bet for long-term employment in the computing industry." The jobs aren't necessarily all that interesting, but they look a whole lot more secure than the bleeding edge tech jobs which come and go in a flash.

    The whole C# and .Net thing is a potential competitor in the same arena, but I don't think that Microsoft's inclusion (or not) of Java is going to matter much. I always figured that Java was intended to allow cross-platform desktop app programming, but the niche it seems to be filling is a back-end role. Personally, I had expected Perl to fill this role as the new COBOL, but demand for Perl seems to be way down, except as one of those "we also expect you to know Perl" type things, which never actually turns out to be important in the job.

  • by jamieo (22197) on Thursday January 23, 2003 @12:27PM (#5144046) Homepage

    Java has it's place, but if you come across someone with the opinion that Java is the be all and end all, avoid them.

    The very best thing about Java is the marketing hype Sun have managed to create. It's only Mac-o-philes who seem to be more obcessed (a Mac-Java geek is something to behold!).

    Java's a decent clean OO language, it's got a good set of standard/accessible powerful libraries, it's handling of libraries is good (compared to say C/C++), it's simple to learn the language basics and the GUI toolkit (swing) is reasonable.

    However for me Java has not delivered on it's promises. Performance generally is poor, compared to say Perl, and is dire when compared to C.

    Java also failed to deliver it's platform independence - you just get so many problems running on different platforms and different VMs. Compare this to say Perl - if you avoid platform specifics, Perl just works. Even compare to C when using a library to abstract platform independence (e.g. things like in Gnome/Gtk or Qt), it's not so hard and at least the mistakes are usually yours. I know it's not the fault of Java as a language, but if it can't be implemented well, it won't be much good.

    The final major reason Java has not delivered is because it's not made programming any easier or error prone - and much has been made of this promise. Yes, gc does save some bugs (it does cause some more, but on the whole it's good). Java does not save you from uneducated developers or people who simply suck as a programmer. I've seen some steaming piles of turds writted in Java by people who really should be better. This can be said of any language, but much was made about Java being a language to make people make less mistakes - they just make different ones.

    So use Java with your eyes wide open, it's decent, good in some areas, weak in others and eventually you'll move on to the Next Big Thing TM.

    • by JohnnyCannuk (19863) on Thursday January 23, 2003 @03:59PM (#5145824)
      However for me Java has not delivered on it's promises. Performance generally is poor, compared to say Perl, and is dire when compared to C.

      FUD, FUD and more FUD.

      Starting with the jdk1.3.1_x series Java has been pretty peppy. JDK 1.4.1_x is downright speedy. Do a google search. On the server, Java is very fast and even some Swing apps can beat native code. Java in 1998 was slow. Java today is not. Get over it and stop living in the past.

      Java also failed to deliver it's platform independence - you just get so many problems running on different platforms and different VMs. Compare this to say Perl - if you avoid platform specifics, Perl just works. Even compare to C when using a library to abstract platform independence (e.g. things like in Gnome/Gtk or Qt), it's not so hard and at least the mistakes are usually yours. I know it's not the fault of Java as a language, but if it can't be implemented well, it won't be much good.

      Well I don't know what your experience is but I have never run into any issues with Java being cross-platform. I have literaly just finished doing some bug fixes to a J2EE app for one of our clients. I develop on Win2K, test deploy on Solaris (Sparc) and will deploy it tommorow on HP-UX. All I do is redeploy the .ear compiling involved. Any issues I have ever run into have been when the have code makes JNI calls or when environmental differences in the OS are not taken into account during a JDK install (think .so vs .sa). Sometimes poor programming, like hard coding "/" vs "\" in path names, but that is hardly the fault of the language. Even with a few warts, the fact still remains that I cannot compile C or C++ on a linus box and just run it on Windows box. With Java I can.

      The final major reason Java has not delivered is because it's not made programming any easier or error prone - and much has been made of this promise. Yes, gc does save some bugs (it does cause some more, but on the whole it's good). Java does not save you from uneducated developers or people who simply suck as a programmer. I've seen some steaming piles of turds writted in Java by people who really should be better. This can be said of any language, but much was made about Java being a language to make people make less mistakes - they just make different ones.

      I guess this is a matter of degrees isn't it. No Java isn't perfect. But it's a darn site easier to learn and maintain than other, more obfuscated languages like Perl. Java is a language that let's you make less fatal mistakes. No buffer overflows, no pointers, strict type checking and casting rules as well as the Java sandbox go a long way in protecting a system running Java. Can the same be said about C? So even if I'm a bad java programmer, I can't be bad enough to cause the OS to crash or to introduce a system level vunerablility. C give you the freedom to do anything...kinda like giving you enough rope to hang yourself (and two of your friends sometimes).

      Despite all that, use the Right Tool for the Job. If that is Java, use it. If it's C (and you can use it right) use it.

      But please don't go spreading half-truths and crap to get moderated up.
  • by kronin (413035) on Thursday January 23, 2003 @12:31PM (#5144085)
    I realize that each language has its strengths and weaknesses, but bear with me for a moment. You get hired at a new job, where you inherit a .NET application. As far as anyone knows, it's C#. When you start looking at it further, you realize that it is actually made up of half a dozen languages, all of which you'll have to know at least remotely before you can understand the whole thing. Is this necessarily a _good_ thing? I don't think so. The argument Microsoft uses is "everyone can use what they know, and are most productive in". That's all well and good until those people leave.
  • by Rinikusu (28164) on Thursday January 23, 2003 @01:03PM (#5144354)
    I know I'm probably missing his, but here's how I view his decision to go with .Net/C#:

    MS made the "important stuff" standardized and "open." It still leaves MS in the position to close off the rest of the "non-important" stuff and that could break compatability. If you're looking for "cross-platform" advantages, .NET and it's VM are dependent upon MS's decision to release a VM. Yeah, you could write your own, but what if MS invokes the DMCA and prevents you from implementing a "full" VM due to patents and the like? Then you're screwed, writing applications that run on a perceived "broken" VM that lacks those things that MS has deemed fit enough to lock in. "Yeah, great, OpenSource to the rescue, we'll port our VM to every platform!" Sure, and getting people to use it? Good luck. Tell Joe IT Manager that he can use a "free, OpenSource VM" from a bunch of anonymous guys on the internet or the "official VM" from MS, what's he gonna pick?

    And that leads us to:
    The key is to ultimately remove the dependence upon MS products. We've all stated that time and time again. People run MS for Outlook. For Exchange. For a relatively easy sytem to administrate and patch. For Support. There's a million and one papers, editorials, /. comments, etc that do a good job of explaining all of that, but imagine this:

    What if Evolution had been written in Java? OpenOffice, if I'm not mistaken, is written in Java and if I must say so myself, it runs VERY nicely on my machine and does everything I need it to do as an Office Productivity Suite. With OpenOffice, you see lots of people switching from MS Office, avoiding the licensing fees and troubles, and generally LIKING it (there are exceptions.. there needs to be a nice Access competitor or at least a great frontend for something like PostGRE or the like). That's one less reason to use MS, right? Great! OpenOffice runs on Windows, Sun, Linux, OS X (with X11 installed). Most importantly, see Windows? Millions of people can now look forward to using that $500 they'd spend on Office to doing SOMETHING ELSE with their money. Millions of companies can still do business without outlaying a chunk of cash for Office. There's the example.

    Now, back to Evolution. If Evolution had been written in Java, like OpenOffice, you wouldn't just have people on *NIX platforms using it. No, you'd be able to use it on Windows, the biggest, most important, and most influential marketplace in the computer industry. What would that mean? Let's say you're Joe IT Manager. You've already switched your desktops to OpenOffice. Now, you could replace Outlook with Evolution, on your Windows systems at work (and saving on the licensing, to boot!). See, it's hard to convince upper management to switch to Linux whole-hogged. But if you do it, one app at a time, eventually you run OUT Of reasons to continue to pay the exorbitant licensing fees to support an Operating System that you no longer need to run the apps you run. Dig it? Dig it! Your users use the new apps, already acclimated to them. Change comes slowly, and for the better. And all that time Ximian spent on working on MONO could have been spent tweaking the interface, developing advanced calendaring functions, developing server-side calendaring/schedule making software, etc. And then Linux slips in quietly through the back door and MS is left to send armies of marketdroids to help woo the companies back, losing their marketshare inch by inch.

    I may have Ximian's and Miguel's intentions completely wrong. Linux "desktop" penetration may not be his ultimate goal, although as a Linux vendor it might behoove him to think this way. Linux is inching it's way into the server rooms of corporate America (and the world), and the desktops will be a hard fought battle. Java is the kind of technology that allows you to provide the replacements that will make the transition EASIER.

    To conclude, I applaud Miguel for his hard work on MONO (and Evolution, it does fucking kick-ass). Unfortunately, I think it's misguided and ultimately futile.
  • by Radical Rad (138892) on Thursday January 23, 2003 @01:07PM (#5144386) Homepage
    A company called Halcyon Software used to be developing a VB to java byte code compiler called VBix. I had a beta of it at one time and it worked under Linux with a few quirks in the GUI but only with a certain version of jdk, Blackdown 1.1.6 if I remember correctly.

    Halcyon changed it evidently to a middleware which converts ASP to Java. I don't know why they dropped the VB compatible source compiler. I think it would have been a terrific product had they released it since all the VB coders would have been able to code on multiple platforms with no learning curve. It would have been a huge market for them too, so I would love to hear the real story behind their dropping it.

    They have since merged with a company called Stryon [] if anyone wants to check it out.

  • by jfengel (409917) on Thursday January 23, 2003 @01:26PM (#5144577) Homepage Journal
    <plug> I wrote a book on the subject of translating other languages into JVM bytecodes. It's called Programming for the Java Virtual Machine, from Addison-Wesley, and you can pick it up at Amazon []

    So speaking as a nominal expert, while you certainly can translate non-Java languages into bytecodes, the machine clearly isn't designed to be general-use. It has a lot of object-oriented instructions that fit the Java object model and not a lot else. You can adapt them to your language, or you can ignore them and code everything up as one big method call (except that you'll run out of space, since function size is limited, and you can't modify it once written).

    I've successfully adapted languages like Prolog and Lisp, and taken advantage of Java objects to provide the continuation-like features of these languages. I've even found a couple of places where you can generate code which could not come from Java code but which is legal and verifiable (e.g. crossed loops).

    I use it mostly for small projects. For example, Ontology Works [] generates Java APIs for its custom database description languages. It generates the bytecodes directly, since the APIs are too large to be conveniently compiled from Java. But that's not a general-purpose language, so the code is actually fairly simple.

    I've only glanced at CLI, but it appears to be somewhat more general purpose than JVM bytecodes. (In the end it's all Turing tar pit.) However, CLI a bit more heavily oriented towards calling out to native code, which makes the code less portable and harder to optimize. The JVM also supports native methods, but they receive a lot less encouragement.

    Mostly, I'm a huge fan of the way JVM does verification. It's brilliant that you can restrict code to safe code and still be Turing complete by eliminating a large class of safe-but-invalid instruction sequences. You can make huge optimizations to verified code that you can't make to generalized code. Verification also allows much more fine-grained authorization than the Microsoft way, which is all based on signed code.

    You always want to choose the best language for the job. C/C++/Java are largely identical, and I think in general a group should pick one and stick to it. But there are languages (Lisp, Prolog, Haskell) which are genuinely different, and I consider it a good thing that you can write compilers for them. That has yet to completely fulfill its promise on the JVM platform, where there are proofs of the concept but they are little used.

Nothing will ever be attempted if all possible objections must be first overcome. -- Dr. Johnson