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

 



Forgot your password?
typodupeerror
×
Java Programming

Java 2 & Hotspot on Linux in 2000 239

djKing wrote to us with the news that Sun will be releasing a "Java2-compliant JVM for Linux that brings the performance, functions, and Java HotSpot features of the latest Java specifications to the Linux community", which will be announced at the Java Developers' Conference. As well, IBM will be announcing the free general availability of a JSDK 1.18-compliant JVM, with performance better then that of Windows NT JVMs.
This discussion has been archived. No new comments can be posted.

Java 2 & Hotspot on Linux in 2000

Comments Filter:
  • Concerning the application part, here are some interesting links. I'm not saying that these are a good representation of anything, but just to show you that you CAN do other things with Java than dopey applets. These are some I came across at Jars [jars.com] which I think were interesting and/or useful.

  • by snorks ( 103191 )
    My company has been developing/deploying linux/java systems for 3 years now, and it's a winning combo. More attention to java on linux from Sun and IBM is a good thing.
  • I also believe that the hardware is so changing so quickly that language decisions made on the basis of performance are generally meaningless within a couple of years.

    Bravo! Absolutely. In some cases, though, maybe four or five years. My (recently deceased) AMD K6-2 PR300 (real clock 233Mhz I think) wasn't that much faster than an AMD K6 75Mhz at running Java. 4x clock speed won't necessarily translate into 4x execution speed because of other bottlenecks.

  • I've had no problems with JDBC or JFC using IBM JDK 1.1.8. I do cross-version tests using Borland's 1.1.6 on NT, IBM JDK 1.1.8 on NT, IBM JDK 1.1.8 on Linux, and had also been using a JavaSoft JDK 1.1.8 on NT. The 1.1.6 JDKs periodically behave oddly with JFC, but that isn't surprising as it's technically downlevel from what JFC requires (I was actually surprised it worked at all with 1.1.6.)

    I have had a lot of problems with JFC under Gnome, but it works properly with KDE and fvwm2. I found issues with the Triteal CDE itself with my latest kernel upgrades, but that affected everything -- not just the JDKs.

    The only "bug" I found with IBM's JDK is present on both the NT and Linux versions: it gave me warnings/errors on code that had been compiling clean for months. When I looked into the errors, I found out the IBM compilers were correct, and Sun's and Borland's hadn't been detecting and reporting the problem properly.

    My only complaint with IBM JDK 1.1.8 for Linux is that it's performance is comparable to Borland's 1.1.6 on NT, taking about 3-4 times as long as their NT version to run the same application code. My guess is that the problem is my use of CPU-intensive long-running threads -- there might be an issue with the way threads are managed on Linux.

    Speaking of CPU-intensive threads, I found I had to drop the thread priority to minimum in order to keep the GUI responsive under NT, but under Linux the GUI remains responsive even if I bump up the priority higher than default.
  • Then, as the other poster says, still use Java but get the best of both worlds - use Java for most of it for maximum portability, but use JNI for system programming tweaks. The idea that Java can't interface with other languages is simply not true.

  • With JavaVM startup overhead, it's 2.7 seconds real.

    Ah, as I suspected. A very big difference. As I said in another post, real-world Java processes usually last more than 9 seconds, so start up time is insignificant. Also, to repeat myself, if you wrap the whole code in a for loop with 200 iterations the JIT should kick in more, especially if it's Hotspot, and it should get much closer to C's speed for 200 iterations.

  • dear idiot, until there is a SOLID 1.2 JVM and ther is generally a VM release at the same time that windows and solaris get it, java is behind. in case you havent noticed 90% of the middleware, ecommerce servers, etc. are using java.

    sun is a business. they have shareholders and quarterly profits to make. generally speaking they are ok in my book - java is cool, its _relatively_ open (see IBM) and it will never reach teh level of ubiquity of ms. keep your eyes on reality...
  • I was too lazy to try replacing the StreamTokenizer - interesting to see how much it helped. I also tried replacing the ArrayList with a LinkedList, but didn't see much improvement at the time... good work!

    Again, it goes to show that with a minimal amount of profiling and a decent knowledge of the libraries you can really speed up slow Java code quite a bit.
  • I think that the Blackdown 1.2 pre-release contains the Solaris x86 JIT, which is OK but gets beaten badly by the IBM, Microsoft, and Symantec compilers. Sun even has a better JIT: their compiler for the Windows JVM is much better than the Solaris x86 compiler.

    You gotta figure that the recent turnover in Sun Java management is probably part of the recent decision to support Linux. Until the 1.2 pre-releases, the Blackdown VM didn't even include a compiler!

    Overall, having Hotspot on Linux, backed by Sun, is a very positive step.
  • CORBA was just the first example that jumped into my mind. And I agree with you. CORBA's too heavy. But that doesn't justify DCOM's existance.
  • Tim is an avid fan of Perl. When he teaches XML to his classes he teaches to parse it in Perl first, and maybe Java later.

    James Clark writes about 50/50 in C and Java.

    When you say "[Java] certainly isn't slower than Perl/PHP/CFML/etc" you are actually saying "[Java] certain is faster than Perl/PHP/CFML/etc" (just reverse the "isn't slower" into "is faster"). That's not the experience I and a lot of companies I've consulted for have had. YMMV.


    perl -e 'print scalar reverse q(\)-: ,hacker Perl another Just)'
  • I've been running the 1.2 JRE on Linux for a couple of months now. Must be some effort in there somewhere, eh?

    Microsoft's "Java 2" VM is only 1.1.4 compliant. Apple's best release so far I believe is 1.1.6 -- so while I 'm glad Sun is making announcements, I'm even more thankful that there are people like those at Blackdown who are working to make Linux a more viable platform. Java 2 servlet support has been a big boost to the Apache team as well.
  • You can't write big applications with Perl. You are not able to understand your own code in perl one week after you wrote it, if it has more than 30 lines. Perl can be faster and smaller than Java, but it is not perfect either.
  • by HRbnjR ( 12398 ) <chris@hubick.com> on Monday October 18, 1999 @05:18PM (#1604140) Homepage
    First, to those who think Java is closed, let's get it straight, Java is open...Suns _implementation_ of Java is closed! Anyone can download and implement the Java spec...as several have. And Sun is at least attempting to achieve some consensus and standardization for what they create, which is a hell of a lot better than most other companies (how many people did MS ask for input on, say, DCOM???).

    Sun's implementation of the spec may be closed, but it is still more open than a lot of other closed software. Their community source licence, if not that great, is at least a step in the right direction, and if other companies took this step, we would be decidedly better off. It takes time for the corporate world to embrace, understand, and experiment with open software...Sun is heading it the right direction. Keep in mind, they have to make money to survive. Eventually, given the same time C/C++ has had, there will be many good open implementations.

    Java being an open specification, with independant, and open implementations, makes it as open as anything else in this world. Just because there are closed implementations, doesn't make Java closed. If Sun started charging $10,000 for their Java implementation tomorrow...what would happen? The whole community would start working on Kaffe, and you can bet IBM (with all they have invested) would do a cleanroom and open source it, but basically, life would go on without Sun. What would all the Visual Basic programmers do if MS started charging $10,000 for VB? Look at how many people use VB! (Don't even get me started on comparing them)

    As for Java changing "every five minutes" as some people like to quote, or about it being unstable and buggy. Well, that's true, or at least it has been in the past. But Java is a really new language!!!! I'll say it again...it's new! Java, like Linux in some ways, has been pushed into the spotlight before it's time, because it fills the need better than any of the alternatives. I think Sun has done a great job of moving the languages features forward quickly enough that MS can't hijack it by adding missing/needed features that will in turn tie Java to Windows. Being a full time Java developer, I could never go back to C++/Win32, despite the bugs, and a _few_ missing bits here and there, Java is a _great_ language to work with. Stability and speed, and more open implementations, these will all come with time. Actually, Swing is becoming useable, and the new JIT's are actually quite fast on "reasonable" hardware.

    Java is just now really starting to become a viable platform. Linux is in the same vote, it's a relatively new operating system, and is still evolving at a pace at least as quickly (or more) than Java in areas such as multimedia, multitrack digital recording, DVD, USB, component architectures (KOM/Open Parts), etc.

    Most importantly, Java is the only real chance Linux has of putting down windows in the enterprise. Even once all the productivity apps are in place on Linux, and the interface (Gnome/KDE) blows away Windows, and it's easy enough for grandma to install, the MS installed base is going to be the problem. Java gives companies a way to easily migrate from Windows to Linux. Java is the link that will let this happen. Normally, convincing a MS based company to develop their inhouse software on Linux would be impossible. But Java is a good language for _MANY_ other reasons than being cross platform, which will get companies to use it, even if it's only on top of Windows. Then one day, when they discover Linux, they will find that they can slowly (or quickly) throw away their Windows boxes without spending a trillion dollars migrating a myriad of software all at once. Without Java, it will never happen.

    That is why Linux and Java are a good match.
  • i've heard that linux is getting a fast tcp/ip stack someday...and a journaling filesystem too.
  • Hmm, I've been successfully using the IBM JDK in places where both the Blackdown 1.1.7 and 1.2 JDKs barf thread dumps all over the place. This is even using the IBM JDK with native threads and the JIT on multiprocessor machines. The only thing I've seen it not do is be a Java2 JDK.

    I know there are some serious problems with native threads on anything less than kernel 2.2 and glibc 2.1.

    -=-=-=-=-

  • by Anonymous Coward
    >I'm wondering if anyone out there uses Java for
    >something useful. Perhaps I sound naive, but I've
    >never seen it deployed beyond annoying applets or
    >slow as molasses games in COS246 (Java Programming)

    Well, the company I work for has a rather large internet app (read millions of users) that is run entirely with Java and Oracle. While much of the development is done in linux, all of the servers are solaris, primarily because of the superior jvm. A great jvm would go along way to further our arguments to try out linux on the production side.

    chris
  • Blackdown has had a Java 2 release for a while now. They have put a lot of effort into this and previous releases. They have put up with being at the bottom of Sun's list and generally being ignore, and they have been able to keep within a few months of Sun's releases anyway. Sun has been promising to keep them better informed for years now, with no change of policy. Blackdown has been doing an excellent job.
  • My issue with the Blackdown port is that, beautifully compliant as it is, it lacks a JIT compiler. My benchmarks make the Kaffe JITC about three times as fast as the Blackdown JDK's interpreter. I consider interpreted Java unusable -- making my computer three times slower (at least) than it should be is not acceptable.

    I'm withholding judgement on JITC'd Java as I haven't found at JITC that will run everything. Kaffe will run my little toy tests, but it dies when trying to run a real app like NetBeans (which is apparently pretty evil, they recommend not running with a JITC). NetBeans under the interpreter runs like it was on a 386. I just downloaded the IBM JDK 1.18. I'd really like to port some Java stuff to C++ and compare for speed. Anyone know of any similar benchmarks that have already been done?
  • As I am currently employed in my second job involving a large scale java server application, I can say without a doubt, yes, yes, most emphatically yes, people write real software in Java.

    Sometimes we have regrets, but I had those in C and C++ too. On the whole, java has been a great step forward. It could be a heck of a lot better but it is more than usable right now.
  • Except you are always programing for the lowest common denominator ... you WANT to use all the neato performance tweaks that only SYSTEM PROGRAMMING can expose.

    Such as ... ? You are now going to list all the things you can only get from "SYSTEM PROGRAMMING" that Java doesn't offer, aren't you? Or are you?

    Didn't think so...

    Seems to me that multithreaded Java apps seem to scale pretty well just from throwing more and faster processors at them as long as you're actively using multiple threads, from a single-processor laptop for development to a dual-processor Linux box for testing to a multiprocessor Sun for deployment it's pretty linear.

    -=-=-=-=-

  • Borland are also previewing a Java 2 JIT

    http://www.borland.com/about/press/1999/jitlinux 1.html

    which can be downloaded
  • From the article referenced:

    Information on a fix should be available on Microsoft's Java Web site.

    So, ZDNet Labs, this would be that central repository of patches you were looking for? Oh, wait, let me jump to the Office page to get those patches, then the IE 5 page...


    --

  • If you really want the URL of a Java application of relative complexity, try:

    FreeBuilder [freebuilder.org] - An IDE in Java.
    Argo/UML [uci.edu] - A UML editor with cognitive support
  • He says "usually",not "always" and I agree.

    And dont come mentioning names of programmers, do you think Joy and Gosling are idiots?
  • I can appreciate Transvirtual's need to make a buck just like the rest of us. However, Microsoft's prime objective was to sabotage Java. It is unfortunate that the otherwise decent folks at Transvirtual were sucked into Microsoft's game. (Analogies could include black actors playing stereotyped roles or Soviet-puppet leaders in east Europe.) The unfortunate result is the spread of Microsoft's pollution in the world of Java programming.

    Sun also has to make a buck. However, as I see it, Sun has a history of making a buck by giving the world new and useful technologies. This is in contrast to Microsoft's history of disabling and destroying new and useful technologies, like CORBA. (This is why Microsoft is the devil.)

    Sun has to walk a fine line between too open and too closed regarding Java. If too open, Java fragments. If too closed, Java withers. It is certainly debatable as to whether or not Sun is following the right path. Many, such as HP and yourself, portray Sun as Java control freaks. And I admit, you are in a better position to judge than I am.

    But to me, it looks like they have done a reasonably good job shepherding Java. The rate of progress in terms of functionality, stability, and performance has been tremendous over the past four years. The documentation is comprehensive, the tools are free, and the source is available.

    Maybe I'm naive, but I wouldn't be surprised at all if, when Java stabilizes over the next few years, that Sun hands off the responsibility for Java to some standards body like ANSI. Let's not forget some of Sun's other contributions like NFS. Let's also not forget that Sun is primarily a hardware company.
  • One point you forget to raise is that for most purposes, UI code doesn't have to be very fast.

    Which is in line with what I said (a couple of posts above) about most prgrams being I/O bound more often than CPU bound -- most GUIs spend the majority of their time waiting for input. Of course, fast or no, I'd still like to see cleaner redrawing -- I often have windows that aren't redrawn because some action is being performed. (Yeah, I know I could start the action off in its own thread, but sometimes that's overkill...)


    --

  • okay but they havel ike 90% marketshare on the client - not supporting that would be suicide (you think sun LIKES windows???)
  • by cbj ( 3130 )
    Both Japhar and GNU Classpath [classpath.org] are active projects. Japhar could use more really good active developers, but the same is probably true for Classpath.
  • okay so now can you anti-sun bigots quit whining? obviously sun is nervous about linux threatening solaris but this is a good step, especially in light of jarkarta being released recently. linux and java should be friends - its a good match and hopefully this is just the first step in their collaboration.
  • Just because they stipulate that they own the spec, which they do, by copyrighting it, doesn't mean they don't make it freely available for anyone to use and implement. You can copyright something you GPL, just as you can release something that is yours under multiple different licences.
  • Technically, the Volano tests were conducted on Kaffe 1.0b4, not 1.05. Among the release notes, Kaffe claims the new JIT "improves raw execution speed by a factor of up to 3". It also uses native Linux pthreads, which should be beneficial to real-world multithreading. And then benchmarks are benchmarks... "benchmarketing" should be avoided on both sides.

    At any rate, given significant changes to the JVM and threading model, the Volano results aren't totally applicable.

    ---
    Maybe that's just the price you pay for the chains that you refuse.
  • It's been a sick joke that the best java platform was windoze. Time to bring it on home.
  • John's views on this is expressed in his .plan. If it is fast enough he'll do it. Check out the Java 3D/2D/advanced imageing.
  • I believe that IBM's support of Java is highly unlikely becuase I recently spent the summer at a large IBM shop (CICS and COBOL-based) doing Java-based programming. We wanted to take some of the CICS-based processing and change them to a Java EJB architecture. Whenever we tried to get a straight answer out of IBM, they dragged their feet and gave us the run-around.

    They first said that it was easy to use Java on the OS/390 (err, MVS...) and CICS. Understand that there were thousands of legacy COBOL programs and CICS transactions that we could not afford to break in switching over to a new architecture. The Java implementation would also have to talk to our databases (ancient VTAM) in order to maintain legacy conversion. But, we asked IBM for an example on how to do this. They could not provide one. We then asked for when Java would even be available as a CICS language (write the Java base and have a CICS-transaction wrapper). Well, in order to do this, IBM said that we needed to write a C-wrapper around the Java code so that our legacy COBOL code could continue to talk to the functions (i.e. COBOLJava is not supported). Not an acceptable answer. We went around and around while we got shuffled from division to division. No concrete answer ever appeared from IBM. We finally came to the realization that IBM wants nothing to do with Java... Any solutions would have to be off-the-shelf (and not IBM).

    The poor guy who was talking with IBM kept trying and got the run around. One day, he'd tell his bosses that we can do it, the next, he'd have to report that IBM said it couldn't be done.

    That said, I would not be shocked to see IBM support it in their lower-level servers, but from my experience this summer, they do not want anything to do with Java on their enterprise-class mainframes.

    Justin
  • What with Sun releasing a Java2 compliant JDK for Linux, what will happen to the Blackdown efforts in this area?
  • The IBM port of the JDK for Linux had compatibility issues, which made it worthless as a java compiler. Blackdown's Java 1.2 for Linux is actually really really good. I've played around with it and there are a few bugs to work out, but otherwise it's wonderful. If this is the base that Sun will be working off of, they're in good hands.

    Oh, and - It's about freakin' time :)

    -----------

    "You can't shake the Devil's hand and say you're only kidding."

  • This would be very nice if it's true. Unfortunately, about 50% of the promises we hear about Java turn out to be greatly exaggerated, or vapor. (I say this as a Java programmer, and strong advocate) I'd really like to see Linux become a strong Java platform, as this would make writing software for Linux much less of a "?" Imagine writing a piece of software that runs both on Windows and Linux, and the same code runs better on Linux, and is kludgy on Windows... Wouldn't that be a thrill! :)
  • Sun's implementation of the spec may be closed, but it is still more open than a lot of other closed software. Their community source licence, if not that great, is at least a step in the right direction,

    I have to disagree - I would rather have Java closed without comprimises than open with such glaring, crippling comprimises.

    When it comes to licenses, I'm a stickler - it has to jive with the open source model certification.

    Otherwise, you get on a slippery slope...with virtually closed licenses proclaiming to be open.

  • It seems to me that this setup -- Linux and Java2 -- is ideal for embedded systems and variegated non-computery apps. No mench was made of this in the report, though; so either the didn't bother or I'm deeply misinformed. Which is it, I wonder?
    I was also surprised by the anti-NT stance the story takes; it's and IDG story after all. Have I been misjudging them?
    Okay, so that was questions rather than statements. Sorry. Won't happen again.
  • This appeared today on Technocrat. I hold the copyright of the article, so I can paste it in here.

    Transvirtual and the Kaffe Core Team have released Kaffe 1.0.5 (finally!). It's got a new JIT, new processor ports, a clean-room RMI implementation, kernel threads, and much more. For more information see http://www.kaffe.org/ [kaffe.org]

    Transvirtual Technologies, Inc. today released Kaffe OpenVM 1.0.5, the only complete Java implementation available with a true Open Source license.

    The release heralds a major improvement in the reliability and performance of open source Java implementations. Tests conducted with various Open Source server side Java applications, including the popular Apache/JServ webserver and the Enydra Java/XML Application Server, demonstrate Kaffe out performs its Java Linux rivals by as much as 300%. Kaffe also proves more reliable than other Java implementations which simply hang when running under heavy load.

    Transvirtual targets Linux as their primary server-side, desktop and embedded environments. Kaffe, developed using the Open Source model, once again demonstrates how Open Source can offer a better, cheaper, faster and more reliable product than proprietary alternatives.

    This new release of Kaffe also offers a number of new features, including:

    * Bundling of the KJC Java compiler from Decision Management Systems (http://www.dms.at/kopi) - a complete JDK 1.2 Open Source compiler suite.

    * A complete Remote Method Invocation implementation written in collaboration with the GNU Classpath project (http://www.classpath.org).

    * Support for the the popular Cobalt Network Web Servers.

    * Support for the MIPS and StrongARM processors (Kaffe already supports Pentiums, Sparcs, Alphas and Motorola processors).

    For more details on Transvirtual Technologies see their web site [transvirtual.com].

    For more details on the Kaffe Open Source Project see The Kaffe Project Web Site [kaffe.org].

    All names and trademarks are the property of their respective owners.

  • Just-in-time (JIT) compiling at run-time allows frequently called routines to run at the same speed as native code, after the initial performance hit. This has shown a huge positive impact on server side applications, where programs run for long stretches of time.

    Java can also be natively compiled, though there are few available compilers (commercial or otherwise). As a compiled (or JIT-compiled) language, the major speed bottleneck is garbage collection -- performance is comprable to C/C++ with a garbage collection package.

    Of course, the AWT package (for graphics) is not particularly impressive, either in speed or in basic window management such as redrawing.

    Also, remeber that execution speed is not the only measure of a program. Java is easier to write and maintain than the C variants (from anecdotal evidence). From personal experience I tend to agree -- I know C++ better, but I'm still faster to develop and debug in Java. Most programs do not use the CPU 100% of the time anyway; there is often some I/O bottleneck.


    --

  • You don't know anything about Java do you?

    End-of-Thread

    -=-=-=-=-

  • This is just vapor. Guess what? IBM, Inprise, and Transvirtual have DELIVERED java on linux. OK, Inprise is really just a JIT for Blackdown. But it's something, and it's commercial. Sun is blowing smoke in the hopes of taking the wind out of their sails. Disgusting. Sun becomes more like Microsoft every day. And why not? What business would not want success like that? Keep your eye on the sparrow...




  • You can download the Borland JIT, free, here [borland.com]. We measure it to be 30% faster than then JIT included in the current JDK 1.2 for Linux.
  • Why would Sun, who have done so well in differentiating themselves on the server side with the best compilers, best RAS, most scaleability want to flatten out the software landscape? It just doesn't make sense from the standpoint of strategy.

    My guess would be that they are probably counting on having the best Java tools. Also, with a flattened software landscape that they essentially control, it will be easy for all of the shops using NT to move on over to SUN hardware for better performance.

  • On the server side, you want platform DEPENDENCE, not independence. You might as well get something out of an E10000 running Solaris once you've spent the money on it - you WANT to use all the neato performance tweaks that only SYSTEM PROGRAMMING can expose.

    It would be better to keep the platform dependence part of things hidden inside the JVM/JIT. Sun, the people who build the machine and are intimately familiar with its capabilities, should do the performance tweaking for you inside of the JVM.

  • by Trojan ( 37530 )
    I suppose people won't mind too much if I use this place to point out that 'better than' is the correct spelling.
  • Because Sun wants to be the high end solution. Linux/Intel is a low cost solution that small shops can get started with. Sun wants those shops to be able to ramp up easily to Solaris on Sun hardware when the load gets to be high and the IPO has brought them plenty of $$$ for new iron. Java on Linux is one way to make sure customers will be walking down Sun's road when it's time to grow. No Java on Linux might mean that the business starts out with Linux OSS solutions (Perl, Zope, etc.) or NT/Intel using VB/COM or Microsoft Java with Windows specific features and will be forever trapped into that technology. Then Sun gets nothing. At least with Java, Sun gets to inject a little bit of itself into everyone's world and get a little leverage.

    It makes sense for Sun to push Java on all the low end platforms. Since there are invariably parts of the business that do not run on Java, it is clear that people could migrate to Sun hardware/Solaris/Java more easily from Linux/Java than from NT/Java simply because Linux shares a common Unix denominator with Solaris.

  • True, that's the only thing i hate about it. But then, if all you develop is components, it doesn't really matter.

    I'm generally using Java as a replacement to VC++/MFC and VB, so I'm not particularly worried about Swing. WFC is quite fast (considering it's just wrapped ActiveX controls).

    I'm betting that MS won't include a Swing form builder in VJ++ 7, but will rather including AFC (Application foundation classes), which IMHO look and work much better than swing. They're also written in 100% java, and have all the windows type functionality that swing lacks. (someone needs to teach sun about GUI design).

  • Can you post the input data too? And the perl version? It's trivial to make modifications to this Java code to speed it up by 5-10 times.

    This code doesn't prove anything about Java's execution speed. It just proves that buffered I/O is more efficient than reading a byte at a time.

    Any Java programmer who has more than a few months experience will immediately spot the
    problems.

    1) Doesn't use buffered I/O at all. A trivial one line fix adding either BufferedReader or BufferedInputStream would boost speed tremendously.

    2) Usage of StreamTokenizer on an interactive stream. A bug in JDK1.0-1.2.1
    http://developer.java.sun.com/developer/bugParad e/bugs/4150737.html

    3) Usage of synchronized Vector and Hashtable operations instead of ArrayList and HashMap.

    4) Usage of StreamTokenizer! Use BufferedReader and indexOf() or StringTokenizer instead.


    Like Linux vs NT, let's not post "cooked" or "biased" benchmarks. The only real way to run these sorts of benchmarks is to have a contest between C++, Java, Pyhton, Perl, and C coders, and have the final result judged on speed of execution, speed of development, clairity, and ease of reuse and maintainability.



  • Actually, I think most experienced server programmers are already well versed in COBOL, RPG, or Smalltalk.

    C++ on the business enterprise server? Sure, it exists, but, uh, it didn't really work out too well. That is why this Java thing is pretty popular... it's the successor to the server-side languages that DID work. [Though i'd argue that the successor to Java should ironically be Smalltalk , but, that's for another time]

  • try NetBeans running the IBM JDK 1.1.8.

    It's a decent speed.

    for compiled Java code, try Borland JBuilder... it's a memory hog, unfortunately.
  • The "official Sun blessing" was given back in August 1998, and did next to nothing with regard to speeding the emergence of a Java2 environment on Linux. The fact that IBM is going to soon release a good JDK on Linux in a few months has spurred Sun to _finally_ give in and release an official (and, IMHO probably (intentionally) buggy) Java for Linux port, so as not to completely lose face. You can bet your bottom one that 1.2.3 will be out for most other platforms shortly thereafter, again leaving Linux a few revisions behind.

    Why? Because, while Sun wants people to be able to leave M$-land, they want them to leave it for Sun-land, and that generally doesn't mean going to Linux.

  • maybe i'm clueless here (well probably), but i've heard about jdk1.3's performance being above the performance of 1.2, on the client side especially. The question I have is why don't they just skip porting 1.2 and port 1.3? And why doesn't IBM just skip a few versions too?
  • I don't think it will happen (I would like for it to happen), Sun hasn't really done anything for the linux community. The released a sorta free version of solaris and someone came up with an app that will run linux apps under solaris but they don't really seem to want to work in the linux world. Can anyone tell what they've released that is Linux based?

    Of course I could just be too paranoid but I doubt it. Lots of folks see MS as the big evil threat but I think that Sun is also doing stuff, just not as obvious...

    And remember that MS doesn't have the large system market, those are solaris machines we're going up against when Linux scales better. (And I can get a 16 processor AMD card :-> ).

    Now if I could just figure out IBMs motives..

    bobm
  • Fine, so long as the company you are working for (which has enough revenue to justify using the big iron) is happy with throwing away your code when they realize they want to move up to the next big piece of iron a year later, which may or may not be a Sun box, or capable of supporting your server-dependent tweaks.

    IMHE(xperience), the programmer resources are vastly more expensive than the iron (if they are not then your dollars are being spent in the wrong places -- or you have management which excels in getting great programmers for cheap prices (in which case they aren't getting as good a deal as they think)). Re-engineering code for a move to a new platform because you NEED to move to the new platform is very expensive.

    Good management will hire good people to do it right the first time (portable, with the right algorithms, and rock solid code) and deploy it on the right systems with an eye towards potential changes in platforms down the road.

    One might argue that isolating platform-dependent code into its own "module" (depending upon what a module is in your language of choice) is the solution -- your server-dependent tweaks go there, and that's what changes in the future. Point taken, but then why are we arguing about not using Java then: that's exactly what JNI was designed for.

  • This is exactly the news i *NEED* to hear. Now if only the Java Plugin for linux was out. There once was "activator" but that is nowhere to be found.

    Reason being, we deploy Oracle Applications Release 11.0, as do thousands of other enterprise companies, and thier is no way for clients to currently connect as there is no good java VM nor is there a working plugin.

    amazing alot of enterprise features need java, a pure java vm would make it easier for Veritas to port its file systems & management software over, oracle applications could work, and just a bunch of business reporting and system software could fall in.

    Can't wait! i'd say in the next 6 months, linux will have a system with all the features, and be able to innovate more instead of play catchup.

  • > Of course, the AWT package (for graphics) is not
    > particularly impressive, either in speed or in
    > basic window management such as redrawing.

    The AWT may be slow, but it's a beautifully designed API. Our company does a lot of UI prototyping (UIs that need to be driven by massive amounts of actual data); each of our UI toolkits is built for rapid development, flexibility, and visual snazziness. These toolkits go through several iterations every year as they are tuned and refined -- without the simplicity and elegance of the AWT's rendering model, we'd be pretty screwed.

    Granted, none of this stuff is intended for massive deployment on anything other than an intranet that's within the tight grip of a professional IT manager. The clumsy manner in which the JVM must be invoked under most OS's (mucking about with classpaths, command line invocation, the crappiness of netscrape- and ie's JVM) and, yes, the abysmal speed of more complex Java UIs severely hampers the wide distribution of Java user interface applications to Joe User.
    Just YAAWSHSTP (Yet Another Area Where Sun Has Screwed The Pooch).
  • ignore the last sentence. and i'm referring to ibm in the one before that.
  • by Anonymous Coward
    I have been steadily converting my old code to java so that I can reach a greater audience. For most apps, LudicrousSpeed is a small trade for cross-compatibility. The process of writing once and running anywhere has worked flawlessly for me - I'm not a big developer but the niche seems to be growing - check out jars.com
  • too much caffine. sorry.
  • by rcromwell2 ( 73488 ) on Monday October 18, 1999 @01:34PM (#1604219)

    In terms of academia and research, if you look at the IETF and W3C, almost all "new" protocols start out with Java prototype implementations. This is particularly true of the W3C. Jigsaw, XML, XSL, P3P, SVG, ...

    If you look at commercial websites, E-Trade and Datek come to mind, you'll see Java on the backend.

    My own free pop/webmail/antispam service msgto.com) uses Java for everything, JSP, servlets, SMTP, POP server, etc. It's also
    faster and more responsive than Hotmail.

    Yesterday, two spammers took "revenge" on our site by redirecting spam bounces to my site. In a
    10 hour period, about 1 million bounced messages were received and discarded on a lowly dual-processor Solarisx86 box. Even now, we are getting about 10 messages per second but 'top' shows only 10% CPU utilization for the JavaVM and 30M memory used. Java definately scales.

    Solarisx86 was used for only two reasons. One, when development was started, JDK1.2 wasn't available on Linux, and our servers use JDK1.2 heavily for its new garbage collection/memory management features and fine grained security.

    Second, Solaris can scale to thousands of threads across multiple processors. Only TowerJ on Linux allows massive numbers of threads (by not using kernel threads), and Java's I/O mechanism relies on launching large numbers of threads. But TowerJ is not JDK1.2 compliant: bummer! Otherwise, I would love to have a bunch of rackmounted VA Research boxes.


    The only place Java really failed was on the desktop application area. But I'm of the opinion that the general trend is that we are moving away from desktop applications and more towards web-based applications. So in a sense, most new desktop apps will fail, regardless of the programming language they are written in, and especially those that try to compete with areas Microsoft dominates. When was the last "killer-gotta-have-it-client-side app created" I can't think of many besides games, browsers, and other multimedia related utilities.

    In the past, if you wanted to manage an address book, or a database, someone would ship you a VB or some other 4GL based app, that displays forms on your desktop and inserts them into the DB. Nowadays, most of these apps can be done on the network. This covers most business uses.

    What's left for the desktop apps is multimedia. Music, Games, animation, art.


    This Sun/IBM announcement is great news. I only wish that IBM would come out with a JDK1.2 compliant VM, because IBM seems to be alot better at optimizing VMs.

    -Ray
  • Can you get NetBeans to load?

    I installed the 1.1.8 final for win32 and Linux. The win version runs Netbean 2.1.1 fine, but the Linux version won't.

    Have I installed wrong? Help.
  • "remeber that execution speed is not the only measure of a program"

    tell that to an end user that is waiting. They don't care about that. They just wonder why is that so slow.

    I have done a little Java programming, and think that it is a really nice language to program in. IHave you tried Tcl/Tk thou? It is a scripting language that is similar to the Java programming language, only not with as many methods available.

  • I don't think it'll ever happen, but J++ just rocks :D~~~~.

    Instant compiling...takes 2 seconds, not 20 seconds to compile tens of classes.
    Intellisense, detects installed packages and lists methods and properties as you type etc etc.
    Hell, intellisense even extends to javadoc blocks in java, so you type @ and it'll like @param @comment etc etc.
  • I fixed up the code a bit (I assume that there were supposed to be a less-than sign in all the for loop comparisons?), then compiled it and converted it to use the new Collections code and fixed the problems with deprecations. I fed an English-Latin dictionary I had on hand (wc says it's 8340 lines and 41178 words). The revised code is posted at the end of this message, but to start with here are the timings (all on a P450 in Win98 using the Sun VM) all timed with the Cygnus "time" utility, which works pretty much like the unix time command. I took the average over a number of runs to get these numbers, but they are still rather rough.

    Jdk 1.1.8:
    Original Code - 7.30 seconds
    Revised Code - 9.23 seconds

    Jdk 1.2.2 (Current production release)
    Original Code - 5.05 seconds
    Revised Code (com.sun...collections) - 5.38 seconds
    Revised Code (java.util collections) - 5.0 seconds

    Jdk 1.3 (Beta release)
    Original Code - 3.79 seconds
    Revised Code (com.sun...collections) - 4.40 seconds
    Revised Code (java.util collections) - 4.20 seconds

    Analysis:
    This surprised me a bit. As seen above, my "enhancements" actually slowed down the program a bit! I think this might be partly due to my replacing the for loops and get(int) calls with iterators, which is easier on the coder but didn't lend itself much to JIT based enhancements. This goes to show that no matter how smart you think you've been, you should always run an optimizer over your code from time to time and figure out why it is slow in some areas you would not expect slowness...

    It also seems to show that syncronized calls are not really hurting us much, though that might be reading too much into the results.

    But what should be very obivous and exciting (nad even quite relevant to this article) is the DRAMATIC speedup from the 1.1.x VM to the 1.2 or 1.3 VM!! About a factor of two in this case. I think that should help demonstrate why we want a stable 1.2 VM on Linux quickly.

    Here's the code for those interested - note that to use the 1.1 collections package you just need to import com.sun.java.util.collections.* at the top of the code. That's how easy it is to switch upwards as well, everyone should start using the new collections package right away!

    ----------------------
    /* Copyright (C) 1999 Lucent Technologies */
    /* Excerpted from 'The Practice of Programming' */
    /* by Brian W. Kernighan and Rob Pike */

    import java.io.*;
    import java.util.*;

    class Chain3 {
    static final int NPREF = 2; // size of prefix
    static final String NONWORD = "\n";
    // "word" that can't appear
    HashMap statetab = new HashMap();
    // key = Prefix, value = suffix ArrayList
    Prefix3 prefix = new Prefix3(NPREF, NONWORD);
    // initial prefix
    Random rand = new Random();

    // Chain build: build State table from input stream
    void build(InputStream in) throws IOException
    {
    Reader r = new BufferedReader(new InputStreamReader(in));
    StreamTokenizer st = new StreamTokenizer(r);

    st.resetSyntax(); // remove default rules
    st.wordChars(0, Character.MAX_VALUE); // turn on all chars
    st.whitespaceChars(0, ' '); // except up to blank
    while (st.nextToken() != st.TT_EOF)
    add(st.sval);
    add(NONWORD);
    }

    // Chain add: add word to suffix list, update prefix
    void add(String word)
    {
    ArrayList suf = (ArrayList) statetab.get(prefix);
    if (suf == null) {
    suf = new ArrayList();
    statetab.put(new Prefix3(prefix), suf);
    }
    suf.add(word);
    prefix.pref.remove(0);
    prefix.pref.add(word);
    }

    // Chain generate: generate output words
    void generate(int nwords)
    {
    prefix = new Prefix3(NPREF, NONWORD);
    for (int i = 0; i nwords; i++) {
    ArrayList s = (ArrayList) statetab.get(prefix);
    if (s == null) {
    System.err.println("Markov: internal error: no state");
    System.exit(1);
    }
    int r = Math.abs(rand.nextInt()) % s.size();
    String suf = (String) s.get(r);
    if (suf.equals(NONWORD))
    break;
    System.out.println(suf);
    prefix.pref.remove(0);
    prefix.pref.add(suf);
    }
    }
    }

    class Prefix3 {
    public ArrayList pref; // NPREF adjacent words from input
    static final int MULTIPLIER = 31; // for hashCode()

    // Prefix constructor: duplicate existing prefix
    Prefix3(Prefix3 p)
    {
    pref = new ArrayList(p.pref);
    }

    // Prefix constructor: n copies of str
    Prefix3(int n, String str)
    {
    pref = new ArrayList();
    for (int i = 0; i n; i++)
    pref.add(str);
    }

    // Prefix hashCode: generate hash from all prefix words
    public int hashCode()
    {
    int h = 0;

    Iterator i = pref.iterator();
    while ( i.hasNext() )
    {
    h = MULTIPLIER * h + i.next().hashCode();
    }
    return h;
    }

    // Prefix equals: compare two prefixes for equal words
    public boolean equals(Object o)
    {
    Prefix3 p = (Prefix3) o;

    Iterator i = pref.iterator();
    Iterator i2 = p.pref.iterator();
    while ( i.hasNext() && i2.hasNext() )
    {
    if (!i.next().equals(i2.next()))
    return false;
    }
    return true;
    }

    }

    class Markov3 {
    static final int MAXGEN = 10000; // maximum words generated
    public static void main(String[] args) throws IOException
    {
    Chain3 chain = new Chain3();
    int nwords = MAXGEN;

    chain.build(System.in);
    chain.generate(nwords);
    }
    }

  • by Anonymous Coward
    Sun publishes a freely-available spec for Java, with a trademark and certification ("100% Pure Java"). As far as I can tell, anyone is free to define and implement a variation as long as they don't call it Java. If you're thinking of the Microsoft suit, Sun is alleging they signed a contract agreeing to implement Java as specified and then broke that contract. That they may have used source licensed from Sun to do it (possibly against the terms of that license) clouds the water further.
  • Of course, that is thier task to try and make Solaris the biggest baddest thing you can get, so at some point you say "I really have enough load on this box to need the reliability and pure hugeness of a sun E10^30 box". What's wrong with that? The fact is that you can also decide that that HPUX 10^30 box might be as good for you, and it will still work as an EJB solution. Or you might find IPlanet a nightmare to work with, and decide to switch to another web server... it doesn't matter as long as you've not strayed from the EJB standard.

    Where you might argue with more force (or at least as much force as an AC argument can have) is to say "Sun will try to always produce Java features quickly enough that only Solaris can have a good VM and thus people will want the Sun box". Now that might be closer to the truth, but there are enough other people producing good VM's (IBM, Kaffe) and working with Sun in specifying standards that I just don't buy that argument as working for Sun even if that is their plan.

    So I guess my stance on that would be that even if you are correct and Sun has an evil plan in mind, that it won't work anyway so it doesn't matter - the programmers always win in the end. I personally don't think Sun has an evil plan so much as it wants to promote UNIX in general.
  • Sun seems like they are being dragged around by Java these day.

    It continued to be such a joke and a failure on the client side for so long that they had to play up this server side story for it. They've completely lost sight of what Java was going to do for them.

    There was once a coherent strategy in pushing Windows off the desktop in favor of thin-clients, but now, well, it's hard to imagine that you could field a thin-client that could compete with commodity thin-client hardware based on PC components. So, even if, and it's a HUGE if, you could displace Windows (and Linux) on the desktops, you'd still have to talk to PC hardware being used as thin-clients. Seems like a win for Intel or StrongArms maybe, but not for Sun.

    So, Sun turns toward the server and middleware for Java dominance. This seems like a move of desparation, to show SOMETHING for their Java investment. If they succeed at flattening the server side with write-once-run-anywhere Java applications, they will have succeeded in commoditizing the server side.

    In such an environment, you'll have IBM, HP, Windows NT and some large number of commodity server Java boxes (made in the far east) to compete against. Why would Sun, who have done so well in differentiating themselves on the server side with the best compilers, best RAS, most scaleability want to flatten out the software landscape? It just doesn't make sense from the standpoint of strategy.

    Sun is being pulled around by the nose by a Java Strategy that's taken on a life of it's own. They pay $500,000,000 for the world's most popular Java application (StarOffice, which BTW uses C/C++ on the server side) only to give it away apparently in a desparate attempt to legitimize Java on the desktop. They now have to support the development of Java on their biggest up-and-coming competitive environment, Linux, to make sure that the phenomenal growth of Linux doesn't marginalize their precious Java. It seems crazy.

    At the end of the day, what large server side applications will be written entirely in Java? All of those systems will have working C/C++ compilers, after all. With C/C++ you should be able to get much greater performance, stability, more immunity to environmental changes, less developmental headaches (no nervously watching evolving Java standards) and more qualified programmers (most good Java programmers are good C++ programmers, but not vice versa).

    I can see Java used like stored DB procedures, and for various kinds of utility programs, middleware glue, quick projects, you know, all those things that Perl does quite adequately already, but take over the server side? How? If anybody dares to field a commercial package written in Java, someone else could beat them up with one written in C/C++.

    This is the essential point that people don't seem to understand about C/C++. Your operating systems are written in them for a reason. Because your operating systems are written in them, they will always be the most stable and mature compilers available. Because this is true pretty much everywhere, they will be the standard in portability. Maybe not the kind of VM portability where you can compile it here and it will migrate over to execute somewhere else, but what does that buy you over just having good C/C++ compilers everywhere (which you already do, see above).

    Java is probably a better language than C++ because of garbage collection alone (and there are other significant advantages), but you need more than just better to displace a truly ubiquitous language like C/C++.

    From my perspective, I see far more developers using Java than users for the forseeable future.

    When some wide-eyed Java fanatic tries to tell me that everyone will be using Java next year, I'm reminded of the Amway guy who told me 10 years ago that I could be making $90,000/yr. in just 90 days with Amway, much more in 6 months. I told him to go away and come back in 90 days if he was making $90,000/yr. Needless to say, he wasn't. Java was supposed to be really big next year for the last 3 years now. It's getting tired.

    Weren't we supposed to be using Java for SOMETHING by now? People using the Hot Java browser, raise your hands! Let's see, it's not good for browsers, nobody would dream of writing an RDBMS like Oracle in it and in the middle, it competes with Perl, Python, C/C++ and Tcl/Tk. Seems like a squeeze to me.

    I see where Lotus got out of the Java client business just the other day. Corel got out awhile back too. StarOffice and their free product is not much of a showcase of a vibrant Java marketplace.

    Don't point me at Java support in Oracle or Java support in some ORB or another. All of those environments have quite stable and working C interfaces too, thank you. Show me large numbers of users using Java day in and day out. I bet those same users use about 20 times more C/C++ in their OS alone to support this one app. For every one user who is using a Java app today, I'll give you 50 VB/VBA users and 100 users of apps written in C/C++. There may be growth in Java today, but is it like the growth of Linux where almost no Java is used?

    I'm not a Sun hater, nor am I anti-Java. I really like Java as a language. I was turned off years ago by it because I didn't want to jump on while they were changing it so rapidly and it seems that it's just now starting to stabilize.

    Maybe Java will be really big someday, but I don't see that someday from where I stand.

  • Before I switched over to all Java development, I was really well versed in C and C++. I once worked on a large product that had the same C codebase that compiled across eight different brands of UNIX systems as well as VAX, VMS, and MPE (Hp3000) systems.

    I got to be pretty familiar there with just about every sort of odd cross-platform compatibility problem one could run into.

    I also did a lot of C++ work as well, which was great... as long as you use RougeWave collections and DB packages, along with Great Circle or Purify (to make your program stable enough to run without Great Circle).

    But there is no way that even at my peak of use of any of these languages, even using Emacs as an editor, that I could approach the speed of Java development. It's not quite as fast as it might first appear as you have to spend a little more time optimizing for performance over other langauges, but you more than make up for the in the stability, portability, readability, and documentation gains you get. I go back to C or C++ when I have to (for instance to write a JNI wrapper for a C or C++ library) but I think you'd have to be mad to try and write some of the software I'm working on now in anything but Java.
  • I haven't heard anything about GJC (the port of gcc to compile Java and/or Java bytecodes) recently -- isn't it an acceptable alternative to a JIT? On a different topic, has anyone integrated Java with SOAP or XML/RPC? (They're roughly the same thing -- XML/RPC handles RPC in a reasonably portable way, and SOAP extends that to objects in a quite nice way.) -Billy
  • by Anonymous Coward
    I have also heard that Java is excellent for generating very high billing rates for contractors and consultants who implement those server-side apps using EJB, CORBA, etc.
  • From "The Practice of Programming" by Kernighan and Pike:

    The test is based on a Markov chain algorithm - stats on p. 81.

    The results are on a 400Mhz PII

    C - 150 lines of code, 0.3 seconds to run

    Java - 105 lines of code, 9.2 seconds to run

    C++/STL/dequeue - 70 lines of code, 11.2 seconds to run

    C++/STL/list - 70 lines of code, 1.5 seconds to run

    Awk - 20 lines of code, 2.1 seconds to run

    Perl - 18 lines of code, 1.0 seconds to run.

    Note that Perl performs very well considering how few lines of code it has.

    The Java performance is not terribly encouraging (C++ is even worse, considering the pain it takes to write).

  • This is really a sweet development. Currently, some really cool apps (like the jMax sound processing system) have been "ported to Linux" via Java. However, because the best they can do is include instructions for downloading the blackdown port of the JDK in the README, they are very difficult to get working. A decent port like this could pave the way for a Linux JRE which is exactly what we need for end-user applications. The JRE has done much to ease adoption of Java on Win32, for example.
  • 2x as fast when running _what_? The only thing out there arguably faster than hotspot is IBM's JDK. Kaffe, last time I checked (which was two weeks ago) was slow and buggy, and didn't ship with a buggy java compiler and not enough of a java core class implementation to compile the code I needed.

    it has a _looooong_ way to go before it is as good as the 1.2 Blackdown JDK (which in turn is nowhere near as good as the 1.1.7 Blackdown JDK, which is in turn crap compared to the windows JDK). Kaffe is one of the lowest rungs on the totem-poll.

    Unless they have been keeping lots of cool changes out of their snapshots..
  • I don't know. Ask The Hungry Programmers.
  • by Anonymous Coward
    All of those systems will have working C/C++ compilers, after all.

    K&R C, I can believe. But there are still proprietary OSes out there whose one-and-only compiler doesn't even grok exceptions, and I'd hardly call that impoverished language C++.

    With C/C++ you should be able to get much greater performance, stability,

    This is a troll, right? C and C++ are half-marked minefields, and the industry has spent the last decade or so proving that getting reasonable robustness with them requires such superhuman diligence that you actually get more money if you don't even bother to try.

    more immunity to environmental changes,

    Ah yes, the joys of DLL Hell.

    less developmental headaches (no nervously watching evolving Java standards)

    Instead you can wistfully watch the evolved C++ Standard and wonder which parts your vendors might bother to support.

    and more qualified programmers (most good Java programmers are good C++ programmers, but not vice versa).

    This is an artifact of C++ having arisen first. Most good C++ programmers have learned Java for the same reason they'd learned C++ - it's better than what they had before. Most Java programmers who didn't already know C++ are too inexperienced to be good (the rest were doing amazing things in Smalltalk instead).

    IMHO the notion of code that's married forever to one machine is the next piece of cultural baggage we're getting rid of, and Java (the first widely-deployed language that can safely receive and run untrusted code from elsewhere) will be the centerpiece.

  • This is absolutely ridiculous. Mr. Perens is claiming that Kaffe is "300% faster" than some competitors without giving concrete benchmarks or even stating who those competitors are. Obviously you can create a loaded scenario by pitting Kaffe with JIT vs. Blackdown with JIT disabled. Even worse is the AC who claimed that Kaffe could be 2x as fsat as HotSpot.
    For real, 3rd party benchmarks, check out the Volano report at:
    http://www.javaworld.com/javaworld/jw-10-1999/jw -10-volano.html
    In terms of speed, Kaffe rated a 389, while IBM's JDK got a 1770. Yup, the IBM kit was more than 4 times as fast. On top of that, Transvirtual doesn't pass Java compatibility tests, so if you develop on their VM, you have no reason to believe that your code will work on a real JVM.
    Open source is not necessarily equal to best of breed.
    --JRZ
  • Is that with hotspot installed?
  • I've been doing all Java enterprise work for over three years - at first, it was more R&D work with graphical visualization, but for the past few years I've worked on a number of practical Java programs that were deployed to big telecom companies. One was a big application/applett (it ran as either) that was a replacement for and enhancement of of large Powerbuilder application (and don't tell me the world wasn't made more pleasant by the reduction of Powerbuilder apps in the world by one!). It was an MDI Swing app (using Jdk 1.2), and it had to run on P90's... I won't say it was all that fast on a P90, but on a P166 it ran pretty well. That did require some tuning of course, but in the end it ran pretty well and the client was very happy with the results. That just goes to show that people who talk of Java being useless for apps are living back in 1996.

    Now I am working on all server side Java stuff. The whole company is doing almost everything in Java, as are many others.

    This is not a flavour of the month kind of event, this has been slowly building for a long time and there looks to be no end in sight. A strong VM on Linux means that at any time, you can swap out that Solaris or HPUX or AIX EJB server for a Linux box if it meets your criteria for the hardware you need. It will be the force that finally shakes loose any doubt of Linux being an equal in the corperate world. It's a shame that Java VM development on Linux has been so slow, but at last we are seeing good progress...
  • Has anyone used native compiled Java (i.e. machine code - no JVM) to develop Linux/Win/Mac cross platform programs? Any problems using Swing, threads and sockets? What compiler did you use on each platform? Any compiler incompatability issues? Am I right in thinking that gjc only supports Linux of these there platforms?
    The Cygnus java compiler is actually called GCJ [cygnus.com] and compiles on all Unix variants, at least if you're using GCC. It has support for native threads and user threads and a full java.net implementation. Actually, the only thing missing is AWT and Swing.
  • Check out this Java World article [javaworld.com] for real benchmarks for a variety of JDKs on Intel hardware. The scalability (page 2) is both interesting and disappointing. The numbers on the Blackdown and Kaffe JVMs really show how badly a new JVM is needed for Linux. --JRZ
  • One thing that java detractors seem to forget is that in many cases the systems being written would formerly have been written in some other "4GL" language such as Oracle or Unify Accell or Powerbuilder, etc. You just can't use system programming in these environments. The "4GL" environments are form/database environments first and real languages second; Java is a real language first but has excellent database and form access (with a little bit of work).

    This is largely in line with comments made by others; that programmer resources are more expensive than hardware in the long run. I also believe that the hardware is so changing so quickly that language decisions made on the basis of performance are generally meaningless within a couple of years.

    Few big companies are going to build large multi-user applications from scratch; Java is like the "4GLs" in that they have a huge respository of useful things that are just standard. It is better than the 4GLs in that it is faster and more generalised - and it works everywhere.

    It is great to be able to combine the two "obvious" (to me anyway) trends of the future, java and linux.

    Just MHO of course.

  • The article seemed to indicate that they would be working together.

    "Sun is also working with the Blackdown Porting Group to bring Java2 to Linux."

    -----------

    "You can't shake the Devil's hand and say you're only kidding."

  • Speaking as a programmer that has been doing a lot of Java development lately, this is very good news. The fact that 'official' Sun blessing has been given to a Java for Linux should help to make Linux more saleable to the PNB types as a Java development and/or deployment platform.

  • The article really sounded as though there is a pressing need to support Java better on Linux machines, but for some reason I thought the general feeling among Linux users was that Java is slow and not really as useful as traditional programming languages.

    I'm wondering if anyone out there uses Java for something useful. Perhaps I sound naive, but I've never seen it deployed beyond annoying applets or slow as molasses games in COS246 (Java Programming) And java support in Netscape seems to be lacking to put it nicely.

    I've done some reading about servlets and Jserver pages which seem quite interesting. Does anyone have any experience with them or experience with gnu-jsp?

  • suns strategy has been pretty consistent since jdk 1.1. Its just that it takes bit longer than they originally expected.

    "That's typically what people in here decry - the fact that there is so much hype for so little delivery."

    Those people generally seem to be unaware of anything else but applets. One of the reasons there are so many Java products at this moment is because its a profitable business. I.e. people actually buy and use stuff like JBuilder, Visual Age, etc.

    You are right that SUN is repositioning Java all the time. They have to because there's a lot changing. A year ago XML was just a spec. Now it's the latest hype. Java is right in the centre providing tools, parsers etc. I don't think that's bad.
    Then Jini, I really like the ideas behind that. Its something truly innovative. It doesn't seem to hurt other things in Java so what's your problem with Jini?

    "...no tool can satisfy all these diverse needs as easily as Sun would have you believe"

    Sun doesn't want you to believe that. They're offering different versions of their JDK now. A standard version, an enterprise version, a micro edition (coming in five flavors if I remember correctly). Each is targeting a different portion of the market.

    I'm sorry the world is spinning too fast for you these days.
  • by GnuGrendel ( 16068 ) on Monday October 18, 1999 @11:13AM (#1604293)
    I know a lot of /. readers don't like Java for X, Y, or Z reasons, but this is a really REALLY Good Thing (tm).

    The direction middleware (such as application servers, transaction monitors, messaging servers, etc) is going is Java, like it or not (I happen to like it quite a bit). Enterprise Java is getting even more hype in these areas than Linux itself *grin*.

    As I've personally just been doing an overview of a systems architecture for a large (fortune 50 or so) company's internal functions, I can tell you that Java support is really holding back a lot of the enterprise middleware products that are available for NT, Solaris, AIX, etc. I had to recommend not using Linux because these enterprise applications are not available for Linux. Hopefully, this move from Sun and IBM's great work on Linux JVM's will help to remedy this situation.

    Plus, with the Apache Jakarta code finally having dropped (thanks again Sun!) it will be nice to have a fast, stable 1.2 JVM. I've heard that the Blackdown port is relatively stable, but the Volano benchmarks show it to be relatively slow.
  • by russcoon ( 34224 ) on Monday October 18, 1999 @11:15AM (#1604295) Homepage
    I have this sneaking suspicion that IBM was the motiviating factor in all of this. I work in/around an AS/400 shop (but I am a web designer) and it seems to me that IBM is pushing Java just as fast as it'll go. Additionally, it makes sense for IBM to pursue this route in terms of client independence. IBM really doesn't have a competitive client to push into the market at this point, so by pushing Java to every other platform, they hedge their bets and can sit back and watch the client wars play out while they focus on the Big Iron behind it all without having to worry quite so much about interoperability problems. My guess is that they will drag Sun kicking and screaming along with this plan through some kind of liscensing deal that we may/may not be privy too. Heaven knows that IBM's patent arsenal affects Sun _somehow_
  • I thought it was a pretty good turn to use a commercial license sold to Microsoft to finance an Open Source product! Sun's policy was unworkable. I also don't think MS is the devil. In this case, Sun was worse.

    Sun didn't want anyone to change Java, so that it would be a "write once, run anywhere" language. OK, that's a reasonable goal. But they did that by prohbiting anyone but Sun from making changes in Java. They should have done it by establishing a Java standard, with trademarks attached to it and a certification program, instead of casting the software in concrete and prohibiting any innovation by people outside of Sun. And now, they've lost. Their big expensive lawsuit against Microsoft means nothing, because Microsoft simply bought their Java VM from someone other than Sun.

  • My issue with the Blackdown port is that, beautifully compliant as it is, it lacks a JIT compiler. My benchmarks make the Kaffe JITC about three times as fast as the Blackdown JDK's interpreter.

    With Java designed the way it is, it should be a truly no-brainer hack to graft the Kaffe JITC onto Blackdown. If a hack it would be at all. Perhaps the relative hooks in the JITC should be exposed with CORBA, if they aren't already, that is.
  • The article really sounded as though there is a pressing need to support Java better on Linux machines, but for some reason I thought the general feeling among Linux users was that Java is slow and not really as useful as traditional programming languages.

    The language itself has a conceptually very clean design placing it in the popular class of things that are easy to learn and do simple things with.

    The standard libraries support a disgusting number of things, so again, simple tasks are often a mere matter of programming.

    Java has decent support on various different platforms, especially those that are poor in programming tools.

    Hardware's "cheap".

    I personally thought Java was the greatest until I became familiar with Unix.

    sklein

  • First, the story does not come from Sun, but rather from "sources close to Sun Microsystems". This is an immediate red-flag. Admittedly, Inprise's CTO seems to be convinced, but Sun's done some interesting things in the past.

    The current 1.2 JVMs for linux aren't really all that good. There are speed problems, functionality problems... a lot of problems. They're certainly not ready for a real deployment in anywhere near a mission critical situation. Fun to play with, but not business ready yet.

    Remember that many of the difficulties encountered when porting this around are due to the very SolarisThreading-centric 'reference' implementation provided by Sun -- unless they're willing to do something about that, they're in the same mess that Blackdown/IBM/HP/etc are.

  • by Ledge Kindred ( 82988 ) on Monday October 18, 1999 @11:21AM (#1604328)
    I've been using IBM's JDK1.1.8 for some time now and have found it's extremely stable and extremely good performance - not what you'd expect at all from something labeled "Alpha version" - it hasn't crashed at all under some pretty severe situations, even using native threads and the JIT.

    The IBM JDK does need a kernel 2.2/glibc-2.1-based machine, but if you're "into" Java, you're going to want to be on those versions anyway for the improved native thread support. (read: "working native thread support.")

    We'll have to see how things turn out in a few months regarding a Java2 JDK, but I'd put my money on IBM. Sun's good at talking the talk, but IBM has proved themselves to also be good at walking the walk. (And it seems like the poor Blackdown guys have just been getting the shaft...)

    -=-=-=-=-

  • Check out TowerJ at www.towerj.com [towerj.com]. They've got a link to the latest Volanomark (?) Java benchmarks that show natively-compiled TowerJ on Linux is the fastest deployment platform for Java. Works on many other platforms as well. As far as compatibility, dunno, I've never used it, but it has a great reputation among those who go for that sort of thing.

    Note that it is very much a commercial product and rather pricey IMHO.

    -=-=-=-=-

  • In the real world, you're not going to have Java processes that just run for 9.0 seconds and then stop (unless you run Java through CGI, which is idiotic if you care about speed). You'd have say an application server with a continuously-running Java process. The whole point about JITs (yes, they did this before HotSpot came along, contrary to Sun's advertising) is that (well, some of them, anyway) only compile bytecode to native code when it's getting used a lot. And then there's bootstrap class loading and initialisation which probably dwarfs the time taken by the main method itself (I don't know if that's included in your results!)

    What all that means is, if you wrap a for loop with say 200 iterations around each program, the Java code should be relatively faster per iteration, because after a while the optimisations will trip in - and the initial overheads will be constant, thus less significant.


  • Thats interesting that you've had success with the IBM JDK 1.1.8. I had lots of problems even running IBM tools for DB2 under their release, although they ran well under Blackdown 1.1.7v3.

    Weird. I hope they get all those revisions sorted out and everyone just gets behind a nice, solid v1.2.

    And a little more speed can't hurt.


    Hotnutz.com [hotnutz.com]
  • ...and with this new announcement today of a security flaw [cnn.com] in Microsoft's VM (haven't seen it posted yet today), it's all the better.
  • by Ledge Kindred ( 82988 ) on Monday October 18, 1999 @11:35AM (#1604356)
    You've touched on the place that Java is developing quite a following. Not too many people that I personally know of are working on building full-screen interactive applications, we're all working on using Java as a back-end, middleware app, application server, servlet engine, database gateway, what-have-you, which is where it really shines.

    Some of the things that I personally think make it ideal for server-side programming are: excellent database API (JDBC), native support for http and ftp xfers, multithreading, a very easy to use exception handling mechanism, and the object-oriented programming model can be mapped very well onto things like database and file objects. When you're not trying to do interactive graphical apps, speed is very good and only a few percent behind compiled apps with most things I've seen.

    The cross-platform-ability also makes it easy to develop on Windows or Linux boxes, then take the same code and drop it on your Sun E10000 to deploy. You just have to make sure your Windows-based developers aren't using MS J++ and writing incompatible code... :)

    -=-=-=-=-

"I've finally learned what `upward compatible' means. It means we get to keep all our old mistakes." -- Dennie van Tassel

Working...