Slashdot Mirror

Now glassfish (the JEE5 reference platform) is monstrous, but it was intended to be the kitchen sink from the start.

70 MB, monstrous? http://java.net/download/javaee5/promoted/Linux/gl assfish-installer-v2-b22.jar

Well, the main reason to switch to 1.6 is that earlier versions won't run under Vista.

I Guess Sun was right. I see a comeback in the works...

https://jxta-remote-desktop.dev.java.net/ might be useful for you.

We've got all three editions of this book in our office and they keep getting better. As the review says, this book will teach you the difference between a DFA and an NFA engine if you want to learn that, or just how to do some simple capturing if that's all you need. Friedl's writing is very approaching and the book's notation for showing what part of a string a regex will select is very helpful.

And this stuff comes up over and over - if you ever need to tweak a JavaCC grammar knowing how to specify a DFA vs a NFA can make a nice performance difference. Great stuff!

We've got all three editions of this book in our office and they keep getting better. As the review says, this book will teach you the difference between a DFA and an NFA engine if you want to learn that, or just how to do some simple capturing if that's all you need. Friedl's writing is very approaching and the book's notation for showing what part of a string a regex will select is very helpful.

And this stuff comes up over and over - if you ever need to tweak a JavaCC grammar knowing how to specify a DFA vs a NFA can make a nice performance difference. Great stuff!

I should have also listed this link which lists all of the scripting languages that have at least some hooks already in Java and that are going to be affected by the new scripting specification.

"Looks like Sun doesn't want to lose out in the race in supporting dynamic languages."
I'm glad that Sun is taking more steps to make sure that the scripting support in the upcoming version of Java is decent. One thing that is kind of ironic about the first part of your statement is that Microsoft hired the Jython creator - hence Jython came first. I don't think a lot of people realize that Jython has been out for so long.

One reason I'm glad that they hired those two Ruby developers is that if you're going to implement an entire language within the JVM, make it complete and up to date - none of this - "Well we're 4 versions behind the current version of the language, but *it's in the virtual machine*!"

Also, the stated goal of the scripting support in the upcoming version of Java is to allow scripting languages to make calls to the Java backend - specifically if you have a php front end of a website and you have a Java backend, then it will become easier to connect the two. Not only that, but they're making a specification pretty open to any scripting languange.

Perhaps these two efforts coloborate.

Sun have finally seen the light, and have created packages that allow distributors to include Java in their operating systems: https://jdk-distros.dev.java.net/.

After a few back-and-forths with Sun's legal department, even Debian have packaged it for their non-free section: http://packages.debian.org/src:sun-java5. Users can simply install the sun-java5-plugin package. In a few days time, the packages will be eligible for inclusion in the forthcoming Debian 4.0 ("etch") release.

Thanks for the information - in that case I guess the only remaining hurdle is the license, and this page seems to say they're looking for an OSI-approved license.

Yes, there are ugly hacks to keep a connection alive, but it is exactly that, a hack, and introduces problems of it's own.

There are some ugly hacks to allow the server to "push" to the client (embedded flash objects, never-closed-connections, etc.)--mostly encapsulated by the moniker COMET (get it? Ajax... Comet...)

But if you get to pick your app server, there are some ready-made solutions. The problem with traditional web servers is their IO method. It's not their fault that the HTTP spec is out-of-date, but there are already new developments on the horizon that get around the current limitations. Take a look at GlassFish, Sun's new open-source enterprise application server, and pay particular attention to NIO socket writes. The performance benefits of NIO over straight IO are astonishing, with the side-benefit that it supports server-push out-of-the-box.

Yes, there are ugly hacks to keep a connection alive, but it is exactly that, a hack, and introduces problems of it's own.

There are some ugly hacks to allow the server to "push" to the client (embedded flash objects, never-closed-connections, etc.)--mostly encapsulated by the moniker COMET (get it? Ajax... Comet...)

But if you get to pick your app server, there are some ready-made solutions. The problem with traditional web servers is their IO method. It's not their fault that the HTTP spec is out-of-date, but there are already new developments on the horizon that get around the current limitations. Take a look at GlassFish, Sun's new open-source enterprise application server, and pay particular attention to NIO socket writes. The performance benefits of NIO over straight IO are astonishing, with the side-benefit that it supports server-push out-of-the-box.

Is it a combination of WinCE and TRON - Oct 2003

Earlier this month, Japan, South Korea and China announced plans to band together to create a Linux-based alternative to Windows - Mary Jo Foley - Sep 2003

'When the Japanese government announced it would install BTRON PC in Japanese schools, the U.S. government objected. It called the Japanese initiative actual and potential market intervention and threatened the move with sanctions.`

"Microsoft's decision to join the T-Engine Forum is not without irony. The company was the main beneficiary of U.S. government actions against the TRON project in 1989."

I don't see why everyone is so critical of PHP.

An ideal programming environment makes it easier to do the right thing than the wrong thing, makes easy things easy, and hard things possible.

The latter two PHP does a tolerable job on, considering what it is. It's not a good job by any means, but there are worse.

Where people like me start bagging on PHP is that for a very long time, PHP just about forced you to do the wrong thing. Then, they'd fix the wrong thing by adding another wrong thing. Then, they'd add backwards compatibility options for the first two wrong things, which set incorrectly constituted a new wrong thing entirely, and added a fourth wrong way to do something.

The canonical example of this was their handling of the construction of strings to go to the database. A number of wrong answers were provided. At least some of them are now deprecated and scheduled for total removal, but at least some of them remain, and I'm not sure that the officially supported libraries support the right answer even now. Even if they do, it took them way too many programmer years to get around to it.

Finally, after ignoring the people who knew what they were talking about for nigh unto a decade, PHP finally implements something sort of like the right thing, albeit making it hard to find underneath all the wrong things that are still there. And best of all, inexperienced programmers have absolutely no clue that all these things are wrong things, and go happily using them to create application upon application that has all the security of swiss cheese.

Ironically, considering the target audience, it took an extremely experienced developer to actually create a safe PHP application, and even the good projects have tended to have little problems with certain combinations of those reverse compatibility flags and stuff like that.

Now, I've carefully written all this in the past tense because I'll admit I have long since written off PHP. I could name 5 languages easy I'd rather do a web app in today, and heck, I'd rather learn a new language from scratch than use PHP. But it may be the case that it has significantly improved to the point where none of this applies. However, from what I have heard from here and elsewhere, it's mostly not the case; the security issues have gotten somewhat better but it sounds like the language has become a monstrosity. (Note that while this is the inevitable fate of any developing language... some are concerned that Java recently passed this point with the Generics feature that seems to defy even Java book author's abilities to understand, let alone explain... PHP is hitting this point without actually passing through any point at which it was the best solution for any but the very smallest of problems.)

Generally speaking, the PHP programmer community is the least mature community I know. And I don't mean like not swearing and being respectful; I mean it's just like 15-year-olds are designing the language from their base of six months of experience programming. I find it ironic to find out PHP started as a collection of perl scripts; by dint of great effort and years of work, they managed to produce a product inferior to Perl in almost every way.

> Start realising that the integration is a weakness, not a strength.

Looks like someone read only half of the Unix mantra, "Small pieces loosely joined". You read upto the small pieces part and forgot small pieces are useful only when they're joined. Joining is integration. It is at the heart of what drives software.

You see it in the money and energy being spent -- twice over! -- in writing a desktop environment for Linux. (In fact, every distro upgrade brings nothing except (shock, horror!) a little more polish and integration. You see it in dev tools, where tools like maven are managing entire projects.

There's integration and there's integration done right. One word for you: pluggable. Incidentally, that's what makes the Unix command line environment come together as a cohesive whole.

> Look at Internet Explorer. Now look at the security issues

IE's security issues come mostly from confusing the web/desktop boundary with their shell (which is a good idea) and the untrusted/trusted code boundary with ActiveX (which is a bad one). It's a rickety model but it doesn't mean no one can do better.

In this specific case, it's relatively easy to design things well so that the db is a pluggable component into the browser (The db should still ship by default, to spur adoption, but the point is it's basically a plugin). In fact the Derby folk already have a demo up. Similarly, a plugin approach could add every one of the other enhancements. All you then need is a revised DOM and a capable language for scripting and gluing the parts together.

Concerns of bloat are quite justifiable here, but the point is -- all of this is really Firefox + a few plugins. A _lot_ of the infrastructure is already there, it just hasn't come together yet. And people who just want a small, light browser can probably download a minimal Firefox build. Or Opera.

Java apologist? Listen, every language has its place. Ruby is an excellent script language, so is Python and Perl. C# is a rich language that simplifies development on Windows and qualifies as a RAD language in Visual Studio. Java is a good OO language, with compatible runtimes on practically every platform. It also has a rich developer community and a number of sophisticated frameworks, APIs, and specifications (J2EE, J2ME, etc.) that help businesses get rich applications developed quickly, consistently, and reliably. Many of the platform runtimes feature JIT-C, so platform independence performance penalties are minimized. Its not perfect, hardly any language out there is (Lisp is pretty darn close, though).

Anyhow, well written apps in any language will rock, whereas poorly written apps will suck. I've used all too many poorly written native Windows/Linux/MacOS apps to know that. I think Swing/SWT have plenty of well-written apps other than IDEs, like the Swinglabs demo at JavaOne 2006: Aerith (https://aerith.dev.java.net/) and LimeWire (http://www.limewire.com/english/content/home.shtm l) - not as clunky as Azureus.

This is slightly off-topic, but I think (less physical) 3D desktop management can be a lot better. Take Project Looking Glass for example. Did you ever wonder whose ideas MS stole with the Vista Aero thing?
  https://lg3d.dev.java.net/
Now you know.

Set up an RSS reader like reader.google.com or bloglines.com, then find a bunch of RSS feeds that cover that domain in some fashion. For Java, for instance, you can find some feeds here.

The key is that that it's really quantity and regularity that's most important- If you spend a little time each day immersing yourself in the terminology you'll start to get a feeling of who has the most credible opinions in that field and what those persons are excited about (so eventually you'll have quality covered as well).

There's a good chance that this will, of time, allow you to spot patterns and predict technology trends.

...kind of reminds me of the Google Web Toolkit which is more or less a Java to Javascript/HTML compiler. It's not an optimization thing like ShedSkin, instead it lets folks use the Java skills they already have to write better web apps. I wonder what they use to parse the Java code? I don't see any mention of JavaCC on their site, or ANTLR either for that matter...

The question is -- what is left to blog about at Microsoft at the moment anyway?

Oh, I don't know...maybe from their developer division, in no particular order:

• Windows Presentation Foundation, which basically defines a whole new way of building Windows UIs, complete with designer focused tools
• WPF/E, the subset of WPF which is supposed to run in browser and cross platform - including a .NET BCL subset.
• Windows Workflow Foundation, which has the potential to redefine basic business application development - including a rehostable designer that a business user can comprehend and possibly use.
• LINQ, which gives C# and VB compile time support for querying Sql, object graphs, and XML.
• Visual Studio Team Edition for Database Professionals, which brings database development into the same world as code development.
• The fact that Sql Server 2005 is slowly being morphed into an application server, complete with the ability to host the CLR, expose web services, perform data integration, etc.
• Office 2007 being (re?) positioned as a custom business application environment.
• A push towards supporting Domain Specific Languages within Visual Studio.
• Exchange Server 2007, which exposes a web services api, and allows for OWA embedding.

Yeah...that's about all the interesting stuff I can think of coming out of the developer division in the near to medium term. Note that I didn't state this stuff was any good (I haven't had the chance to toy with most of it yet), but I do think it's interesting and worth talking about.

Of course, their other divisions are no slouches either, so we also have (again, in no particular order):

• A brand new deployment format for Vista called Windows Imaging Format, which could make multiple Ghost images a thing of the past.
• A ridiculous number of Office 2007 servers, including a new version of Office SharePoint Server, not to (evidently) be confused with the new Windows SharePoint Services v3.
• OneNote Mobile, which finally puts OneNote where it belongs - on a Windows Mobile device. Now if they'd just add PocketPC support...
• Windows Compute Cluster Server 2003
• Virtual Server Host Clustering, catching up

For heavy number crunching interpretted is not there yet. Then again compiled code is not great for everything either, sometimes you have to write hardware specific assembly code. On the other hand if you are doing something that spends more time waiting in the user than actually working, then an interpretted language is great. Like everything you need to make a choice when you are going to use one approach or another. Remember you want to get a program out of the door and making it available to as wide an audience as possible so you will write in the language that is best suited for the task. If you know where to delegate the heavy number crunching then you can spend the rest of the time making a great program. Look at some of the programs written in Java using OpenGL. They are fast, but that is because they hand off the necessary heavy lifting to low-level APIs, heck even compiled languages like C/C++ do the same. See here for example: https://jogl.dev.java.net/

Yes, it was written by their lawyers, and was intended to clarify those aspects about the license the ftp-masters found troubling. Read the various posts about how java was accepted for details.

A major problem was the large disclaimer declaring the FAQ not legally binding. This appears to be a goof on the part of SUN, and the latest version clarifies this disclaimer considerably (see DLJ FAQ 1.2).

My company has been using Berkeley DB for quite some time and I must say that is indeed quite a good product. Sleepycat has great support and the tool itself is very stable. The java version is fairly new and doesn't have the features of the C version but works great as object storage.

However it is not very user friendly and also not very programmer friendly. It doesn't have any single protocol like JDBC for access because you can literally program it to do anything. Also the documentation is very sparse and there is only one GUI admin tool as opposed to about a jillion ones for SQL DB's. However BDBXMLAdmin from the java.net project is quite good and though its not quite a phpmysql competitor it is adequate https://bdbxmladmin.dev.java.net/. What it makes up in difficulty it absolutely makes up for in terms of raw speed and portability it just can't be beat and we have benchmarked it vs. HSQL and MySQL running in ISAM mode.

It looks like the oracle acquisition may actually be paying off as they were generally very slow in new releases and I don't know about the size of their development team but I would have thought they would have produced more for the time and the apparent caliber of the management team (bunch of Phd's that worked on the initial product). I hope that oracle can bring some muscle and polish to their product and maybe this will be one that they don't kill off with their questionable ideals.

Here's to hoping that BDB gets the recognition it deserves and I predict that with the right involvement it will be a strong player in the embedded applicaitons space, something oracle could never hope to compete in without a tool like this.

We are currently building a product for embedded devices in the RFID space and some of the things that need to be done can't be done with any other embedded db period. It really is so great to work with and handles Java and XML storage quite well.

------- Long time Addict, First Time Poster

I am entirely unsure how this would work in terms of dependancy solving, would it satisfy the same dependancies as the truly free java version or solve different dependancies?

The packages have their own names and thus do not resolve existing dependencies. Packages that wish to create a dependency on sun-java5-jre on Ubuntu, for example, need to explicitly refer to it (as well as assume Multiverse is enabled). Anyone basing a software installation on the new packages will have to do so explicitly and knowingly. As I said, this new step is simply a convenience (and one I have been asked for repeatedly since I started this job), nothing more.

I only took a brief look at the re-distribution terms of the DLJ and i fail to understand how debian could possibly redistribute it given the responsibilities it places on the distributer.

Do read the FAQ as well - the license was devised in consultation with Ubuntu and Debian community members in order to overcome the poison that had stood in the way of distribution via non-Free. The new license does not pretend to be DFSG Free.

On a related topic I think it's short sighted of Sun not open sourcing Java

Sun will. Soon.

Didn't read the license when you downloaded that? One of the provisions is that source code and modifications can only be shared with other licensees. Notice all the "Personal Research Use Only" parts?

http://download.java.net/jdk6/

Yes - we did the DLJ (see https://jdk-distros.dev.java.net/) not as a move to open source Java, but to make it more easily available. The DLJ's intent is clearly about easing redistribution by OS distributors. (BTW, I work in the jdk-distros team)

There's a couple things he missed in the article.

One is a nitpick. The way the DLJ goes, we require one person per organization to agree to the license. Not per user, per organization. In the debian bundles that's handled through a debconf key that remembers the license has been seen and agreed to. An administrator for an organization could distribute that debconf key and then silently install Java across their organization. At least that's what I've been told is possible.

The other thing he missed is the other announcement last Tuesday. The "it's not a matter of whether, but how" comment.

1. Leaks 5+MB of memory every time a laptop resumes.
2. It often seems to lose focus on dialogs, keyboard input only comes back if you switch away to a legacy (non-java) app and back again.
3. GTK look and feel is laughably bad.
4. The whole GUI development model has inadequate support for testing, at least by modern (junit) processes. SwingUnit looks like the only hope there, and it still feels a bit of an afterthought.

There, much better, a whole new set of complaints.

1. Leaks 5+MB of memory every time a laptop resumes.
2. It often seems to lose focus on dialogs, keyboard input only comes back if you switch away to a legacy (non-java) app and back again.
3. GTK look and feel is laughably bad.
4. The whole GUI development model has inadequate support for testing, at least by modern (junit) processes. SwingUnit looks like the only hope there, and it still feels a bit of an afterthought.

There, much better, a whole new set of complaints.

If you are compiling to bytecodes (*.class files), the "compiler" doesn't matter much. If you are comparing the runtimes of JVMs, which produce the binary executable ostensibly after the program starts, then we can talk. As for comparing GCJ's direct compilation to Sun Hotspot engine, GCJ loses almost every time and usually by a noticeable margin. GCJ at this point should be seen for its convenience in packaging, not its raw speed. (I still like GCJ, but let us call a spade a spade.)

You missed my (poorly stated) point. I wasn't arguing for or against one compiler or language, but trying to emphasize that the languages themselves are separate from their implementations. It's quite possible to make a C++ compiler that compiles to JVM bytecode or a Java compiler that compiles to native code.

First of all, no it doesn't load every jar into memory. It scans every jar for the classes and resources available, but it does not actually load their entire contents just for "Hello World."

No contest on this one. I mis-remembered this article. I'm not sure if you're right, but I was definitely wrong.

From a pure math point of view you are correct. In the real world you're quite wrong. Except maybe (MAYBE!) for the top assembly coders in the world, a non-trivial application will be faster written in C than assembly. Not only will the assembly language version take orders of magnitude longer to write than a C version, humans make mistakes. While one or twenty particular sections will be optimized ahead of the equivalent C version -- commonly through the exploitation of side effects -- what about ten or twenty thousand code segments? A C compiler will do a damn fine job and as good a job with the hundred thousandth code segment as it does with the second. That's the gain. The same is becoming (has become?) true of Java when compared to C.

You're right, it would take a huge amount of time to do that stuff in assembly language, or even C. But to state that something simply can't be done in assembly or C is wrong. It may not be done easily, but it can definitely be done. That's the point I was trying to make.

So yes, anything you do in a JVM can be done in assembly. However I am not aware of any non-trivial assembly projects that are completely rewritten to run faster on newer Athlon processors and completely rewritten again to run faster on Intel Xeons.

Of course not. Any gain in execution speed would be lost to the huge development time. Any sane person would write it in a higher level language.

On a side note, any such C re-compiler would want the original C source code for reference. Once you compile down to machine code, you lose almost all context as to what the programmer intended. The source code contains context. So perhaps you would create a meta language that stored the program structure? Maybe you could call them bytecodes? Then perhaps your C re-compiler would read these bytecodes in and optimize them for the platform and environment you're running in?

That's exactly my point. I didn't say it was a good idea, I said it's possible in C. But nobody does it because there are better ways to speed up code.

No, C++ is a multi-paradigm language. It supports OO as well as generic programming as well as procedural as well as template meta programming as well as... Even Bjarne Stroustrop calls C++ a multi-paradigm language, not OO. Where have you been? Hell, many top C++ language architects actively disdain OO usage in C++ like the original author of the STL, the hallmark of C++ generics.

Yes, it's multi-paradigm, and one of those paradigms happens to be object oriented. Whether it's good to use it as such is irrelevant. The OP made the blanket statement that OO

The DLJ terms are at: http://jdk-distros.dev.java.net/

Ah, just checked the homepage, local college = Georgia Tech. Not exactly a community college. Still, continuing education is more focused on the trade, not the fundamentals I would think. I'd still recommend JSF w/ Facelets.

This idea of specialized training in programming had got to go. If they know how to program and read standards, that's all they need to know in order to grasp the entire concept.

I wouldn't say that this is necessarily the way for a "continuing education" course to be taught. Fundamentals can take a year or two to teach. The submitter didn't give a whole lot of context, but I'm guessing this is perhaps a course at a community college (low cost, outsider putting materials together, etc.)

Since it must be in Java appropriate topics might include:

• EJB3/ORM
• The MVC Pattern
• Component based frameworks (e.g. JSF)
• AOP, IoC (i.e. Spring or Seam or some such), although its not just a web programming topic, you can't avoid it.

While we're on the subject of JSF, I should plug Facelets, which vastly simplifies the view side of things.

Your biggest concern will be having enough time for the students to get their head around whatever framework you do choose. Using Java for a small application is like sandblasting a soup cracker (to quote the bard). You could really spend a whole course on one part of the MVC.

about how RedHat are ungrateful bastards actually read the license? It has some serious nastiness in it.

Section 2 says you may not use it to develop Java software that is to be run on another system or use it in conjunction with any other language that implements similar APIs.

Section 4 says that if your OS fails to implement any functionality Sun wishes to use for the Java runtime you have 90 days to make it happen or you must stop distributing the runtime.

Beware of greeks bearing gifts is all I say.

explain how making the binary available as a no-charge download

For the last time, Java has the source available. It just isn't "Free Software" in the sense that you can't release your own binaries or fork the code.

Perhaps we'll see a repository for Java .debs at last, eh?

You must have missed the big news: official packages of Sun Java .debs were uploaded into Debian's non-free archive yesterday.

The announcement

Link to the page for the "source" package (I put "source" in quotes since it actually contains tarballs of the binaries, but you can obtain real source code in the sun-java5-source binary Debian package.)

License and FAQ about the license under which these packages are made available (note in particular that it permits sublicensing for derived distributions).

Perhaps we'll see a repository for Java .debs at last, eh?

You must have missed the big news: official packages of Sun Java .debs were uploaded into Debian's non-free archive yesterday.

The announcement

Link to the page for the "source" package (I put "source" in quotes since it actually contains tarballs of the binaries, but you can obtain real source code in the sun-java5-source binary Debian package.)

License and FAQ about the license under which these packages are made available (note in particular that it permits sublicensing for derived distributions).

Sun's press release
Offical Sun JDK Distros Project
Like a lot of people are already saying, you've been able to get the JDK source code for a long time now. The goal here is to fix the things that keep most Linux distro from including a JRE/JDK.

Well, for one thing, it is slower than native code

Statement with no proof, got to love that. If you even bother googling "java vs c++", you'll see plenty of benchmarks that demonstrate pretty much speed parity at non-GUI tasks.

For another, its garbage collection has a tendency to result in really bad performance stalls, making it useless for anything involving real-time (eve soft real-time) performance

Hence the reason for the related JSR and Sun's implementation.

For another, its portability has been hampered by not fully supporting interesting OS features, which means that there are all these OS-specific extensions to add things like audio support, making it not much more OS-independent than C when it comes to open source development. The result is that any apps that are very complex at all will utterly fail to "run anywhere".

Not much to argue although the JDK is constantly expanding to incorporate new features. The trick of course comes in when you have to decide - if feature X is only available on Windows, does one include it? Generally however, this is only an issue for the desktop - a space it's been struggling in. The enterprise market doesn't tend to face this issue.

For another, there is little incentive to ship a single binary for multiple hardware platforms. The extra overhead of building a binary for another platform is negligible once you get past the OS-dependent stuff (which Java for the most part fails to solve). If you have to do extra work for each platform anyway, you're 80% of the way to doing it right....

Umm... the JVM comes for a wide variety of platforms - even the ones for which Sun doesn't release the JVM, the companies developing the OS do (i.e. AIX, MacOS). And you say that Java fails to solve the OS-dependent stuff - compared to C/C++ it's far far ahead. I mean look at something like Netbeans - no OS dependent stuff (except maybe some look and feel). So you're argument is just flawed in so many ways.

Next, Java generally fails to result in apps that match the native OS look and feel, so Java apps tend to seem very foreign on any platform on which you run them.

When was the last time you actuall used Java. Swing's come a long way and integrates very cleanly into the OS (if done correctly). And it's also getting faster with every release.

They don't integrate well with other apps, don't do a good job of supporting OS services, etc

Not quite sure what you mean there.

With C and C++, assuming you separate out the interface properly, it is possible to write an app in which the vast majority of code is shared across platforms, but the UI portions are per-platform.

With Java you don't even have to do that saving on development time. Not to mention that with C/C++ you have to be familiar with the appropriate OS-specific API. With Java, there's only 1.

This allows much tighter platform integration for a relatively small amount of effort. You just can't do that sort of thing with Java in any practical way.

Define "relatively small" and what features you're adding that make integrate it better. And with Java you can do it in a more practical way - that's why there are 3-party libraries such as the Java Desktop Project

Finally, Java makes it hard to add debug functionality into your code without a performance hit. You can do this trivially in C with #ifdef code that makes the debug code fall out entirely. All you can do in Java is run-time testing, which hurts performance. The more debug code,

Well, for one thing, it is slower than native code.

Patently false. It has been false for years now. Ever since Chris Rijk published his earth shattering benchmarks. (More recent benchmarks here.)

It's now down to the skill of the programmer. A good programmer will write speedy code, and a bad programmer will write garbage. Who'da'thunk?

For another, its garbage collection has a tendency to result in really bad performance stalls

When was the last time you used Java? 1.1? The modern hotspot JVM uses a generational collector which should NEVER stall during runtime unless it begins running into memory pressure. Go try this game and tell us how many stalls you see. If you think that's too "simple", try this one.

For another, its portability has been hampered by not fully supporting interesting OS features, which means that there are all these OS-specific extensions to add things like audio support,

Is there something wrong with the javax.sound packages? I'm REALLY thinking that you haven't tried Java since 1.1.

They don't integrate well with other apps, don't do a good job of supporting OS services, etc.

Psst!

Finally, Java makes it hard to add debug functionality into your code without a performance hit.

That's just a weak argument. Debugging info can really screw up a codebase and should be removed after debugging. But if you're wedded to the idea, get one of the three billion preprocessors that are available.

The bottom line is that pretty much any compiled language has great advantages over Java.

The bottom line is that you haven't used Java since the days of 1.1, but you feel that you're fully qualified to make statements about a platform you know nothing about. Whether you intend to or not, you are trolling, sir. So I would ask you to stop spreading FUD by not commenting on Java until you are again familiar with the platform.

Sun also grants you a non-exclusive, non-transferable, royalty-free limited license to reproduce and distribute the Software, directly or indirectly through your licensees, distributors, resellers, or OEMs, electronically or in physical form or pre-installed with your Operating System on a general purpose desktop computer or server, provided that:
(...)
b) the Software is distributed with your Operating System, and such distribution is solely for the purposes of running Programs under the control of your Operating System and designing, developing and testing Programs to be run under the control of your Operating System;

c) you do not combine, configure or distribute the Software to run in conjunction with any additional software that implements the same or similar functionality or APIs as the Software;

you agree to defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees)

what the "pundits" have been calling for is the source code to the virtual machine and the compiler

WindBourne! I'm shocked to hear such garbage from you!

Current "Stable" JVM - <= 1.5 (SCSL)

"Unstable" JVM Branch - 1.6 (JRL)

Every, (and I do mean every) story on Java here on Slashdot has contained one of those two links. Most of them contain BOTH. Why? Because the trolls come out in force. The fact that you didn't take the time to look into the matter (I believe I suggested Googling for it) is disappointing and disheartening. :-(

Are you aware that Sun is allowing the Apache Software Foundation to create a 100% open source build of java that complies with the official Sun spec?.

This is the best of both worlds and gives those who want a "Free Software" VM their own VM, while allowing Sun to continue shaping the future of the platform according to outside comments (JCP - Java Community Process, a process where IBM, Nokia, Intel, etc. have a say), but preserving the right to prevent "pollution" of the platform like Microsoft attempted years ago with their windows-only win32 hooks in their Java implementation.

I think some slashdotters need to read The Inquirer more often... ;-)

Sun-approved Open Source Java making progress
http://www.theinquirer.net/?article=30688
MAR 31, 2006

Argentina students help Apache's Open Source Java effort
http://www.theinquirer.net/?article=30689
MAR 31, 2006

Apache Foundation to create clearn-room Java
with Sun's blessing
Compatible open source J2SE in the works
http://www.theinquirer.net/?article=23127
MAY 10, 2005

About Java based apps, the "Java is a failure on the desktop" is an old MYTH. Java has been getting really nice on the desktop lately, starting with J2SE 5.0 just at the time most systems above 1Ghz are now (finally!) the norm and at a time when 512MB ram is the average.

There's a lot of java based apps that I run on my linux AND windows desktop and whic I've learned to love:

  http://phex.kouk.de/ http://azureus.sourceforge.net/ http://www.artofillusion.org/index
http://www.evermoresw.com/weben/product/productOve rview.jsp - http://www.jedit.org/ - http://sourceforge.net/projects/frinika
http://sourceforge.net/projects/javaamp - http://sourceforge.net/projects/humaitrader - http://sourceforge.net/projects/jgnash/
http://megamek.sourceforge.net/idx.php?pg=main ...Editors, Music, Office Suites, P2P clients, 3D design, financial apps, games.... you name it, there is one best-of-breed app written in Java. And without having to chase a Microsoft API from behind like it happens with Mono...

https://mustang.dev.java.net/
"Sun is releasing weekly early access snapshots of the complete
source, binaries and documentation for Java SE 6 ("Mustang"). These raw snapshot releases let you review and contribute to Mustang as it is being developed."

What part of "Source" don't you understand??

I rest my case.

Finally about Desktop apps and Swing. Swing is MUCH faster in Java 6.0 (aka 1.6.0), because a lot of stuff is maped to native windows and gnome widgets.

The downside is that Homo sapiens cannot keep claiming that they are the only one that can talk on this planet. The up side is that we are not alone and that we can start chatting today with open source software from https://leafy.dev.java.net/

gray panels/gray rectangles are no more in Java 1.6 (at last!).

We had to wait, what, nearly ten years for that?

But at least once you use Java 1.6 it's a thing of the past. I use IntelliJ IDEA with JDK 1.6.

Blog entry from a Sun developer on that subject one year ago:

http://weblogs.java.net/blog/zixle/archive/2005/04 /no_more_gray_re_1.html

No more gray rect, gone... Bye bye and farewell, I won't miss them ;)

The situation is pretty good now, but it certainly hasn't always been like that.

The situation is pretty good now, but it certainly hasn't always been like that.

Not so fast. have you ever read the license? Basically merely by looking at sun JVM code you are agreeing to a lot of things that basically means that you'll never be able to work in a competing VM for the rest of your life, unless you want SUN lawyers coming at your heels.

Have you read the Java licenses recently? They were all updated a while back to be explicitly non-tainting, allowing people to study the reference implementations and still work on other VM implementations. Take a look at the JRL for example, FAQ item 18. They may not be open source but they're not actually out to get you either...

It would take the open source community years to beat Sun Java into shape: both the platform and the implementation are far below the quality that successful open source projects would tolerate.

Go look for yourself: Sun's Java source is of uniformly moderate-to-high quality, both in design and implementation, and always fully documented. Contrast with some of the big name Apache project Java sources and there's no comparison: the open source stuff is replete with empty catch blocks, not a line of Javadoc to be seen, upgrading a jar silently changes the contract of preexisting public methods, etc.

I'd argue that the quality of the development team (including prevailing practices and culture) matters far more than how the code is licensed.

What do you consider to be "successful open source projects" with better code quality than Sun's Java code, anyway? Fetchmail? Matt's Script Archive? Both quite successful in their day, by any metric.

Personally I think Dan Bernstein's C code (qmail, djbdns) is very high quality -- all edge cases checked; poorly-designed libc mechanisms avoided/replaced; his C source reads like Haskell -- but it's poorly documented, non-idiomatic, very difficult to read, aging, and not as widely used as its more "successful" competitors.

There's a reason why the top two server side platform these days are .NET and Java,

"Top" in arrogance and pay, at least, if not in the number of sites based on it.