Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Fast, Open Alternative to Java 357

Posted by michael from the better-mousetrap dept.
DrInequality writes: "For those of you out there who admire the portability of Java but want something faster or open source, the answer to your prayers is finally here. The Internet Virtual Machine is open source, fast and supports C, C++, Java and ObjectiveC. There are some cool demos for Linux (requires Redhat 6.0 or above, and OpenGL 1.2 or Mesa 3.41) here (1.5MB) and for Windows (requires glut32.dll, here) here (1.5MB)." We mentioned this last year; perhaps it has improved. I'm sure a lot of people would be interested in a language as portable as Java but speedier.
This discussion has been archived. No new comments can be posted.

Fast, Open Alternative to Java More

Fast, Open Alternative to Java

Comments Filter:
  • No way...its too good to be true. something faster and more open but with the same functionality of java? awesomeness.

    • Re:[insert scary music here] (Score:5, Insightful)

      by jilles ( 20976 ) on Saturday September 15, 2001 @03:47AM (#2302283) Homepage
      It's just C compiled to bytecode. It doesn't have most of the features that made Java popular (e.g. security, dynamicity, reflectiveness because inherent design decisions in the way C programs work inhibit this). In other words it is no replacement.

      Don't understand me wrong, maybe integrating such a thing with e.g. the gnu compiler would be useful. It would be great to create a single set of binaries and distribute them to the hubndreds of unix versions and other operating systems. But it has to be clear that this thing is orthogonal to java rather than the same.

      In any case, I'm not impressed and even bored. Java is a relatively simple language. Most of the language concepts are easy to grasp, even for novice programmers. Yet people keep comparing it to more primitive languages such as C and suggesting alternatives which are basically C++ improved rather than Java improved. After years of being confronted with a rapidly growing java community, even some C++ programmers begin to appreciate things like garbage collection (after having dismissed it for years based on performance concerns). However, beyond garbage collection they are still largely missing the point (i.e. C is not so cool after all).

      What I would like to see from the open source community (perhaps as a proof of concept) is a more ambitious effort, not just a (partial) duplication of features inspired by ignorance rather than innovation. Java has room for lots of improvement, lets set it as a baseline rather than a design goal. Duplicating all of Java's useful features should be a minimum requirement and not the ultimate design goal.

      This post is rather harsh, I know. However, I think this is a fundamental problem with open source in general and linux in particular: it's mass production of commodity software components (kernels, compilers, IDEs, word processors), not creation of new ones. If cutting edge technology is your thing, the propietary world is still the source of it (speech recognition, cool 3d technology, AI related improvements to user interfaces, compiler technology, languages, ...). It is very rare to see an open source project that does not just duplicate features but instead introduces radically new features and paradigms. There are some research projects that use open source to distribute their stuff but these generally play only a marginal role in the open source community. The big open source projects are all about duplicating and imitating the bigger/better (in most cases) propietary counterparts.

      In short I find the open source community boring & backwards. Its contributions are very useful and I use them on a daily basis. However, as a researcher I don't want to wait for thirty years to see things like OO being grudgingly accepted; I hate it when linux is advocated as a windows alternative when the people doing so largely fail to even realize why windows got popular in the first place. The same applies to Java and Visual Basic (yes, from the *evil empire* you understand me correctly). The features that made those things popular have yet to be duplicated. Effords like the one advocated in this article are just so backwards they only make me angry. Go do something useful! Don't waste your time figuring out how to reinvent the wheel, I already have half a dozen.

      • Open Source Innovation (Score:2, Interesting)

        by richieb ( 3277 )
        [...] It is very rare to see an open source project that does not just duplicate features but instead introduces radically new features and paradigms. There are some research projects that use open source to distribute their stuff but these generally play only a marginal role in the open source community. The big open source projects are all about duplicating and imitating the bigger/better (in most cases) propietary counterparts

        This is true in general. It is rare to see a project open source or proprietary that is really innovative and different. That's because it's easy to copy existing ideas than to think up and implement new ones.

        But remember that the Web (http, server, browser) were started as open source projects and today Apache is still one of the best web servers there is.

        If you look around there are number really cool open source projects that are way ahead of anything the propriatary world is doing. Here are two I like:

        Jazz [umd.edu] - a Zooming user interface, as discussed in Jef Raskin's book The Humane Interface.

        Squeak [squeak.org] - a ground up implementation of Smalltalk-80 which is being used in all kinds of explorations. One of the leaders of this project is Alan Kay (you've heard of him, haven't you?).

        Innovation can come from unexpected places. If more people get to play with the code, then it's more likely that someone will think of something really cool...

        ...richie

        • Both these projects I would refer to as rather marginal efforts (interesting though). Squeak is essentially a smalltalk clone. I haven't heard of jazz yet (will check it out soon).

          I have heard of Alan Kaye. In fact I was about to listen to a keynote by him only last week(unfortunately it was cancelled at the last moment).

  • A fried of Mono? (Score:3, Interesting)

    by Whyte Wolf ( 149388 ) on Friday September 14, 2001 @10:00PM (#2301540) Homepage
    COuld this possibly be useful with Ximian's Mono project, or Gnu.NET? I could imagine using this as a VM for C# could seriously PO M$ :)

    • DotGNU (Score:4, Insightful)

      by bstadil ( 7110 ) on Friday September 14, 2001 @10:11PM (#2301568) Homepage
      The DOTGNU guys has already looked at it. From Carsten Kuckuk via the MAilinglist

      Quote

      I printed out the spec last night and read it on the commuter train back
      home. The IVM team essentially created a specification for a Motorola 68000
      like 32 bit processor, assigned 16 bit opcodes to instructions and
      implemented an interpreter for it as well as an adoption of the gcc
      compiler.

      Advantages:
      + Portable
      + It works
      + Very fast

      Disadvantages:
      - No separation of data and code
      - Interface to the underlying operating system is POSIX
      - No built-in security, not even a sandbox

      My assessment:
      o Good piece of Engineering: It's there, it works, it solves a problem, it's
      GPLed, it's tested.
      o In order to be used as one of the VMs for DotGnu, security needs to be
      added. As one of the rules in secure programming is that you can never add
      security to a system, but that it needs to be designed into it, I don't know
      if that is possible.
      o For my personal taste it's too close to real untyped assembly language.

      Carsten Kuckuk

      Unquote
    • Ximian isn't interested in staking new ground. THey want a sure thing. THey are a company in need of money. They want C# because they think it will be a new revenue source in which they can make a name for themselves.

      Java is full of weenies mark(et)ing their territory already. No room for ximian. Poor ximian, so badly in need of revenue. what for-ever shall they do? C# Ah yes. Ride on teh back of microsoft. maybe they are wiser than me, for I would be too scared. (offtopic, OSU was kicking tonight! I am so druNK! Fsxk me! hahahha ahahhahah. It aint the 4th biggest party school in the US for nothing!)

  • I wonder... (Score:2, Interesting)

    by L-Wave ( 515413 )
    "Our vision is to bring the Internet Virtual Machine to the Internet completely, enabling video games, interactive entertainment, and applications to be operated from the Internet on your browser or television"

    I wonder how secure they expect this to be? I know I wouldn't want to run an Accounting program (or anything similar) via the internet. Does anyone have any experience with the code to share info?

    • Re:I wonder... (Score:3, Interesting)

      by small_dick ( 127697 )
      In the future, there will be middleware.

      I don't know how else to put it. The laws, the technology...everything is going to middleware.

      Java, C#, this product...a better question is : how will i find apps that don't run off the internet?

      Answer: a computer museum. I'm totally serious.

  • It crashes on RedHat Linux 7.1 (Score:4, Informative)

    by BlowCat ( 216402 ) on Friday September 14, 2001 @10:10PM (#2301562)
    I downloaded the binary and it crashed on RedHat Linux 7.1 with all updates and kernel 2.4.9-ac10. It looks like that it's the library loader that crashes, because even ldd icvm dumps the core.

    Sorry, I have no time to download 23M of compressed sources to compile it. But if it crashes for you, you probably have to.

    • I kinda hate to say it, but a lot of stuff crashes under 7.1--at least, a dozen or more apps that ran fine under older RH (and seem to work fine on other distros) core dump. etc. on my RH 7.1 box. Mostly it's been glibc incompatibilities and such, but still rather anoying if you don't have the time to chase it down. So this may not be a problem with the IVM per se.

      -- MarkusQ

      P.S. Who the heck moderated the parent "offtopic"?

      • Of course it's not a problem with IVM, if ldd crashes. ldd should never crash. It's a libc problem (or the kernel, but it's less likely).

        Sorry, I keep forgetting that an average /. reader cannot figure it out.

    • Lol. And why do you think anyone on slashdot should care? Mmmm Beta software doesn't work for person X. Maybe I shouldn't try it. Yeah! Great, thanks for passing on the gewd wh0rd (goat speak - yes, I am durnk)!

  • Faster? (Score:4, Insightful)

    by silicon_synapse ( 145470 ) on Friday September 14, 2001 @10:11PM (#2301564)
    Java is already comparable to C/C++ in speed. It has made a lot of improvements over time. I think the key to better speed now lies more in better code than in a better virtual machine. I can't see this gaining a significant acceptance. It'll probably do it's job well, but there needs to be some pretty compelling reason to move away from java.

    • Re:Faster? (Score:5, Insightful)

      by Waffle Iron ( 339739 ) on Friday September 14, 2001 @11:04PM (#2301713)
      Java is already comparable to C/C++ in speed.

      Well, the actual situation depends very much on the abstraction level of the program being implemented.

      JIT compiled Java is kind of strange because it is competeitive with C++ at both low-level (bit banging primitives) and high-level (dynamically allocated objects). However, in middle ground (nontrivial objects that can be allocated solely on the stack), C++ blows Java away. This is mainly because all Java data that is not a local primitive variable must be dynamically allocated.

      As an example, one concept that is on the border between mid-level and high-level abstraction is strings:

      If you use C++ at a nice comfortably high level of abstraction (i.e., with some implementations of STL's std::string), it can be significantly slower than Java because of construction and destruction of every function parameter. OTOH, if you write your C++ program in a painstaking and dangerous C-like fashion (using one stack-based buffer for a string across many levels of function call), it can be an 1 or 2 orders of magnitude faster. If you bang on strings alot, a language like Perl can be a good choice because its mutable strings are more efficient than Java and safer or easier than C/C++.

      (Aside: In my experience, a rule-of-thumb is that most dynamic memory allocations in any language seem to take on the order of 1000 CPU clocks, and most dynamic "objects" end up consuming about 1000 bytes.)

      Of course, at the end of the day, all the issues that I just raised pale in comparison to the importance of the basic structure of your algorithms. If you feed in 50X times your expected load into your application, it will often slow down and/or eat memory in a spectacular fashion. By recoding to eliminating that problem, you can often make a "slow" language outperform "fast" one. This is often done by identifying the portions of your algorithm that depend on input size and perform worse than N*log(N) in space or time, then recoding them so they don't.

      The upshot: it all depends.

      • Re:Faster? (Score:4, Insightful)

        by MarkusQ ( 450076 ) on Saturday September 15, 2001 @01:43AM (#2302042) Journal
        ...if you write your C++ program in a painstaking and dangerous C-like fashion (using one stack-based buffer for a string across many levels of function call), it can be an 1 or 2 orders of magnitude faster...

        There is a general principle at work here: you can quite often go one or two orders of magnitude faster if you are willing to give up safety. It applies to everything from sex to ice hockey, and (viewed at the right level of abstraction) the results are always pretty much the same.

        -- MarkusQ

      • Re:Faster? (Score:2, Informative)

        by kryps ( 321347 )
        How nice it may sound, some things in this comment are just not true:


        JIT compiled Java is kind of strange because it is competeitive with C++ at both low-level (bit banging primitives) and high-level (dynamically allocated objects). However, in middle ground (nontrivial objects that can be allocated solely on the stack), C++ blows Java away. This is mainly because all Java data that is not a local primitive variable must be dynamically allocated.

        Objects that are used only in the function in which they are created can be allocated on the stack if no references to this object are returned/passed as arguments. In fact recent VMs (Sun 1.3.1, IBM 1.3) do exactly that.


        If you use C++ at a nice comfortably high level of abstraction (i.e., with some implementations of STL's std::string), it can be significantly slower than Java because of construction and destruction of every function parameter. OTOH, if you write your C++ program in a painstaking and dangerous C-like fashion (using one stack-based buffer for a string across many levels of function call), it can be an 1 or 2 orders of magnitude faster. If you bang on strings alot, a language like Perl can be a good choice because its mutable strings are more efficient than Java and safer or easier than C/C++.

        Well that is what the StringBuffer class in Java is for. StringBuffers are very fast for this kind of thing. While I have to admit that Java immutable Strings make it easier for the developer too generate code which performs poorly it is well possible to produce (text processing) code which performs really well.


        Aside: In my experience, a rule-of-thumb is that most dynamic memory allocations in any language seem to take on the order of 1000 CPU clocks, and most dynamic "objects" end up consuming about 1000 bytes.)

        Your numbers are just wrong at least for recent Java implementations. Object allocation is very fast in languages using a generational garbage collector because allocating an object just consists of increasing a pointer by the size of the newly generated object. On the other hand the time needed for object deallocation has to be considered. The cost for deallocation is highly dependant on the number of live objects and the way objects are created. If the way objects are created is "compatible" with the generational GC (i.e. most newly created objects are short-lived) deallocation is very fast as well. Example: Object creation takes about 60 CPU cycles (JDK 1.3.1) on my Athlon 1200 if the objects are discarded directly after creating.

        I don't know where you got the "1000 bytes per dynamically allocated object" number from. In JDK 1.3.1 each object has an overhead of 16 bytes.


        Of course, at the end of the day, all the issues that I just raised pale in comparison to the importance of the basic structure of your algorithms. If you feed in 50X times your expected load into your application, it will often slow down and/or eat memory in a spectacular fashion. By recoding to eliminating that problem, you can often make a "slow" language outperform "fast" one. This is often done by identifying the portions of your algorithm that depend on input size and perform worse than N*log(N) in space or time, then recoding them so they don't

        With this I have to agree.


        -- kryps

      • Re:Faster? (Score:3, Insightful)

        by X ( 1235 )
        Some things you got wrong:
        1. All Java data that is not a local primitive variable must be dynamically allocated.
        2. Dynamic memory allocations in any language seem to take on the order of 1000 CPU clocks.
        3. Most dynamic "objects" end up consuming about 1000 bytes.
        1. I presume by this you actually mean stack allocated, as opposed to dynamically allocated (it's certainly possible to define statically allocated objects). While on one hand objects are meant to appear to be allocated on the heap, IBM has done a great deal of research on using linear analysis to allocate linear objects onto the stack. Works great.
        2. Allocations in the HotSpot VM can take only a few instructions, much like stack allocation. Unlike C++ you don't have a heap that you are constantly trying to keep balanced and unfragmented.
        3. Objects in Java are quite small. Indeed they have to be smaller than the 1K that you claim they need. Try allocating a million objects in a system with less than 1GB of memory. You'll find it works just fine. Again, with a compacting garbage collector, you don't have to worry about all the overhead associated with heap management which causes objects to be bigger than they need to be.

        It seems to me your programming prejudices are tied to experiences with C++. If you learn the Java paradigm better, you'll discover that a lot of the performance trade-offs you learned in the C++ world don't play out the same way in the Java world.

      • Re:Faster? (Score:3, Insightful)

        by mj6798 ( 514047 )
        However, in middle ground (nontrivial objects that can be allocated solely on the stack), C++ blows Java away.

        What you are complaining about there is that a particular coding style you are used to from C++ doesn't carry over to Java. However, there are reasonable, alternative ways of expressing the same kind of code in Java. They aren't ideal (and Java isn't perfect), but they are workable.

        (Aside: In my experience, a rule-of-thumb is that most dynamic memory allocations in any language seem to take on the order of 1000 CPU clocks, and most dynamic "objects" end up consuming about 1000 bytes.)

        That may be a good rule for C++ (whose storage allocators generally have high overhead), but in a language like Java, a good implementation should have about one word of overhead for a large object and no overhead for small objects, and it should take about as much time as one store on average per word of storage allocated. The current JDK is a bit worse, but it still seems to beat most C++ allocators.

    • Re:Faster? (Score:2, Interesting)

      by eric17 ( 53263 )
      Well I've never had a compelling reason to move TO java, so I think perhaps there is a group of people like me that have different needs than the group of people who find Java compelling.

      Perhaps Java is _too_ dynamic, _too_ simplified, and _too_ rigidly held by its creators for certain developers. On the other hand C++ is annoyingly crufty, but does let us do stuff that Java will not, and is not controlled by any one company. Java's design prevents many forms of optimizations, and there will always be programs that are impossible to write in Java with anything near C++ speeds. Java can beat C++ in some forms of code where its design does not prevent good optimizations. On the other hand there is a separate but smaller set of optimizations (and associated cruft) that C++ can't perform because of its forced compatability with C and old style linking.

      Perhaps IVM will allow someone to build a language that jetisons the cruft from C++ without removing the power, perhaps not. While the JVM design prevents this from happening, the IVM does not seem to prevent it, AFAICT.
    • Have you ever programmed with swing? It's just painful.
      • That would just be because Swing is broken by design. It's terrifying to think that a bunch of unix geeks could come up with something that is just that horribly broken. If you want a snappy java gui just use the remnants of AWT and ignore all the deprecated warnings, or pick up one of the java to native widget libraries that are floating around the net.
        • What's broken about it? They didn't do enough optimisation on it until this year (1.4), sure, but that's not a fundamental external API problem, just an internal design problem.

          • AWT widgets map directly to the native widget sets for almost all platforms: Windows, Mac, Unix (Motif in many cases). This allows the windowing system to do all types of optimizations, and minimizes the complexity of the application, as well as the volume of information it needs to send to the display.

            Swing by contrast maps all the way to pixels within the JVM. This not only prevents the native optimized windowing system from having any advantage, but nearly always degenerates into full frame bitmaps being pushed for every refresh. While it is true that IBM is pushing a lot of performance tweaks into 1.4 to try and work around this, there really isn't any way it will ever catch up with awt.

            This is not a problem on windows where applications can get direct access to the hardware to push a pixel image down, but on most other operating systems this simply isn't the case. X is particularly hard hit in this, have a look at a swing application running under xscope to really see this.

            Java was promissed to be a platform independent environment, but it has become clear that Java's GUI team only cares about Windows. Sadly by the time this was discovered a lot of applications had already been coded and deployed. Within my company for example an entire toolchain was developed before anyone had discovered this, and the impact of widespread use on the network had been discovered. The result is that the large unix boxes that the applications are run on have been set up with VNC servers and the users have vnc clients on their thin client machines because it's compression and selective redraw logic does such a major improvement over raw swing.

            This is more than just an internal design problem, it's a core architectural issue because Swing was *intentionally* designed to work this way, doing all the widget rendering (and font rendering, and focus management, and ...) in the JVM so that it could present the same (bit for bit) gui no matter the platform. While they have reached that goal, it has been at a cost... while all java based applications can look and feel the same, it also means that none of them really blend in with the other applications on the system, infact they stand out as "differnet" and sometimes "broken" in the user reactions. An end user (who else are applications written for?) usually wants something that integrates with their platform, they don't care what we used to implement it. This is why I say swing is fundamentally flawed by design, unfortunately most of AWT has been deprecated.
  • Looking at the description of the VM, I see only 4 general-purpose 32-bit integer registers - which seems like a rather shortsighted limitation to me. Seems like this VM is designed to be easily dynamically-translatable to x86 code - but there are plenty of other (better designed) architectures with more registers that IVM could target...seems like a waste to me.

    This is a neat idea - but isn't this essentially a clone of what Amiga's been doing with their universal VM?
    • That's right -- the "internet virtual machine" seems designed to map well onto a single CPU, the x86.

      The standard library seems designed to map well onto a single OS, Unix.

      You can run it on your big fancy RISC machine (well, if they've gotten around to writing a stable back-end), but it'll still approximate the performance of a register-emasculated ia32 processor.

      It's a bit more portable than an Linux ELF binary, but not much. And about as revolutionary, given that a Linux runtime also exists on the modern BSDs (for example)

    • Why even bother with registers at all? Hardware CPU's use registers as because they are bits of faster memory, but that isn't necessary in a pure virtual machine. Unless you're trying to model a real CPU, why screw up the acrchitecture with unnecessary registers. Just have it do everything on the stack. In an all software VM, regsiters buy you nothing but unneeded compiler complexity.

  • What about C#? (Score:3, Offtopic)

    by tshak ( 173364 ) on Friday September 14, 2001 @10:12PM (#2301570) Homepage
    What about C#? Many Java and anti-Java advocates have come to a common ground that C# is a great language. It's fully OO and very easy to code in. MS has submitted the spec to the ECMA, so isn't this possible?

  • C++ vs. Java all over again. (Score:3, Insightful)

    by under_score ( 65824 ) <mishkin.berteig@com> on Friday September 14, 2001 @10:15PM (#2301579) Homepage
    Okay - this is a "religious" issue. Building and promoting for C++ works up to a point. But the fact is that C++ and Java are both industrial strength languages (especially if you consider their libraries and tool support). It seems that the IVM does C++ "natively" but requires an extra step for Java etc. Why? Can't it just figure it out from the context? The file extension? The syntax? This IVM seems to be a pretty cool idea. Not new, but cool (IBM's UVM). I like the fact that they bothered with Objective-C (although that might just be because I believe the GNU GCC supports it).
  • If you'd like to execute your code with native speed on any platform from a single sourcebase, why not use a cross-platform application framework?

    Here is a list of many application frameworks [asu.edu], many of which are cross-platform, and many of which are free software.

    My favorite is ZooLib [sourceforge.net], a multithreaded C++ framework.

    Read about the importance of cross-platform application development. [sourceforge.net]

    • If you'd like to execute your code with native speed on any platform from a single sourcebase, why not use a cross-platform application framework?

      Because then you either have to recompile for all platforms and provide binaries for all of them (along with suitable installation instructions/programs) or you have to make your source available. The former is a pain, since the whole aim of writing truly cross-platform software is that it can run on any platform, not just those you happen to have development tools for. The latter may not be desirable (not all software is open source, you know) and causes hassle for people who don't feel they have the skill to compile code from source and install it.

      Well, you asked...

  • I have used Java and Objective-C professionally in a very extensive manner, and a little bit of C++. I think they are all great, but I feel more friendly to Objective-C :-) It is great to see that the IVM people have bothered with it. It would be really fantastic if they made it so that you could inline any language inside any other. The big difficulty with this is that the three languages (C++, Java, Objective-C) have fundamentally different ways of "implementing" objects, particularly method calls, but other aspects as well. Objective-C provides more flexible run-time typing and meta-class objects. Java has decent security, exception and threading built in (decent, not great). C++ has operater overloading, friends, etc.
    Check out my Courselet: Architectures with XML Documents [oomind.com]
    • You bring up an intersting point. How fast is objective C and why aren't more people using it?
      • Fast. Method invocations take (I think) about 3 times longer than normal C function calls, and if that becomes a problem in a tight loop (which is rare) you can cache the function pointer for a method and use it to bypass the dynamic lookup. Unfortunately Objective-C mostly got overlooked due to the momentum of C++, but hopefully Mac OS X and GNUStep can change that.

  • Java *is* open source (Score:4, Informative)

    by magic ( 19621 ) on Friday September 14, 2001 @10:50PM (#2301675) Homepage
    The original post was misleading.

    Java is open source, at least for practical purposes. Sun has released the source to the entire Java standard library. IBM's Jikes is one of the best Java compilers available (it is more reliable and faster than javac), and is available with full source.

    Open source doesn't just mean the GPL! The GPL trouble more often than not because most companies won't get within miles of it for fear of legally contaminating their sources. The important thing is getting provided source code to be seen as a standard, not a wierd alternative. With Java, the source is provided and is really useful.

    I wouldn't put Java and C# in the same boat as far as "proprietary". You can't fork the Java code base directly, but Sun is really responsive to the community. Most new libraries are incorporated from user built packages, and all new features go through a community review. The bug database is open to the public. Sun provides open source repositories like jxta.org to help the community. Sun is the good guy... C# is Java Microsoftified and is evil (although a decent language) because it won't have this kind of community interaction and open source.

    -m

    • Re:Java *is* open source (Score:2, Interesting)

      by oops ( 41598 )
      This is a perfectly fair comment, despite the replies it's received already. I use the API source to answer queries from programmers I work with, resolve issues wrt. performance/usage etc. From my clients perspective (big banks, usually) this is perfectly adequate. They're not going to want to modify the source. They invest in Java to have a maintainable code base that does (to any practical degree) run anywhere.

      The Sun developer connection is responsive. I vote for bugs to be fixed (3 at one time). In the last 3 weeks I've had three issues resolved.

      One of my developers came across a threading issue last month. It's resulted in Sun's kernel people, Java people and threading people banging their heads together and finally issuing a bug fix in the form of a new JVM for us to test. Once we've confirmed that it's a fix, it'll go into the main branch.

      Is it GPL ? No. But from a big business perspective, there are other more important issues.
    • What the hell is up with moderating the above post as a troll? There is absolutely nothing in there that any reasonable person could object to.

      The issue with companies shying away from the GPL is a fact. I don't mess around with GPLed code for that exact reason. I'm really hoping I manage to get that moderator in metamod *rubs hands gleefully*...
    • Java is open source, at least for practical purposes. Sun has released the source to the entire Java standard library.

      Not really, last I checked the sun.* packages have not been released, and the packages that have been released are under the equivalent of MS's "shared source" license.

      IBM's Jikes is one of the best Java compilers available (it is more reliable and faster than javac), and is available with full source.

      Why thank you. But Jikes is more a result of Sun having attempted to standardize Java, we work from the two pubished specifications for the language and the virtual machine, not from anything released under the SCSL. (aside: we're also in need of more active developers.)

      Open source doesn't just mean the GPL! The GPL trouble more often than not because most companies won't get within miles of it for fear of legally contaminating their sources. The important thing is getting provided source code to be seen as a standard, not a wierd alternative. With Java, the source is provided and is really useful.

      hmm... well that's true, however, a more important aspect I've always felt was what you can *do* with the source. With the SCSL for example if you find a bug in a given class you can't distribute a fix without violating the license. The best you can do is submit a bug telling them how to fix it, then hope it eventually get's incorporated.

      The bug database is open to the public.

      Um, not entirely. You don't get 100% view of the bugs, even in the community source area.

  • Some quick thoughts. (No sound, GPLed) (Score:3, Interesting)

    by BrookHarty ( 9119 ) on Friday September 14, 2001 @10:50PM (#2301678) Journal
    The demos are nice and small, very impressive. Ill need to try this on my linux box in a few moments. (Looks like from the /. posts is crashs on some redhat installs..)

    No sound, but its still in beta, so things should be added. The most impressive thing, is IVM is GPLed! No pesky Sun or Microsoft License! Now give me a QNX, Ipaq and Gameboy Advance IVM and im set!

  • Cross platform? (Score:3, Insightful)

    by bay43270 ( 267213 ) on Friday September 14, 2001 @11:21PM (#2301762) Homepage
    I know Java isn't very popular here, but I have to say this... (I guess I wasn't going to be able to spend the karma on Christmas presents anyway) I think this is a bit insulting to the people at Sun to say IVM is cross platform. Cross platform means a lot more than just being able to run on more than one OS. Think about internationalization support. Does the ability to swap out text in the GUI constitute internationalization? No. Currency, calendars, colors and many other issues make up internationalization. The same principal applies to cross platform support. Sun spent a lot of work grappling with issues such as how to provide the programmer with an operating system independent environment. They deal with memory management, threads and display capabilities in ways that work consistently from a kiosk to a cluster of Alphas. They spent a lot of time dealing with j2ee, making sure the application server environment was swappable. They spent a lot of time working on platform independence in general, and I think its insulting to Sun to say that slapping a virtual machine under a compiled language is any more than a small part of the platform independence offered by Java.

  • It Will Never See Widespread Acceptance (Score:3, Insightful)

    by istartedi ( 132515 ) on Friday September 14, 2001 @11:41PM (#2301804) Journal

    It Will Never See Widespread Acceptance. Why? It's GPL'd. So, until Linux conquers the desktop, or Netscape recaptures the browser market it's irrelevant.

    PNG and JPEG are in IE because of the license. If they were GPL, all the MS browsers would be supporting GIF and some other alternative for lossy.

    I didn't download IVM, but I decided to take a look at the instruction set. I gave up because it was taking too long to download! It looks like it has thousands of instructions. The JVM has less than 256. Something tells me IVM won't be targeting the embedded market. :)

    Don't get me wrong. There is a market for embedded C or C++ virtual machines. I know because I'm working on one for my own use, and other parties have expressed interest to me. But I don't expect to bring in big bucks with it. MS CLR will probably win on Windows, and the JVM will win every place else. The smart money is on tools and languages that target the installed base. Sound familiar?

    • If the libraries for PNG and JPEG were GPL, they would be rare even under Linux.

      But I wonder about IVM and the GPL. Will all programs executing under IVM also have to be GPL? If the programs have to link to an IVM module of some kind, they may have to. I guess it all depends upon how it's done.

      But how in the world will one be able to write a IVM plugin for Mozilla? Or Galeon and Nautilus, which still use non-GPL Mozilla code? If IVM is truly GPL, and with no exceptions, then it may be limited to Konqueror only.

  • More programming languages than programs (Score:3, Funny)

    by WildBeast ( 189336 ) on Friday September 14, 2001 @11:47PM (#2301822) Journal
    It's crazy, at this rate we'll have more programming languages than programs, we'll have more OS's than we can think off, etc.. I don't know if you're getting it but at this rate, the value of software will sink. Supply is much bigger than demand, soon enough developpers will not afford to pay for food. Don't say I didn't warn you.
  • Am I missing something ? How can a language 'support' another language (I assume this means relatively full support), support other languages, and yet still be faster than *any* of the languages ? The only thing I can imagine is that their compilers are better, but somehow I doubt that's the answer.

  • Wish it luck, but... (Score:3, Insightful)

    by arQon ( 447508 ) on Saturday September 15, 2001 @12:26AM (#2301911)
    There's a lot to be said of platform-neutral environments. Typically tho, what's said is: "It doesn't f**king work". C++ is standard only as long as you're willing to stay with the language as it was 5 years ago, since we're constantly forced to use (eg) SunCC 4 or MSVC 6 or some other hopelessly broken compiler because of broken legacy code that NEEDS it; and Java has never been anything other than "write once, debug everywhere".
    Being language-neutral on top of that is also a great thing for a VM, although it's no shock that the VM is going to be biased towards one language over the others. But let's face it: anyone using Java doesn't need hard-realtime performance anyway, otherwise they wouldn't be using Java in the first place. Same as if they were VB devs. So it makes sense that the bias would be towards C++.
    The IVM runs DAMN fast, supports a truly open, pretty well-designed, widely-available graphics library: it's got a lot going for it.
    But it'll have to bully its way past Java to get wide acceptance even if it's 10x better; and to truly become a standard it ironically needs to be adopted by, yes, THEM. The people whose browser has 80+% of the market. Of course, since it's GPL'd that's hosed it right there.
    Then there are the same security issues that you see with every inet VM: how sure can I be as a user that some site's little applet didn't just funnel a ton of info back to them, that it won't do nasty things to me, etc. THOSE are the sorts of things that always bother me about "active" content: take a look sometime at how trivial it is to totally ruin someone's machine with an ActiveX control.
    As an "Internet VM", I have as much use for this as I do for ANY objects-on-Web-pages "solution", which is to say, damn close to none. I have ONE site that I'm willing to run Java from: ESPN for it's baseball applet. Every "enabling" technology that people use for this stuff tends to end up meaning "enabling inept web designers to create gimmicky pages that don't work", especially when they end up using scripting and crapplets to mimic the most *basic* HTML functionality like hyperlinks. (No, I'm not joking. I've seen it happen).
    OTOH, for an *intra*net I would definitely consider something like this, and I'd prefer it over Java any day of the week. And for little noddy apps, being able to use my language of choice and still have portability AND much better performance, well, that sounds pretty good to me too.
    So I think it's a useful bit of tech: just that it'll never go anywhere in the role they're pushing for it. That's not necessarily a bad thing though. :)

  • this is good but not great (Score:3, Interesting)

    by Anonymous Coward on Saturday September 15, 2001 @12:56AM (#2301964)
    Having a VM to make C, C++, Obj-C (and Java) alll portable and still fast is great. Java does reduce the need for this and since the VM isn't portable to my platform of choice (OS X) this certainly isn't the answer for me at the moment. If it grows and moves to other platforms, tremendous.

    People here have already started rebutting the need for this as Java is fast, has great libraries and enforces good writing style. In response to that, from a person who makes his living writing Java:

    • Java is fast. It runs close to C/C++ in basic algorithm tests from what I've seen, depending on your runtime settings and VM.

    • Java's lack of direct pointer manipulation (e.g. pointer arithmetic) does help people from hurting themselves and that alone leads to better code. The OO nature helps a bit, but really, not much more than taking C++, removing pointer manipulation and removing huge reliance on globals. Obj-C, which I use in my hobbies for OS X, is just as good an OO language, with some minor quibbles about its syntax being more awkward. The lack of memory control in Java loses out big time to the option of manual or automatic memory deallocation in Obj-C. Big Time Loss, even in 1.4.

    • Java's libraries lead to code bloat. People substitute poor use of OO code and APIs for their poor use of pointers in their C work. Sun encourages this poor use by advertising its APIs' functionality and not their many weak points and the fact that its APIs aren't particularly efficient outside of a limited scope.
      Example: People commonly use a Vector when they just want an array of simple types (e.g. int) that will always be "large enough". Vector implements things that have nothing to do with this functionality and Vector doesn't support simple types. Code using the Vector with an Integer rather than an array with an int runs at less than 2/3 the speed and has a much larger memory overhead. Yes, teaching will help people reduce this error but with many classes the poor API coding is two, three or four parent classes above the class you think about using and oftentimes performance of the code is obfuscated - you don't want to have to write replacement code and test yours by theirs in order to determine if you should write replacement code. Java substitutes interfaces and Object-Orientedness (e.g. "Integer" support but not int) as so-called functionality while sacrificing efficiency and usefulness. Whereas efficient programs like to keep good form while remaining close to the bone, java likes to wrap your whole body in saran wrap and then cover that in tupperware and then let you touch the code through those nice OO pieces of plastic surrounding your hands. People teaching Java generally never tell the students the API code sucks, often because they don't really realize it themselves (in academia) or ..? Or if not that I don't know why they don't. I guess the modus operandi for many Java programmers is to rarely research the code beyond the published docs. It came to heart for me after I had to write an editable text component extending from JPanel as everything they offered was wretched for something requiring complex formatting.

    • Java's libraries are very buggy and often poorly written. In final release versions their code still has questions, e.g. "How should this be handled?". They have some bugswhich are 3 or 4 years old [sun.com], easily noticeable and in a basic part of their API which aren't even fixed as of 1.4. Leading to...

    • Sun doesn't support community fixes to its libraries. This is the worst thing possible given their oft-shit code. If they simply had a "submit bug fix" section in an easily found place that would help so much. This is the major downfall of them not having truly open source code - you can look, but you can't fix and post so no one else will have to fix. This, above all the other reasons, is why Java still has such a poorly implemented API and thus (through its poorly made API) why it is not automatically the language of choice when considering C++, Java or other OO languages. It's really not the language that is so slow, it's the poor implementations in and the misuse of the APIs.

    So, please, all you fellow Java programmers, realize that Java is far from perfect, and even just among the languages with an OO nature, it is not the best (none of them are). If Sun made it easy to fix its code, and offered more classes with less "functionality" and better performance it would become vastly better. I don't see Sun really making the changes necessary to make Java fast and memory efficient and, well, responsive to programmer's needs. If this VM can become a practical substitute for coding across platforms I would happily make the switch and would certainly hope that my company does the same. Unfortunately for both these paths the promises therein are still well in to the future.

  • Ahh, I can tell that you know a language other than JAVA, because people who only know one language seem to want to defend that language to the death. I am so sick of listening to programmers who only know one language, call themselves programmers, and will fight to the death explaining why that language is better than all others without a good grasp on theory to do so.

    I don't see why this should be any quicker though :-P
  • Does not sound very cross-platform to me. :)
  • The problem with arguing about java is that it is two things.

    1. A language.

    2. A virtual machine.

    There is no need for a virtual machine. Simply a language with a full and developing library which is cross platform. Any language which is defined and left alone is going to become out of date very quickly.

    VM's are always going to be slower than native code. If you want a cross platform language, implement the cross platform ability at compile time rather than at run time.

    HZ.

    ps I'm a Lazy Bastard, not an Anonymous Coward :P
    • "There is no need for a virtual machine?"

      This sort of quote sounds very much like you read it off the net in some opinion piece somewhere, because it's meaningless and you offer no support for your assertion.

      Let's see how you'd define Java without a virtual machine. Firstly, we'd assume that we'd not want to give up any of Java's features or 'niceness', because after all if there's no "need" for a virtual machine it implies that we can eliminate the VM without compromising anything.

      So let's enter an alternate universe in which javac just produces a native executable file. Fine and dandy. Unfortunately, we immediately hit a few snags. How do applets work? Applets are distributed to whatever machine requests them, so unless you already have a compiled version you just can't do it. Hmmm. What about security? Java is a secure language, meaning that untrusted code running in the sandbox can't cause meaningful harm to your computer. You can't make that guarantee about an executable.

      What about Web Start, which distributes code to different computers? That will be a problem too. How about a program which requests a few classes from elsewhere? Same thing.

      Okay, so scrap that idea - clearly we'll have to give some things up. So instead of javac only producing executables, we'll change it to instead produce an intermediate format, and then have it automatically translated into the final representation as soon as we know what that representation is. Well, guess what, genius! VMs have been doing exactly that for five years.

      "VM's are always going to be slower than native code. If you want a cross platform language, implement the cross platform ability at compile time rather than at run time"

      Check out the Java Performance Report [javalobby.org], in which Java delivers MS Visual C++ a thorough spanking. (Disclaimer: it does lose to Intel's compiler, but gcc isn't anywhere as good as Intel's)

      The Slashdot community, at least, should be smarter than this. Never, ever say that technology A will never beat technology B without a mathematical proof of its limitations in hand.
  • Comment removed based on user account deletion
  • Looking for a fast, portable, free-as-in-speech, object-oriented language? Try Squeak [squeak.org], a wonderful smalltalk implementation. It's great. I've been playing with it quite a bit myself, and have been very pleased with it.
    • Looking for a fast, portable, free-as-in-speech, object-oriented language? Try Squeak

      Squeak is Smalltalk. That means, among other things:

      The is no clear separation between the environment and the program.

      There is a confusion between a pointer and the object itself.

      There is no finalaization (destruction)

      There is a single memory model for instances (heap) versus, for instance, C++es minimum of 4 (heap, stack, static, member-of-another-object)

      There is a single model of memory management (garbage collection over ALL objects - lose them and the memory eventually returns - sometimes after a sudden "freeze" of the program). It is automatic and can't be replaced with improved handling of special cases.

      There is no strong typing.

      The environment is hostile to multi-programmer cooperation.

      The language design allows incomplete programs to appear to run, encouraging the release of incomplete and buggy programs.

      Methods (member functions) of subclasses (derived classes) are executed during construction of the superclasses (base class), invalidating the debugging of the superclass (base class) constructor.

      I could go on.

      Smalltalk is useful for throwing together a program to run once to get an answer to a question or sometimes to test an idea. It is totally unsuitable for the construction of mission-critical or commercial-grade applications.

      Since the problem here is to create an environment for writing code you want to DISTRIBUTE to a large number of people who will use them without being inside their development, it's an amazingly wrong language choice.

      • It's hard even to know where to start with that.

        The is no clear separation between the environment and the program.

        Okay, one point in favor of Smalltalk, IMHO. :-)

        There is no finalaization (destruction)

        I can't speak for every Smalltalk, but then what exactly am I telling my objects when I define a #finalize method for them and send them the #beFinalizable message in Dolphin? I'm relatively sure that other Smalltalks implement similar measures.

        There is no strong typing.

        Kindly review the meanings of strong/weak vs. static/dynamic typing. Smalltalk is strongly and dynamically typed. I don't necessarily disagree that strong typing is a good thing (under its correct definition, of course). The whole dynamic/static argument is considerably less clear, however, IMHO.

        The environment is hostile to multi-programmer cooperation.

        Please tell us specifically what is wrong with approaches such as StORE for Visual Works, or even less ambitious tools such as David Gorisek's Source Tracking System for Dolphin.

        The language design allows incomplete programs to appear to run, encouraging the release of incomplete and buggy programs.

        It's unclear that your premise implies your conclusion. It's also unclear exactly what your premise means. As you pointed out above, there is no clear separation between the working programming environment and a developed program. So how is it that an incomplete program is appearing to run? A modification or extension to the existing Smalltalk image actually is running. In contrast to your assertion that this results in buggy code, the typical Smalltalker would observe that this makes it a lot easier to test and correct code incrementally.

        Methods (member functions) of subclasses (derived classes) are executed during construction of the superclasses (base class), invalidating the debugging of the superclass (base class) constructor.

        I have an inkling what you mean by this, but I'm not sure. Would you mind posting a snippet of Smalltalk code to clarify it?

        It is totally unsuitable for the construction of mission-critical or commercial-grade applications.

        I will admit that I only know one massively successful Smalltalk "commercial-grade" application, viz. Visual Age for Java. OTOH, you might want to ask companies such as Sprint, FedEx, and various large banks about the suitability of Smalltalk for mission-critical applications.

        If you don't like Smalltalk, that's fine with me (it's not my first choice for most things either, honestly), but please don't spread misinformation about it.

  • Like small children... (Score:3, Insightful)

    by macpeep ( 36699 ) on Saturday September 15, 2001 @04:59AM (#2302378)
    Sometimes, I cannot believe the silly fights I see here on Slashdot. I'm a software engineer myself and I use both Java and C++, but for different purposes.

    At work, we write cross platform C++ code for a large number of platforms in a pretty large scale project. This is amazingly straight forward given a strict set of rules that everyone has to follow, but it also requires that you constantly test on all these platforms. The actual product that we are working on, is C++, like I said, and it would never even occur to us to write it in Java. Even if Java would be 80% as fast as C/C++, we wouldn't use it, because we want all the speed we can get. (yes, some of our inner loops are optimized in assembler - separately for every CPU that we support)

    However.. In order to be able to compile and test on all platforms, we needed a tool so that every engineer could just press a button and have the code compile and test on platform X. To enable this, we built a tool in Java, that checks out code from CVS, compiles it, and sends logs to a server where you can view the build logs with a web interface. From the same server, you can also initiate the compilation remotely on any one of the client machines (one per target platform) that are running the tool. This whole system is coded in Java, and just like would never occur to us to code the actual product in C++, it would never occur to us to code this tool in anything other than Java.

    It seems like everyone here is trying to prove that one particular language is best for all tasks. Guess what - that's not true. I see C zealots try to prove how slow Java is. Well, it's actually way faster than many believe. I see silly proofs that try to show that Java is slow by using benchmark apps that do string manipulation with String objects. If you write your own strcat, strcmp, strstr etc. in Java and use byte arrays, you'll find that string manipulation is about 70-85% as fast as in plain C - and that's fast enough for just about any purpose you can think of. Of course your productivity advantage is now gone.

    Just use whatever you feel comfortable with and whatever works for the application that you need to write. In most cases, you'll find that Java will be very nice forit. In other cases - like graphics and game programming, C++ - used wisely - is your best choice. Some dislike OOP and want to use C instead... Whatever gets the job done for you! I don't see why everyone has to prove that Java is "damn slow" all the time. Obviously, it's fast enough, as evident by the fact that a few millions programmers use it every day for real life tasks.
  • -It supports many processors.
    -It is based on TAO's Intent.
    -There are currently STABLE "runtimes" for Linux and Windows, with more in development.
    -It's faster than Java.
    -Most programs run faster through the runtime than they would if coded in C for a native OS.
    -It has already been adopted by Sharp.

    It's called AmigaDE.

  • My biggest beef about Java used to be that it was slow and not backward-compatible across minor versions. People are saying that Java is faster, and I believe them. However, it is becoming apparent that Java is only a first-generation cross-platform language, and it has many design deficiencies.

    Java's second-biggest problem is that it seems to have been designed to run on a virtual machine (or a piece of custom hardware), rather than being translated to native code. This is what made it inefficient for so long. IBM has done a great job of working around this problem, but if it wasn't a problem in the first place, IBM could have spent the time making Java even faster than it s now.

    The largest problem I can see with Java, though, it that you're tied to the Java language. This is basically assuming that the Java language fits all for anything that needs to be cross-platform.

    My preference right now is the Amiga DE. It's a translated (rather than interpreted) version of assembly language, which means GCC could (at least in theory) have an amigade target. My beef with the Amiga DE is the fact that it's a proprietary standard, which may have been fine 10 years ago, but it certainly doesn't fit into today's reality of open standards.

    IVM looks promising in that it seems to address all the problems I've stated above. I hope it does well.

    (Please excuse me bad English. It's not my primary language in the morning.)

Slashdot Top Deals

Utility is when you have one telephone, luxury is when you have two, opulence is when you have three -- and paradise is when you have none. -- Doug Larson

Close