Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Java Programming

Java 2 for Linux Released & Blackdown Gets Creds 211

burner writes, "After quite a wait, JDK1.2.2 is released for Linux. You can grab the final release from Sun's site. Sun has also put up bios for the Blackdown guys. Sun's been acting pretty flippy lately, but this is great news. I've been using Blackdown's latest release candidates lately, and they're excellent, but now there's a final release. Nice work guys! "
This discussion has been archived. No new comments can be posted.

Java 2 for Linux Released & Blackdown Gets Creds

Comments Filter:
  • I'm very pleased to see this and to see Blackdown getting credit. I have been hoping to use Java on Linux for a distributed network-of-computers project and this release makes the whole thing look more "polished" then using an RC.
  • by mochaone ( 59034 ) on Wednesday February 16, 2000 @11:11AM (#1267359)
    Lest you people forget, there was a horrific accident some months ago when developers tried to code Q uake in Java [cnn.com]. Please do not make the same mistakes.

  • Upgrade away, this should be a very stable release seeing as Blackdown doesn't seem to relaese flaky code. The betas were very stable and I have been happily developing with them for quite a while.
    Now onto java 1.3, 3 or whatever it will be called :)
  • by fusion94 ( 19221 ) on Wednesday February 16, 2000 @11:12AM (#1267361) Homepage
    Yeah it looks as though Sun finally pulled their heads out of their asses on this one. Now if they would only do the same with StarOffice and the SCPL I might actually be convinced to no longer speak disparingly about them.
  • Lest you people forget, there was a horrific accident some months ago when developers tried to code Q uake in Java. Please do not make the same mistakes.

    Ha ha! Nothing funnier than hundreds of dead and wounded innocent people in a remote part of the world! Look at those poor people! What a great joke!!!
  • Now onto java 1.3, 3 or whatever it will be called

    Isn't Visual Basic at about 6? Based on industry trends, Java 1.3 should be released as Java 7.

    - - - -

  • by MattHaffner ( 101554 ) on Wednesday February 16, 2000 @11:19AM (#1267365)
    It's so disappointing to still see Java so fragmented across platforms. The 'Linux' release is only officially supported on one processor and increasing the officially supported OS's by 50% has been like pulling teeth. It's not the end-all-be-all of languages, but two years ago I had hopes that by now it would be faster and more pervasive than it has become--especially outside the browser cage. Such a shame... mh
  • Point taken, but misplaced.

    Java development is growing daily. The speed with which Java applications and servlets can be developed is unprecedented. The speed issues with Java are decreasing with each release, and 1.2.2 is pretty quick. The 1.3 early-release 1.3 JRE is quite a bit faster, and Blackdown is already working on the port.

    This is very good news for Linux, which, as you may have noticed, a few /. readers seem to care about. If you wanna bitch, try posting at http://dev.null.com [seanbaby.com].

  • Let's see how many we get on this story:

    • 1) Sun sucks
    • 2) Java sucks
    • 3) slow
    • 4) use Perl!
    • 5) blah blah blah

    Offtopic: If you don't have an X-server, JavaLobby posted a story about a very nice GPL'ed Xserver/Esound/Truetype server written in Java at called WeirdX [jcraft.com] Even runs as an applet. Very nice if all you have is a Windows/Mac box, or are at a public terminal/cybercafe and need to remote-X from your Linux box. :) Mostly impressive because a single guy wrote an X server from scratch in a short period of time.

  • This was done for Solaris 2.7 by Sun. Solaris 2.7 was renamed as Solaris 7 and now it on on version 8. It's not difficult that Sun may even do the same thing to Java.
  • by ChrisRijk ( 1818 ) on Wednesday February 16, 2000 @11:29AM (#1267371)
    You may be interested to find that the final release does not (currently) include a JIT JVM, because they were using Inprise's and that's not yet certified. You can download it seperately though.

    There was a JavaLive chat [sun.com] yesterday about the Java on Linux stuff. They haven't put up the transcripts yet though.

    For Java 1.3 from Sun, the Windows version will come out first, then Solaris then Linux. However, they do want to syncronise all releases together and should do this at or before Java 1.4 - might happen first for a maintenance release.

  • by Anonymous Coward
    The blackdown JDK (1.2.2 RC4) supports native threads, while the Sun/Inprise release does not. The Sun/JDK release for liunx is not recommended for use on SMP systems....
  • by jd ( 1658 )
    How does this compare with anyone else's Java 2 for Linux? I know there are some out there.

    That's not to insinuate that there's anything bad about Sun's version of Java. Other than it has a history of being the slowest. (Jikes leaves Sun's v1.1 compilers trailing in the dust.)

    Also, now that Blackdown have it ported to Linux, will it be ported to different Linux processors? Or just ix86?

    I can't see why it should be anything beyond a simple recompile, to get binaries for all the Linux platforms, and compilation speed isn't an issue, as you're not looking to debug the logic. Emulators, such as the ARM emulator, and cross-compilers, should be fine in producing Java 2 for Linux for every platform it runs on.

  • What do you mean, they already did (Java 2 and Java 1.2 are synonymous...)

  • I have been using IBM's Java 1.1.8 for basically powering my backend web applications on linux and frankly it has been working so well I have not seen a need to move to Java 2.

    I don't use any of the Java EE beans or really anything major complicated, but my team has built some fairly complicated web sites that use multi-tier architecture with a great deal of success.

    From the benchmarks I have seen I wouldn't argue that 1.2 is not really any faster than IBM's JDK? Actually, the benchmarks I have seen argue strongly the opposite.

    From what I understand IBM will have Java 1.3 ported to Linux Q2 this year. Is Java 2 really worth it on the backend on linux?

    Does anyone know what HotSpot is and what advantage that is going to bring us on using Java where it belongs, on the Server. :) (IMHO)

  • by kevlar ( 13509 ) on Wednesday February 16, 2000 @11:44AM (#1267377)
    I admire the Blackdown crew, and the work they've done to get the JVM working under Linux. Unfortunately however, its not something I can use to write a professional application if I expect it to work properly.

    I've done a lot of Java development under Linux this year, and I've noticed several things that prevent me from doing serious work with Java (under Linux). For example, rmiregistry crashes without fail for any type of heavily loaded RMI project. Another example is that Thread objects break just as easily, or refuse to start altogether when you spawn multiple Threads (even if there is plenty of memory available). Luckily I have access to a cluster of Ultra5's to test my applications on, which execute almost flawlessly (I've noticed a few quirks with Threads under Solaris as well, but not nearly as bad as under Linux).
    I see the state of the JVM under Linux as being close to a toy. I know all the Blackdown people will probably find this insulting, but unfortunately, I can't do hard-core Java the way I can under Solaris. I do not blame Blackdown in any way for this however. I feel that this is solely Sun's fault.
    Thats my $0.02 on the issue. I love Blackdown, I love Java. Bugs suck.
  • I'm writing servlets for my current project. The "Powers That Be" had concerns about Java support on Linux (no official release, etc., etc., etc.), so they went with HP-UX. (Don't ask.)

    If they would've known the amount of time I had to struggle with getting GCC loaded and config'd for the HP, just so I could then compile Apache, just so after that I could compile JServ, just so I could *then* use an "Officially Sanctioned" JDK....

    As I said, long overdue...

  • by CyberDong ( 137370 ) on Wednesday February 16, 2000 @11:49AM (#1267379)
    I had hopes that by now it would be faster and more pervasive than it has become--especially outside the browser cage

    About the "faster" part, it will probably never be suitable for OS development, but you CAN get platform-specific compilers for it.

    Regarding the "pervasive" & "outside the browser" parts, I think you're just not looking.

    • Oracle & Sybase (also SQL Anywhere) now ship their DB software with Java as the internal procedure language.
    • At JavaOne last year, the Palm Pilots for sale so inexpensively were loaded with a JVM.
    • The Apache organization has embraced Java Servlets and Java Server Pages in their Jakarta Project [apache.org].
    • IBM's AlphaWorks [ibm.com] is pouring out java resources like mad.
    • Embedded Java is a super-hot trend for everything from cell phones to web kiosks.

    Admittedly the start was slow, due to the fact that Java's original target platforms were toasters and TV's. But there are no shortage of Java applications you can't see until you look for them.

    - - - -

  • by Anonymous Coward
    My life with the Sun JDK for Linux: 1. Got excited! Downloaded. 2. Installed 3. Ran my app. 4. waited. 5. killed process; tried again. 6. waited, waited, waited, waited. 7. killed process. 8. Uninstalled. 9. Downloaded and reinstalled RC4 *sigh*
  • Has anyone gotten Jini and Javaspaces to run? I'm taking a class that has an assignment to write a "distributed" program using javaspaces, and I've been trying to get the examples to run using a release candidate... needless to say, it bombs out, and I don't want to attempt this project in Win98... Thanks!
  • Correction: Please, codes games, as well as everything else in Java. Thank you.
  • >What do you mean, they already did (Java 2 and
    > Java 1.2 are synonymous...)

    JDk 1.3 is also a Java 2 platform release.
  • This is not a Blackdown release! They are at 1.2.2RC4. SUN has released the 'production' version of the SUN/Inprise port, which contains (older) Blackdown code. Not quite the same thing!
  • Perhaps it's time to start optimizing your RMI projects so they hit the registry so often, as you should do on any JVM.
  • As people who have been following the development of JDK 1.2 for Linux will know, the Sun/Inprise and Blackdown porting efforts have been taking place in parallel for the past while, and each group has produced a different port.

    My experience has been that Blackdown's port was faster and more stable than Sun's. Now that Sun's port has been officially blessed, I imagine it will have the stability edge for a little while, but I will continue to use the Blackdown port for its superior performance.

  • by Blue Lang ( 13117 ) on Wednesday February 16, 2000 @12:14PM (#1267393) Homepage
    see the state of the JVM under Linux as being close to a toy.

    I think the implication of your post is much more interesting than just 'java doesn't run well on linux.'

    What this (teir-1 support for solaris, goat-blowing support for linux) mostly accomplishes is continued degradation of a core-value of java: write once, run anywhere. Not only does it not work, it hasn't ever worked, and even if it does work, it doesn't work well enough to be useable in the Real World.

    So, as usual, instead of disparaging linux and the blackdown crew, I think it's important to keep the blame right where it belongs: on Sun. If they REALLY wanted Java to be a ubiquitous standard, they'd release it all and let the people who do the work have at it.

    All in all, NOTHING works perfectly across all platforms, not /bin/sh scripts, not perl, hell, not even terminal emulation. But the projects which are most open seem to have the most luck with being truly portable.

  • Optimization is irrelevent. It works under Solaris and NT, therefore it should work under Linux. Optimizing specificly for Linux goes against everything Java stands for. The fact is that RMI under Linux is severely crippled.
  • just so after that I could compile JServ

    I hate to have to break this to you, seeing the amount of work you've already had to do, but JServ isn't it any more. The new reference implementation for servlets is Tomcat from the Jakarta Project [apache.org].

    My condolences...

    - - - -

  • ...the real problem isn't the warm-and-fuzzies, (although there's no underestimating the importance of people's feelings). The real problem is that Java is not open-source, and the stewardship of Java standards/apis is not open. The earlier slight to the Blackdown team was just a symptom, the real disease is Sun's unwillingness to let go of their baby and let it grow up into an adult. The result is that Java is still running largely with training wheels. Who wants to see how well the sandbox works when there are precious few applications worth running? Who wants to run an app that is theoretically pleasing but is, in practice, slow and kinda ugly? And not 100% stable? We can fix all that, but not under the current conditions. If things continue as they are, yes, progress will happen, but it will be sloooooooooow... maybe *too* slow.

    I don't want to sound ungrateful, but... when are you going to drop the other shoe, Scott???
  • by JohnZed ( 20191 ) on Wednesday February 16, 2000 @12:19PM (#1267398)
    I've been using 1.2rc3 for some time on an intranet site using a bunch of servlets/JSPs. Works like a charm. 1.2 JVMs are SOO much easier to use and configure than 1.1.x JVMs. They're much more intelligent about using .jar's, etc. The performance is also quite good, especially with Resin (www.caucho.com). No, I don't work for them, but I'm incredibly impressed by their servlet engine. It also has a cool feature that compiles JavaScript (in JSPs) to real Java bytecode. Plus a lot of great utility classes (like automatic database connection pooling, and XML support). I highly recommend checking it out. We're running an app on a $400 Linux machine and the response is basically instantaneous, even with multiple database queries. --JRZ
  • The last Blackdown release had a wobbly JIT and native-threads that were just plain broken. To run Netbeans, I had to disable the JIT and switch to green-threads - in other words, to turn off anything that makes Java run faster than molasses. Is this fixed in this release? Is there infact any real reason to upgrade from Blackdown 1.2.2 RC4?
  • All in all, NOTHING works perfectly across all platforms

    I must have an old version of NOTHING. Mine only works on ETHERnet.

    - - - -

  • Your right, I stand corrected. The headlines gave me a different impression. I guess I should have grabbed the tar ball first.
  • by Ledge Kindred ( 82988 ) on Wednesday February 16, 2000 @12:33PM (#1267402)
    As far as I'm aware, Sun's "official Linux JDK" is *not* the same as the Blackdown release - this is still the Sun/Inprise release. Sun *have* given Blackdown some credit for the port since the Sun/Inprise version is based on an earlier version of the Blackdown codebase, I assume they have miraculously managed to learn from their earlier mistake.

    An important distinction between the two is that the "official Sun JDK" does NOT support native threads and in fact recommends NOT running it on SMP machines, while the Blackdown release does native threads and SMP just fine.


  • Its completely true. We all know that Sun has a grudge against Linux and OSS in general, and this is just a good example of how they don't want to participate. It really is a shame though, because the potential for Java is huge, so long as things are done correctly; unfortunately they're not.
  • OSes are not the end-all-be-all of Java, either. example: a modular reconfigurable robot from Xerox-PARC called Polybot [xerox.com]. (if you were at comdex and caught John Seeley Brown's keynote speech, you saw it. there have also been lots of print, online, and TV pieces on it) it runs on PowerPC chips running compiled Java.

    there are lots of embedded Java things coming out now that run embedded Java. remember that the original demo for the language (if I remember correctly) back when it was called Oak, was a bulky TV remote control.


    Warning: the Polybot link will take you to a page that my Mozilla M13 will render and then turn blank grey. I have no idea why, but you might want to try Netscape instead. (or IE, if you're that sort of person)

  • I wrote a Java program for my son to use. Supposedly, it puts pictures of animal pictures on the screen, plays a sound clip, and a person is supposed to click on the picture of the right animal. Programming it was a dream. Easy! Not much code.

    The problem: It doesn't run the same on any 2 platforms that I've tried. It doesn't run the same twice on any single platform. You never know which thread will run first. Sometimes the sound comes before the pictures appear (which is not the order it's programmed). Often, it doesn't load the images when I tell it to, and sometimes it doesn't load one of the images at all. The only way I could keep it from playing 2 sound clips at the same time was to specify a sleep the duration of the 1st sound clip. This happens with 4 different JVMs and operating systems (no Sun platforms) that I've tried. And, of course, it often crashes.

    I have given up on Java. The point was to make a cross-platform program that non-Linux users could use, but if it only runs well on Sun products, forget it.
  • Not being a Debian user, I guess I can't say for sure (maybe there's some weird issue that I'm not seeing). However, if you're worried about being able to unistall easily, you shouldn't be (worried that is). Beyond using tar to create your /usr/local/jdk1.2.2/ directory, and modifying your environment variables, there's nothing more to do. To get rid of the jdk, just remove jdk1.2.2 directory.

    I have three different jdk's installed under /usr/local/ and it makes it very convenient to switch between them by simply changing my environment variables.
  • A history of being slowest, yes, but Sun's HotSpot dynamically optimizing VM is very nice, competitive or superior to anything else out there, at least for Java 1.2 and greater.

  • Java is an appopriate choice for many kinds of games, but not all. First-Person shooters would not be a good class of game to do in Java; they are so resource-intensive and speed-critical that the performance hit of running on a JVM would probably be unacceptable. However, many other types of games would be great on Java - multi-player turn-based strategy games (Like Civilization II [civ2.com])would benefit from Java's strengths. I think that pretty much any game that isn't dependant having a high framerate to be enjoyable could be done in Java with no noticeable degradation to playability.
    "The axiom 'An honest man has nothing to fear from the police'
  • by FreeUser ( 11483 ) on Wednesday February 16, 2000 @12:55PM (#1267413)
    I was once very excited about java. Did a fair amount of development under Java 1.0, Java 1.1, and Java 1.2, before we as a company decided to dump the product because of Sun's mismanagement of the standard and their lackluster support of the Blackdown group and Linux in general. This may have changed for the moment, but for us (and I suspect many others) it came far too late to be of much use (c.f. "sun sucks").

    Performance may now be acceptable, but at the time we dumped the product even a small, simple data entry application was too demanding of the JVM at the time (even on Sparc 10's running Solaris, much less Linux). The choice Sun gave us was stark: run the Java VM under Windows or Solaris on a high end sparc, or suffer. We chose Linux, adopted a more open development environment, and now having dumped the product we will not, in the future, ever consider going back (c.f "sun sucks" and "slow"). Using GNU configure and its associated utilities, we are able to get all the cross-platform support we require, even if it involves a quick rebuild of the sources (typing "./configure" and "make install" isn't terribly difficult) with the performance our users demand and languages we can hire developers for (c.f. "use Perl" and "Java sucks").

    I enjoyed using Java (despite the, even now, still horrificly screwed up date and time classes) as a language, but the drawbacks were too severe and too critical for too long of a time, and Sun's current and future motives with respect to the openness of the standard and support for Linux, FreeBSD, and whatever other platform we may, in the future, chose to deploy, has eroded our confidence in the product too much for us to seriously consider any future use of Java. Put simply, the stumbling blocks Sun until recently put in the way of development on anything other than their "blessed" platforms far outweighed any advantage the language itself offered (and those were not inconsiderable for those of us coming from C++, with Java's simpler memory management and garbage collection and other features).

    Alas, the promise of "write once, run everywhere" quickly became (and IMHO remains) "write once, run where Sun would like you to." At present Sun has chosen to become mildly friendly towards Linux. This is great! However, I would not expect this to remain a long term strategy on their part, unless there are some serious changes in the mentaility of Sun's upper management. (c.f. "blah blah blah").
  • I just tried it (weirdx). I downloaded the 1.2.2 JRE from sunsoft, and uploaded the weirdx-*.html files to an http server, as well as the jar file... got nothing but starting java applet and a white screen.

    Java never seems to work right for me.

    At work we are using a java program (running through X in this case), and it crashes about 50% of the time when you try to start it. This is running on HP/UX.

    In other words, I'm not impressed with Java so far. But that weirdx LOOKS really awesome. What am I doing wrong?
  • Actually, Visual Basic is one of the few Microsoft products to not skip version numbers.

    And now, submitted for your disapproval, the dark path I have trodden since 1993: The History of Visual Basic (short form).
    • May 1991: VB 1.0. Drag-n-drop window layout, VBX visual component architecture, p-code-based runtime. Simple by today's standards, but remember: It takes MS at least three versions to get it right. :-)
    • Nov 1992: VB 2.0. ODBC, Multiple Document Interface, and object variables.
    • June 1993: VB 3.0. Access DB engine, OLE Automation, Crystal Reports. Reaches Critical Mass, even though it's not really ready.
    • Oct 1995: VB 4.0. Parallel 16- and 32-bit development, rudimentary classes, ActiveX Controls (then called OCXs) replace VBXs, extensible IDE. Almost ready for prime time.
    • April 1997: VB 5.0. Goodbye, 16-bit. Native x86 and Alpha compilers, events in classes, API callback support, COM Component and ActiveX Control targets, vastly improved IDE (IMHO). ...and there was much rejoicing.
    • Oct 1998: VB 6.0. Dynamic form building and lots of web candy. Little more than a service pack to VB5, if you ask me.
    • Q1 2001: VB 7.0. Major redesign. Real objects with inheritance, polymorphism, constructors, &c. Structured exception handling (Try...Catch...Finally instead of On Error Goto Hell). Free threading. Essentially, everything we've been begging and screaming for since VB4!
    Note: VB7 info is based on Steve Ballmer's keynote at VBITS San Francisco yesterday. So if any real improvements are dropped before RTM, we know where the lynch mob will form. :-)

    Can I moderate myself -1: Offtopic?

    Keith Russell
    OS != Religion
  • Now, how about an alpha (AXP linux) port? Due to childish feuding between the Blackdown team and "Uncle George," the guy originally doing the alpha ports, there is still not a decent JDK for my lab's Linux/alpha systems. (I don't even know which side started it, just that the result is very disappointing to those of us who want the port). I'm sure Sun could clear up that problem pretty fast with some strategically applied cash. Of course, if they released their JDK as free software, somebody might do the port for them, but their license is another issue.


  • by jonabbey ( 2498 ) <jonabbey@ganymeta.org> on Wednesday February 16, 2000 @01:00PM (#1267417) Homepage

    It doesn't surprise me that Java on Solaris would be more stable than Java on Linux. I run my (large!) RMI server app on Solaris under Java 1.2 and under Linux under 1.1.7/8, and it works fine in both places.

    Perhaps you are doing very fine-grained RMI object exporting? One thing I learned fairly early on is that it is important not to have all of your RMI objects inherit from UnicastRemoteObject.. if you do that, then your objects are automatically registered for export on creation. Much better to use the static UnicastRemoteObject.exportObject() method to export your Remote-implementing object only when needed.

    Actually, now that I think of it, I only actually register a single object in the RMI registry.. my top-level server object. All further RMI activity is done using returned references to RMI-exported objects.

    What sort of architecture are you using in your program? Which versions of the JDK have you been seeing problems on Linux with? What version of glibc do you have installed?

  • by daemonc ( 145175 ) on Wednesday February 16, 2000 @01:01PM (#1267418)
    Does this mean that us poor linux users can finally use the java plugin for mozilla ? (oh please please please ...)
  • You may want to brush up on multi-threaded programming- what you describe is exactly the way it is supposed to work (i.e. the order of thread execution is not guaranteed).

    It sounds like you've seriously overdeveloped your app- if you're doing things sequentially, why put the actions in seperate threads? If you actually need threads for something, can the UI functions you describe be in one thread? Perhaps you should sychronize things using events.

    YMMV, but I daily do development between 98, NT, Linux, and Solaris (on an UltraSparc) with Java and my code works the same on all platforms. Of course, I'm only doing Server Side applications and am not using AWT or Swing.

    I'm not saying Java is all the hype made it out to be. In fact, all of the hype probably did more damage to Java over the long term than helped in the short term, but overall as a language it's not too shabby. As always, you should use the right tool for the job- maybe it's Java, maybe it's C, maybe it's Perl, maybe it's VB or Delphi. Depends on what needs to be done.

    For the record, I've never been able to get a client side application using AWT or Swing to work the same between implementations.

  • DOOM in Java.
  • I just ran some of my old programs, even the one's with 1000+ threads work fine now, no crashing...sweet
  • This is great news. I had been holding the WebMacro servlet framework [webmacro.org] to 1.1.8 because there wasn't good support for Java2 on free OS's.

    Now I can move it forward to Java2!

  • Optimization cannot be irrelevant. Yes, it would be nice if the Linux OS and JVM scaled in all the same ways as a certain JVM on Solaris or NT does, but that's not realistic. The Java Language Specification makes no guarantees about threading semantics, let alone scaling and performance issues.

    Write Once, Run Everywhere works surprisingly well, all things considered, and it's getting better. It's not a panacea, though. You do have to test your software across several JVM's and in various memory, threading, and loading conditions.

    All of which you know already, of course. Just don't curse Sun (too much)for not attaining perfection when they've got a better portability story than anyone else does today.

  • This is a reply to most of the replies to mine :)

    I wasn't very explict I guess. What I'm really lamenting is a pervasive, cross-platform, in-sync environment to RUN java apps in. I do understand where it has been really successful as a language/platform. As another example, it will be exciting to see if Mac OS X really succeeds in fully integrating it as a first-class development language in a popular OS.

    However, many spiffy add-on APIs (not only from Sun) are only really supported on those platforms that Sun supports. Admittedly some are inherently difficult to support well cross-platform (Java3D for example), but without even core Java in sync across platforms even simpler packages quickly fall away from non-Sun platforms.

    As a mostly high-level language programmer, I really enjoy programming in Java. It also had (has?) the potential to close the cross-platform app gap. Aside from some gee-wiz items and small utilities, that vision (delusion?) seems to be mostly dead for now. It certainly has been a success, but just not where I was looking :)

  • "What more do you want?"

    Non native java code, compiling to native code does not offer much performance advantage (contrary to what people seem to believe) since it does not eliminate the real bottlenecks (garbage collection, memory allocation, synchornization, etc.)
  • by rhedin ( 91503 )

    Tomcat isn't ready for primetime yet. It's lacking many features that JServ already has (and has had for a while now). Just an example, but it still doesn't support servlet reloading. JServ does.

    I'm running both side by side, and while I would like to use some of what Tomcat has (ex. support for Servlet 2.2), right now I can only deploy to JServ. Maybe when 3.1 is out I can switch.

  • In real simple terms, HotSpot is a run-time optimizer for bytecode. It sees what pieces of code are getting used over and over (hot spots) and optimizes them - in a way that I believe is similar to storing data in registers instead of memory; whatever that means in JVM parlance.
  • i wouldn't call the current support "good". there is still no Java2 VM for *BSD or any GNU/Linux flavor except X86. i would keep holding if i were you.
  • by jilles ( 20976 ) on Wednesday February 16, 2000 @01:13PM (#1267431) Homepage
    With the coming mozilla version (beta in 60 days according to mozillazine), yes.
  • i take that back...Blackdown RC4 is available for SPARC, but it's not supported by Sun and probably won't be for a while.
  • Port it to Java!!
  • Let me correct myself. The JLS obviously does say a lot about threading semantics, just not enough to specify whether threads are even pre-emptive under Java, let alone map to native threads or across processors on an SMP box.

    If you are extraordinarily careful and use synchronization primitives with care, you can write code that will function (however slowly/poorly) even in a very limited threading environment.

  • Fuck you, I've been running Linux since 1994.
  • Aren't native threads allowed to preempt? I think there are garunteed atomic operations too like (a = b);
  • I am currently employed in the telecommunications industry working on a SNMP administration tool written in Java. We started with JDK1.2.1, moved to JDK1.2.2, and are now developing with JDK1.3. With JDK1.3 our application blazes onto the screen in under a second, whereas with the earlier versions it took substantially longer. Good work Sun! Blackdown, I can't wait for the port.
  • Now onto java 1.3, 3 or whatever it will be called

    Actually, I want them to get on the ball with all the supplimental stuff -- Media Framework, Advanced Imaging, 3D, and the plug-in (and make sure the plug in and mozilla milestones work together.

    Basically, there are still a number of "Java" pieces that have native code that needs to be ported. If Blackdown doesn't have the resources to do the work, then someone else needs to step forward to get it done.

  • What makes it even greater is that there is still no JDK 1.2.2 production release for Solaris, only a 'reference implementation'. Production release for windows has been there for a year, now we have it for Linux but where's the Solaris version?

  • Maybe having 100 tons of concrete fall on you isnt funny, but if it were a grand piano or an ACME Anvil, then it would be funny!! HAH HAH!!

    Its no fun til someone loses an eye!!

  • Check out Frag Island [passagen.se] - a Java FPS, that if only had gone all the way...
  • Post feature requests for the next JDK as replys to this message.

    MODERATORS, please rate the suggestions!

    Please, only one request per posting or you will mess up the rating.

    Lets work together and make better software!
  • And now, submitted for your disapproval, the dark path I have trodden since 1993:

    I don't like to admit it in public (especially here!), but I've used VB since v1.0 When I started using VB, I was working in a shop where the tool of preference was Clipper '87; an xBase compiler. VB 1, as broken as it was, was an improvement over that. Unfortunately, I have so much VB experience now that I keep getting shanghaied into VB projects when I'd rather be coding in Java. VB is the Dark Side of programming -- once you start down the dark VB path, forever will it dominate your destiny.

    The most common complaint I hear about Java is "It's too slow. Use C/C++ instead." I don't think it's appropriate to compare Java to C/C++, even though Java is (in many regards) the decendent of C++. It is far more appropriate to compare Java to 4GL's like VB and PowerBuilder, as Java has much more in common with those languages than it does to C and C++. Java is pretty mature for it's age. Yes, it has problems, but so did every other language early in it's life.

    Java would benefit a lot from being Open Source. IMHO, Sun should spin off a non-profit subsidiary to manage Java, patterned after the Apache Software Foundation. Apache is probably the most successful Open Source project to date - even moreso than Linux; no other open-source project I know of has over 50% market share in it's category. If Sun were to allow Java to develop the way Apache and GCC have evolved, it's problems would rapidly disappear.

    "The axiom 'An honest man has nothing to fear from the police'
  • Preemption is allowed, yes, and there are guaranteed atomic operations (reference and integer assignment, at the very least). That's why I backpedalled and said that the JLS did indeed have guarantees on thread semantics.

    It just doesn't have any guarantee as to when a particular thread will be run, nor whether a thread will ever be switched unless the active thread comes to the end of its execution or to a wait() call. In practice, every JVM that I care about will do those things, and I don't bother seeking out a Palm Pilot or Win 3.1 JVM to test my code on, but in theory it's something to be aware of.

  • It just so happens that this is being done: http://come.to/JavaNetHack [come.to].
    work seems to be dreadfully slow, but maybe someone can lend him a hand or something...
    BTW, more roguelike java projects can be found on Roguelike News' Links Page [demon.co.uk]. Enjoy!
    "Ladies and gentlemen, this is NPR! And that means....it's time for a drum solo!"
  • Do not you do memory management when coding in C++? Only by hand and error-prone. Your code spends 80% of its time withing like 10% of the program. If you do not create and dispose of too many objects in there - GC overhead is negligible and well worth it. REal bottleneck in Java for me was its floating point performance. I can not use GCC now, for lack of features, but I would expect it will alleviate this..
  • Wow, magnitude 6.4? They got a demo of that somewhere?
    "Ladies and gentlemen, this is NPR! And that means....it's time for a drum solo!"
  • by drudd ( 43032 ) on Wednesday February 16, 2000 @01:39PM (#1267454)
    Actually, its not his multi-threading which is the problem. Graphics in java are multithreaded within the language, which is supposed to aid applets which may need to grab images off of a server.

    It is possible to force your main thread to block until images load, but he obviously doesn't know (For the previous poster, look into the MediaTracker interface).

  • Oh, I've *long* since given up any illusion that this installation is up-to-date. I've opted for "stable" over "latest-and-greatest".

    Hell, at this point I'd settle for "already installed"... (grin)

  • The thread problems aren't a Java issue. Thread execution order is nondeterministic and often seemingly random. To blame this behavior on Java is to not understand multithreaded programming. Remove the threads and you won't have that problem.

    I've been programming in Java ( using CORBA and RMI ) on Linux for ~2 years now and it's been great. It's had its problems to be sure but it's not as bad as some here are making it out to be. We've had significant loads and high numbers of objects going back and forth from our servers and Java has worked like a champ.

  • code like:

    public class Test {
    private static Frame frame;

    public static void main(String[] args) {
    frame = new Frame("Test");

    compiles fine, but segfaults every time I run it. Something isn't right here...
  • I can't believe the parent of this is posted "2, Interesting" This post slams Java wo/having much of a clue about the defined programming model. RTFM
  • Sure I do. Open your mouth now.
  • a=b is guaranteed atomic unless a and b are longs.
  • Well, it isn't the final one, but there is a 1.2 pre-release plugin for Netscape at:
    ftp://iodynamics.com/pub/mirror/linux-jdk/JDK-1.2. 2/i386/rc4/

    I haven't been able to find a final one... anyone else?
    The sun is going down, I say we follow it out of town- We've been here for far too long.
  • What do you expect from a poster whose nick is "Kludge?"
  • just what are moderators on these days... moderators should be moderated themselves.

    How can this be classed as interesting for Godsake.. funny maybe, but interesting?
    what information does it give?
    bugger all thats what.

  • I didn't know this before I read these news, but now I do: I needed a good JVM for Linux in order to competely switch my focus from C to Java. I will certainly continue working in C, but less and less. My company does a lot of Java developement (on HP UX and NT), but I wasn't very motivated to join R&D with Java. Now I am!

    Thanks Blackdown and Sun!

  • That's funny! Seriously, though, Java 2 v1.3 combined with Sun's Java3D implementation is suitable for writing games with high quality 3D graphics and sound. Java 2 v1.3 code often runs nearly as fast as C++ compiled code. The catch is that the 1.3 version (actually 1.3 release candidate 1) implementation with hardware 3D acceleration is only supported on Windows platforms, not even on Sun's own Solaris OS! Sun claims that the JDK 1.3 for Linux will be out sometime late in 2000.
  • While I recognize that SUN might have strategic problems with Linux and open source in general, I would like to point out that they seem to be supporting Java for that platform.

    Check out the Macintosh support. Not Open Source at all.

    If Java actually ran on multiple platforms with any performance, it would make the question of Platform old fashioned. However instead they work hard to push it on the majority platform, Windows.

  • ...to see if any Greek soldiers are lurking in there.

    Really, the README says that only green threads are supported and running under SMP kernels is discouraged. Given the resources Sun has to do things right, this can mean only one thing: it's their way of saying "Linux is OK for single-user toy usage but for high-end SMP stuff just get Solaris, OK?". This is more a PR release "We do Linux, we want our stock to go up" than the REAL thing.

    I hope IBM will bring out a SMP-supporting JDK2 SOON! Their 1.1.8 is wonderful and fast. Are you listening, IBM?

  • Most 3d game engines are written in C, though.

    Maybe in a few years.. ;-)

  • Part of that is that Sun's 3D "acceleration" REALLY SUCKS!

    Just ask Chris Schoeneman.
  • Normally, I'm pretty happy when something new comes to Linux, however in this case I'm not sure if I should be.

    It is about time Sun got decent Java support to Linux. I know that they'd rather spend effort on working on their own OS, but if they truly want a language that is portable to all systems, they need to make sure it actually works on all systems.

    Now for the negative side. My experience with Java screams that the language is in need of much work. It runs slowly. It requires you to look up the APIs constantly anytime you want to do something useful, and it just doesn't get the job done as well as C/C++. It has a place, but I'm not sure that it is really the greatest tool for Linux programmers when compared to C/C++/Perl/Whatever. Still, the idea of "crossplatform" is nice.

  • If you're not satisfied with the proprietary nature of Java on Linux, you should contribute to GNU Classpath [classpath.org], a set of clean room classfiles that attempts to support Java 1.1, and possibly 1.2.

    It's in a early stage right now (version 0.0), but should more people hack on it, we can say bye-bye to Sun.

  • Umm? It did work. Once that blank screen goes up, go to a Unix box somewhere and run "xterm -display yourmachine:2.0" and the xterm will appear in that applet window. You shouldn't run it as an applet anyway, read the README and launch it from the command line as a Java Application. I had KDE with Enlightment to run through it back to my NT box.
  • work seems to be dreadfully slow or the game seems to be dreadfully slow :-) they probably got tangled in the no-multiple inheritance mess that is java OO and had to flip their code inside out to get what they wanted (can you tell I'm bitter), but seriously, I would like to see more java games so I could crank them up on the Sun and the Alpha and the p3's and have a real in-house fragfest.
  • Wes, I'm glad to see you say this (as someone who has been supportive of Java in general) -- I've personally been burned by this to the point of using Mozilla for portable deployment: even with changing API's and alpha-level code Mozilla is more "write once run anywhere" than Java for desktop apps. Of course, few people take me seriously when I say this, but then again, we are able to deploy now thanks to Mozilla, where we *still* wouldn't be able to if we had stayed with Java.

  • I followed your link and you are right, towerj is on top. But what does that say really? IBM is a very close second and they don't compile to native code. Above all, this version of IBM's VM runs on NT and towerj runs on linux.

    A closer examination of this benchmarks reveals that it tests socket IO and threads. The performance of both is very much dependend on the OS.

    Furthermore, I think a benchmark that stresses the OO usage of Java a little more (i.e. creating destroying objects) would show a different picture.

    This benchmark does not proof much to me. A benchmark that doesn't take typical OO behavior of a program into account is not realistic, even for server side programs.
  • The real problem is that Java is not open-source,
    ... since languages aren't software. Implementations of the languages can be open-source, though, and some are.
    Thankyou for pointing that out, I'm always appreciative of a good niggle in place of an intelligent comment (*sarcasm off*)

    the stewardship of Java standards/apis is not open
    ... just like C++ et al.

    Huh. That's not so. ISO is a public body, the standards are open to real public review, and you can join the working groups if you want (if you've time and money to travel, that is). Try to join one of Sun's api committees. Try to even identify an api committee for Java, let alone a public one. Do you get the picture?

    Except that you can go to Sun's site and download their official specs free of charge, while getting ISOs specs for "their" languages will cost you an arm, leg and your daughter's hand in marriage.
    So? The specs haven't been kept up to date (check for yourself). And have always been incomplete. The specs somewhat lame in a lot of places, too. For example, hardware api's sucked from the beginning, they still suck, and from the look of things, they are going to continue to suck forever unless something drastic changes in the API development process. About the only hardware Sun has created an api for is the mouse. Show me how you support a joystick in Java, for example. It's a big world out there and Java as it stands just can't deal with a lot of it. Don't talk to me about native code interface either: hardware support is pretty much useless in Java unless it exists on every platform, and it's now so late in the game that even if the api's were fixed it would be immensely difficult to deploy the new support widely enough so that application writers could write to it with confidence.

    Sun's unwillingness to let go of their baby and let it grow up into an adult.
    How long did it take for AT&T to let go of C++ and leave it to "grow" in the vats of ISO's JTCs?
    We haven't got that much time to wait. At the current rate, Java is going to be a dead issue by the time Sun wakes up. It's going to be killed by something more useful, and more open, without one, self-interested company trying to dominate it. All I can say is, thanks Sun for giving Bill a few sleepless nights, but really, another proprietary solution is not what the world wants and it's not going to accept it. Many programmers are now using Perl and Python for applications where they would have looked seriously at Java. Python and Perl both work better than Java on Linux, they're faster to develop with, they start faster, easier to debug, more useful libraries, more code developed by other people that you can leverage, etc. etc.

    Do you really feel ISO's process has been to the advantage of the language? A single, steering body is always better, whether that body is called Sun or Guido von Rossum. :-)

    Then lets have a single steering body, but let that body be chosen democratically, and by merit. As far as I'm concerned Sun has dropped the ball.

    We can fix all that, but not under the current conditions.
    It seems you want Sun's source instead of working on the OSS projects already running, like Kaffe. Why?
    Kaffe is nice. Kaffe is fine. I admire everybody that works on Kaffe, and Blackdown too for that matter. But Sun is passively resisting Kaffe and other Java-clones (by withholding important specifications and compliance tests) to the point where it is very difficult to be sure whether Kaffe is Java-compatible or not. That's evil.

    This annoys me, because I'd use Java for a number of things if it weren't such a sluggish, unreliable memory hog. (Which is exactly what it is when you try to run, for example, any Swing program.) Personally, I'm not contemplating using Java for any serious development at this point whereas two years ago I was full of enthusiasm for the idea. Perhaps there are others like me?

    It seems to me that you just want to keep things the way they are. Well, it isn't working, that's plain for all to see. Look at the way Linux is leaving Java in the dust as a cross-platform vehicle for delivery of net-enabled applications. That's what Java was supposed to be. Linux has already stolen a lot of Java's thunder, and it will steal the rest unless Sun smartens up fast.
  • No, dillwad AC loser, we are using XUL and writing our own XPCOM components using NSPR, and delivering our "content" along with integration to our network services (almost hard to explain without showing the product). We are tracking the changes in Mozilla and the product works better now than it could work with any extant Java system (particularly when WORA practicality is a factor). The product won't be available for another couple of months, but we are already in testing.

  • Yeah, wiseass, I've heard of implements, and delegation, abstract base classes and factories, and design patterns, and UML, and all the other supposed means to get around Java's problems. Fact is, Java has them, and for any large scale project overall implementation time is increased over other common procedural and/or OO languages due to the fact that the design phase of a large project is longer than for other languages (due to the narrow ways that you are allowed to express designs in code). All that for a not-quite-portable slow language?

  • I do not scoff design time. Design time is the most important phase of development. Doubling design time because of the choice of pointlessly rigid implementation language is however ridiculous.

Adding features does not necessarily increase functionality -- it just makes the manuals thicker.