Slashdot Mirror

Come on Microsoft, it is year 2013, 2014 almost. We are not in 2000 anymore, you can't just tell everybody to go screw themselves anymore and act like you are some kind of god. I don't think it is going to work as well as it used to...

http://slashdot.org/story/07/02/03/1524250/confidential-microsoft-emails-posted-online
http://www.javalobby.org/java/forums/t90205.html

Thanks for reading my stuff. Especially the blog, please do visit that one often. (I use AdSense, if you visit my blog about a million times I'll make a dollar or so.) ;) But do please note: I review tech books from other publishers, too. A few examples: http://www.javalobby.org/articles/jboss-seam-rick/ (Apress) http://www.javalobby.org/articles/beautiful-code/ (O Reilly) http://rickwagner.blogspot.com/2010/11/book-review-spring-dynamic-modules-in.html (Manning) Full disclosure: I always sign my real name to my reviews, I have never received payment of any kind from anyone, except for sometimes a copy of the book to be reviewed. My reviews tend to be honest but maybe a little on the kind side, as sometimes books appeal to some people but not all. I try to be as technically accurate as possible. Watch for future reviews: Erlang and OTP in Action (Manning) JBoss AS 5 Performance Tuning (Packt) Please do keep reading my reviews! Thanks, Rick

Thanks for reading my stuff. Especially the blog, please do visit that one often. (I use AdSense, if you visit my blog about a million times I'll make a dollar or so.) ;) But do please note: I review tech books from other publishers, too. A few examples: http://www.javalobby.org/articles/jboss-seam-rick/ (Apress) http://www.javalobby.org/articles/beautiful-code/ (O Reilly) http://rickwagner.blogspot.com/2010/11/book-review-spring-dynamic-modules-in.html (Manning) Full disclosure: I always sign my real name to my reviews, I have never received payment of any kind from anyone, except for sometimes a copy of the book to be reviewed. My reviews tend to be honest but maybe a little on the kind side, as sometimes books appeal to some people but not all. I try to be as technically accurate as possible. Watch for future reviews: Erlang and OTP in Action (Manning) JBoss AS 5 Performance Tuning (Packt) Please do keep reading my reviews! Thanks, Rick

Ok, here's some research. First, there are actually two memory areas in the VM, the heap and the Permanent Generation. It is a PermGen overflow that's causing Eclipse's problems, not heap overflow. As I understand from the linked article, PermGen is a place where VM data is stored; stuff like the class structure, method bytecodes (is that just a copy of the executable?), heap content information, etc. PermGen info used to be stored in the heap, but was moved out as a performance optimization, which incidentally is no longer relevant. I'm still not quite clear why PermGen has a fixed size. Evidently there are quite a few applications out there that routinely overrun PermGen and have to increase it. The cause seems to be people writing custom classloaders that bypass the "class already loaded" optimization, which I suppose makes sense for Eclipse where you keep modifying the class all the time and want to keep reloading it into the VM for testing. Apparently it is possible to write them in such a way that the resultant class metadata "leaks", resulting in overflow. Now, I think I'll just take a small break laughing my ass off at how those poor Java kids need 256M just to store their class definitions. I say, collect your garbage off my lawn and learn C++ already! It seems your fancy Java doesn't absolve you from the need to learn memory management after all :)

If you're incapable of doing memory management, you're an incompetent boob of a coder.

Ok, here's some research. First, there are actually two memory areas in the VM, the heap and the Permanent Generation. It is a PermGen overflow that's causing Eclipse's problems, not heap overflow. As I understand from the linked article, PermGen is a place where VM data is stored; stuff like the class structure, method bytecodes (is that just a copy of the executable?), heap content information, etc. PermGen info used to be stored in the heap, but was moved out as a performance optimization, which incidentally is no longer relevant. I'm still not quite clear why PermGen has a fixed size. Evidently there are quite a few applications out there that routinely overrun PermGen and have to increase it. The cause seems to be people writing custom classloaders that bypass the "class already loaded" optimization, which I suppose makes sense for Eclipse where you keep modifying the class all the time and want to keep reloading it into the VM for testing. Apparently it is possible to write them in such a way that the resultant class metadata "leaks", resulting in overflow. Now, I think I'll just take a small break laughing my ass off at how those poor Java kids need 256M just to store their class definitions. I say, collect your garbage off my lawn and learn C++ already! It seems your fancy Java doesn't absolve you from the need to learn memory management after all :)

Inside Sun we have used the TeamWare DSCM for many many years, and it has allowed us to co-ordinate distributed development between teams, both remotely and locally. The Mercurial DSCM will make this work even better, and allow anyone to join in, at the appropriate level and area.

http://www.javalobby.org/java/forums/t103115.html
OpenSolaris is using Mercurial, as is Java 7.

Their global market share is so tiny (2007/8 *sales*. Not to be confused by the total number of phones in active use!), and their lack of Java so ridiculous, that we professional developers couldn't care less. They are not worth the effort, just to make some Apple fanboys happy, who won't do anything but complain anyway, because your app got more than one clickweel.

All of these numbers are based on what completely flawed microbenchmarks from a site that used to be called "The Language Shootout". The numbers have been thoroughly debunked several times in the past. See this thread, for example: http://www.javalobby.org/java/forums/t86371.html?start=30 Or just google for "language shootout". It's not that the people who run this are just incompetent (making dumb mistakes like including JVM startup times). It's that they actively allow and even encourage cheating. For example, at least one of the "C" benchmarks actually uses hand-coded assembly (libgmp), and rather than stick to the obvious "program must be written in the language it's listed under" rule, the site maintainer suggests that the "Java" benchmark could be changed to also use assembly. This is all documented in the thread listed above. After several of these debunkings over the years, they had to change the name from "the language shootout" to something else, as any quick google will show that these benchmarks are completely bogus. Nothing to see here, move along.

I For one am still waiting for CrazyBob to stop working on Android and code Guice 2.0 because Guice 1.0 is not finished.

I guess the twubble is that it is much more fun to start a project than to finish it...

so java 6 is actually supported?

I just read this article http://www.javalobby.org/java/forums/t102936.html and of course read all the flames here on slashdot with Leapoard and java.

I was under the impression that Jobs preferred Coca and java 6 was never going to see the light of day.

Its true there are usage guidelines but I have been reading not even eclipse would run on leopard and no one cared.

If I am wrong let me know as I hate vista with a passion.

(Note: I am a Java developer by day.)

There was a huge, huge stink in the Java community when Leopard was released without Java6. Teeth were gnashed, complaints were shouted from the rooftops, great offense was taken. Threads of truly astonishing lengths were generated.

Watching all of this transpire made me incredibly embarrassed of the Java community. (Note: Predictable smart-ass comments can be inserted after the previous sentence.) The hue and cry was simply amazing and, let's face it, immature. "I want Java6 *now* and since it's not there I'm abandoning the Mac as my platform!" In other words: "I'm taking my toys and going home." Very, very few of the complaints were from people who actually depend upon Java6, i.e. are building apps with it. Instead, there was a large sense of entitlement that was unjustified and exhibitied a childish impatience that was amazing to watch, with a strong dose of the usual fanboy/hater streetfight.

*shrug* There were two choices that were much less reactionary: (a) wait for the Apple release Java6 or (b) work on the OpenJDK project. Kudos to Landon for doing this. It's a big start, and will hopefully generate enough interest to move it forward significantly.

Of course, people like to bitch, and neither of those choices fulfills that need.

While an open source Java port would be an interesting development, the real issue is whether Apple is interested to support Java on its platforms. A recent Javalobby article, titled So Long Apple. The Party's Over, gives several arguments supporting the position that Apple is doing a lot less than what it should in order to properly support Java. A high-quality implementation of the Java virtual machine needs all the help it can get from the underlying platform. For an illustration of this, see how slickly Java runs on Sun's Solaris. If Apple isn't interested to put its weight behind Java, it's unlikely that Sun will fill this role. Sun is putting a lot of effort to tune Java on the Windows platform; I doubt they have the resources and motivation to do the same with Apple's platform, due to the significantly lower market share of Mac OS X. So, while an open source port of Java is nice, full-hearted support from Apple would be a lot better.

Compiled applications are linked with the GCJ runtime, libgcj, which provides the core class libraries, a garbage collector, and a bytecode interpreter. libgcj can dynamically load and interpret class files, resulting in mixed compiled/interpreted applications. It has been merged with GNU Classpath and supports most of the 1.4 libraries plus some 1.5 additions.

Red Hat has signed Sun's OpenJDK contributor agreement and will now align the work its done on its IcedTea project, which was its own implementation of some parts of the Java SE JDK, with OpenSDK, said Shaun Connolly, vice president of product management for JBoss. IcedTea brought together the Fedora project with key Java technologies in a Linux environment, and currently provides open-source alternatives for the few remaining proprietary sections in the OpenJDK project, he said.

Red Hat has launched the IcedTea project, with the goal of creating a hybrid fully free Java implementation based on OpenJDK and GNU Classpath. The project replaces binary plugs that are still non-free with code from GNU Classpath "We have been working within Red Hat to replace these binary plugs with free software based on GNU Classpath and to remove the need for bootstrapping with unfree software. This is important for a number of reasons, the most pressing being that only free software may be used to build operating systems like Fedora", said Andrew Haily on an OpenJDK newsgroup.

IcedTea replaces the binary plugins with the equivalent GNU Classpath code, compiles it all using GCJ and optionally bootstraps itself using the HotSpot Java Virtual Machine and the javac Java compiler it just built.

Others are set to join him.

Almost 12 months since Java 6 was released on other platforms. Still waiting, Steve.

Once this stabilizes, I'll probably be using it. It's nice to see such a direct impact on my work from their contributions. Thanks guys!

The FSF maintains a list of GPL incompatible licenses that it considers "free software", CDDL is on that list.

I didn't say anything to the contrary. I simply pointed out that people shouldn't confuse "free software" with "open source software".

Sun has always preferred the CDDL, it has nothing to do with trying to be incompatible with the Linux kernel. OpenSolaris is CDDL, so it would only make sense for it's flag-ship file system to be CDDL as well.

You're misrepresenting the history. Yes, ZFS is CDDL because OpenSolaris is CDDL. But Sun didn't first pick the CDDL and then used the CDDL out of consistency for ZFS, they picked CDDL for OpenSolaris and ZFS was simply part of that. And there is no reasonable explanation for why Sun picked the CDDL over other licenses other than that they wanted OpenSolaris code as a whole (including ZFS) to be incompatible with Linux. The changes to make the CDDL into a GPLv2 compatible license would be trivial and of no consequence to Sun, but Sun chose to have those clauses in there.

How do you maintain control of the development of a GPL'd work?

The way Sun does it: the JDK is dual licensed, and most customers continue to use Java under a non-GPL license. Sun also maintains control through the TCK and their ownership of many of the documents defining Java.

Why would Sun open-source their TCK if they wanted to stop the development of open source implementations not under their control?

Sun has not open sourced their TCK. Quite to the contrary, they have been trying to use the TCK to maintain control of Java and exclude alternative implementations. This has been a major dispute between Sun and Apache:

http://www.javalobby.org/java/forums/t94330.html

http://www.javalobby.org/java/forums/m92169688.htm l#92169688

Now, tell us, are you simply so uninformed that you really believe that Sun has open sourced the TCK, or are you deliberately trying to deceive us?

The FSF maintains a list of GPL incompatible licenses that it considers "free software", CDDL is on that list.

I didn't say anything to the contrary. I simply pointed out that people shouldn't confuse "free software" with "open source software".

Sun has always preferred the CDDL, it has nothing to do with trying to be incompatible with the Linux kernel. OpenSolaris is CDDL, so it would only make sense for it's flag-ship file system to be CDDL as well.

You're misrepresenting the history. Yes, ZFS is CDDL because OpenSolaris is CDDL. But Sun didn't first pick the CDDL and then used the CDDL out of consistency for ZFS, they picked CDDL for OpenSolaris and ZFS was simply part of that. And there is no reasonable explanation for why Sun picked the CDDL over other licenses other than that they wanted OpenSolaris code as a whole (including ZFS) to be incompatible with Linux. The changes to make the CDDL into a GPLv2 compatible license would be trivial and of no consequence to Sun, but Sun chose to have those clauses in there.

How do you maintain control of the development of a GPL'd work?

The way Sun does it: the JDK is dual licensed, and most customers continue to use Java under a non-GPL license. Sun also maintains control through the TCK and their ownership of many of the documents defining Java.

Why would Sun open-source their TCK if they wanted to stop the development of open source implementations not under their control?

Sun has not open sourced their TCK. Quite to the contrary, they have been trying to use the TCK to maintain control of Java and exclude alternative implementations. This has been a major dispute between Sun and Apache:

http://www.javalobby.org/java/forums/t94330.html

http://www.javalobby.org/java/forums/m92169688.htm l#92169688

Now, tell us, are you simply so uninformed that you really believe that Sun has open sourced the TCK, or are you deliberately trying to deceive us?

Artima
eWeek
InfoQ
Java home
JavaLobby
JavaWorld
JDJ
The Inquirer
The Register
TheServerSide

But there are other kids as well:

12-year old Nigerian is a certified Java Programmer

12 year old programmer creates web browser

Pakistan's youngest certified Microsoft programmer - 9 years old

Covered in slashdot before

I'm giving up mod points on this article, but given the amount of misinformation you're getting, its better that I post a reply.

Sun isn't using GPLv2, they are using GPLv2 + the Classpath exception. This is a modification to the GPLv2 pioneered by the GNU Classpath project. It basically makes Java's code GPL, but doesn't require code running on the JVM, or using the J2SE libraries, to be GPLv2 complaint.

Links here:
http://www.sun.com/software/opensource/java/faq.js p#g5
http://www.javalobby.org/java/forums/t84256.html
http://en.wikipedia.org/wiki/GPL_linking_exception

Language independance

Yeah, 'cause it's not like you can compile other languages like Ruby to Java bytecode.

Look I've seen code break. You haven't. I don't care if you get a team of 30 coders with a combined experience of 900 years to tell me their apps haven't broken. I've seen apps break, and not only when the code's compiled for a later JRE. We've had to develop specific workarounds and re-release stuff due to this. I can't show you because I'm bound by an employment contract and I'm not about to embarass my employer even if I wasn't. That you don't believe me doesn't make an inkling of difference to my life. Enjoy your fantasy.

If you are going to reply at all the first thing I challenge you to do is explain this migration guide by Sun for Java 1.3 to 5.0:
http://java.sun.com/j2se/JM_White_Paper_R6A.pdf ...complete with a whole section on runtime issues

More references. Again not the best. Wish I could show you my good example but see above.
http://forum.java.sun.com/thread.jspa?threadID=731 921&messageID=4212821
http://www.codecomments.com/archive251-2005-5-4986 00.html
http://forum.java.sun.com/thread.jspa?threadID=432 494&messageID=2042086
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id =4783788
http://helpdesk.wisc.edu/page.php?id=2891
http://www.javalobby.org/java/forums/t18329.html
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id =6204839

The above links very clearly show installing the latest JRE is not sufficient to run all your old code. With many Java applications, you can't just remove all older versions of a JRE and upgrade to the latest.

I also recall that if your code is applet based, the tags used to invoke the JRE changed after Microsoft dumped their custom JVM due to the legal action between Sun and MS.

The bottom line is that you're calling anyone who has seen anything break due to a newer JRE a fool and a liar based on your "30 years of experience". I know for a fact that this is false. Your arrogance is astounding and your insistance on this makes me wonder what you've been doing for 30 years since I know of no complex environment where the runtime backward compatibility is so fantastic that you don't need to test a new version to be sure it works for your application.

Let me add some content to your Apple advertisement :)

Apple's JVM implementation has something called Class data sharing to speed Java startup after the first invocation. The first time is just as slow as always. Since then the feature has been added to Sun Java 1.5, so if you're up to date, you should have this.

Swing slow?

http://www.javalobby.org/articles/swing_slow/index .jsp

The parent is a troll (possibly an IBM troll).

Sun paid tons of money and spent years writing the class libraries. Why should they give their work away for free? They license this code to IBM, Oracle and BAE for a significant sum. Why should they give up this revenue?

Sun has changed the licensing for the JRE to allow it to more easily be integrated into Linux distros. The parent is either ignorant of that fact or deliberately omitting it.

Sun is less likely to maintain to maintain the standard if they open source the code. What kind of ass backasswards reasoning is this?

Why embrace SWT? This is IBM's attempt to bastardize the JDK. What's more, it's not pure Java. For instance, when I bought my Intel iMac, NetBeans 5.0(pure Java Swing) worked immediately, whereas an SWT library needed to be replaced for Eclipse. Why should Sun integrate a less than fully platform independent competitor's attempt to break a standard?

See this blog for more analysis on SWT vs Swing:

http://www.javalobby.org/java/forums/t18544.html

The jury is out on whether SWT is technically superior to Swing.

If you think Eclipse makes Java development easy, you obviously haven't used NetBeans 5.0, which is significantly superior to Eclipse in every way. It includes functionality out of the box (JSP compilation) that you need to pay for (MyEclipse) with Eclipse.

You obviously have an IBM bias with the following stated positions:

1) Open Source Java so IBM doesn't have to license class library source from Sun.
2) SWT should be included in JDK, thus polluting the standard.
3) Eclipse is the best IDE and makes developing Java "easy", with no mention whatsoever of the clearly superior NetBeans 5.0, or, for that matter, IntelliJ.

Since JBoss is private, Marc would have to be willing to sell JBoss to Larry. Larry can't just write a check, get regulatory approval and be done. There is no way Marc will sell his baby... I think he is much more interested in JBoss someday being bigger than IBM & Oracle. The world is moving toward software as a service. JBoss is positioned to be the king of that world. Marc knows this. 10 years down the road, no one will be paying for enterprise software licenses. Marc sees this and won't let even $400 million get in the way of JBoss being king of that world. I probably sound like a Marc loving lunatic. But we have to be honest. Marc created a virus that's exponentially eating away at Oracle, IBM, etc's business models. That virus can only be stopped if Marc sells. I've seen the smile on his face when he talks about the virus he created. By the time JBoss is public and purchasable by Larry, even Larry won't be able to afford it.

(Reposted from my comment on Javalobby)

GNU Classpath, has completely implemented over 98% of JDK1.4 and is building steam. Most packages are now 100% complete, and momentum is building.

GNU Classpath, Essential Libraries for Java, is a GNU project to create free core class libraries for use with virtual machines and compilers for the java programming language.

More discussion is here.

That is a liability disclaimer, so if you use Java for something it wasn't designed for, Sun doesn't get sued. Also, Sun would like to sell you an RT version of Java instead. ;-)

RT Java is currently being used in one of the major military autonomous aircraft programs. There was a blurb about it at Javalobby.

Before those who go on to dismiss Java for various reasons (no matter how ignorant they are), take a look at the presentation given by Google at this year's JavaZone conference on how Google is using Java internally at extreme scales. Among them are AdWords and GMail.

Do you have any stats I could look at to support your statement? Just curious...

yes, I do.

I have been severely critical of Swing performance in the past, however it has improved dramatically.

here is a single post which gives a typical comparison:

http://www.javalobby.org/java/forums/m91832009.htm l

But in the end, the best thing to do is to download NetBeans + Java 5.0 and Eclipse (the GTK version is best) and try them out.

All the current suggestions from other posters I would agree with, Dr. Dobbs, ACM, IEEE, CUJ. But probably, like regular media, the smaller players are picking up the slack, even if they are web only. ServerSide, JavaLobby, IBM Systems Journal, Software Development, Artima Developer, JavaWorld, and DeveloperWorks are a few of the excellent ones I regularly read.

Or apache: News on Harmony

Fortunately Sun does let us fix bugs now.

Take a look at this article:
I fixed the JDK!

This guy submitted code fixes and actually got accepted by Sun and rolled into Mustang code!

Swing is generally slow because developers don't take the time to learn how to use it -- they end up overloading event listeners instead of using SwingUtilities to offload the logic onto the SwingWorker thread..

It's not so much of a speed issue as it is a visual response issue.

Here's an excellent presentation on how to go about coding swing properly...

The difference between Java and Mono is not a technical one in the first place. Both are modern platforms with a JIT compiler and a prefered OO language. Both run on multiple platforms and for bioth are multiple languages available.

The problem is more a political one. On Mono, future language extensions are dictated by Microsoft. The Mono developers could of course extend their VM in any way they want. But they would loose compatibility with Windows.

On Java everyone can join the Java Community Process (JCP). Membership is free and every member is entitled to vote and can even run for election.

Datails can be found at Javalobby.org.

"Power arises when groups of people act in concert." (Hannah Arendt)

There is a very interesting online presentation (slides with speech) here : http://www.javalobby.org/eps/swarmstream/ (Flash player required)

Open source does not always equate with free (as in speech). Do we really need to cover this (yet) again?

Java is a nearly total failure at desktop applications, and will remain so, because Sun doesn't give a damn about enabling native Java apps to deliver user experiences comparable to those offered by native apps.

Every day I use one of the most successful Java desktop applications (jEdit), and like it very much. So it should tell us something when the author of that application, Slava Pestov, advises programmers to "just give up" on Java for the desktop:

It is clear that Java was never practical for developing real applications, and never will be. Instead of asking how you can revive something that's obviously dead and gotten much more hype than it deserves, you should be asking if there's better technology out there.

First released notice in May.

This is a good demo of the power of Java, it handles the game, then passes this smoothly to the native opengl rendering. Jogl is great, I hope I can find time to work with it some more.

Those crazy Germans do deserve some awesome credit for this! (having lived in Germany I can say I love Germans, and they are crazy! :-)

Sourceforge page

Open source won't use Java until Java is open source. Most OSS developers are wary of traps like that.
(Which caused reluctance to using Qt, which sparked the Gnome project. Now Qt is free, of course.)

Java is certainly going open source. Not Sun's java, but there are plenty of open-source VM:s, and compilers, and a full implementation of the class library in the works.

I predict that, when these projects reach sufficient maturity (AWT/Swing support being the achilles heel in all the above), we will see widespread adoption of Java in the OSS community.

What Sun does will have little impact on the OSS community unless they get serious about open source and put Java under a tolerable license.

(If someone's curious about what is bad about the Sun license, see Dalibor Topic's post here, containing a point-by-point comparison to the Open-source definition.)

Java is getting much better on the desktop (FINALLY), but it is most definitely at its best on the server.

Why? Am using Java on the desktop every day, it's fine. Check out some Java apps screenshots.

They post this and completely ignore Java on Apple ][.

*sigh*

You know what's even worse? Slashdot rejects funny submissions. Here's the text of my submission that got rejected twice(!):


In one of the oddest moves yet, Guillaume Desnoix (head of the JDistro project) has ported the open source Kaffe Java Virtual Machine to his Apple ][c. When asked why he did it, he said, "The main reason was to fasten my programming daily work. I felt a little limited by the 6502 instructions and wanted to enjoy the highlevel bytecode of Java." Read the full scoop over at JavaLobby.

You know what's even worse? Slashdot rejects funny submissions. Here's the text of my submission that got rejected twice(!):


In one of the oddest moves yet, Guillaume Desnoix (head of the JDistro project) has ported the open source Kaffe Java Virtual Machine to his Apple ][c. When asked why he did it, he said, "The main reason was to fasten my programming daily work. I felt a little limited by the 6502 instructions and wanted to enjoy the highlevel bytecode of Java." Read the full scoop over at JavaLobby.

"anything you do after looking at Sun's source code may be considered a derived work"

That's not so; this week at Javalobby Sun JCP Director Onno Kluyt states that looking at Java sources does not taint and is willing to answer FSF questions on the issue.

"anything you do after looking at Sun's source code may be considered a derived work"

That's not so; this week at Javalobby Sun JCP Director Onno Kluyt states that looking at Java sources does not taint and is willing to answer FSF questions on the issue.

> Getting more contributors to OSS Java projects would
> be a pragmatic and actually helpful goal to work
> towards. As opposed to demanding Sun give away their
> source. IMHO

Just for reference, those of us currently involved in
developing free implementations of Java have not, to
my knowledge, demanded that Sun give away any source.
ESR has, but he doesn't speak for us.

Of course it would be hugely helpful if Sun gave away
their source. That would be man-years of work we wouldn't
have to do. For instance, right now some people are
actively working on Swing. I would expect this to take
quite a long time... Sun could shorten that considerably

We don't really expect that, however. And we don't really
need it; we'll do ok at our own pace.

The things we really could use, and that I at least really
would like Sun to change, are:

* Access to the TCK. No free implementation has ever
been run against the TCK. It has never been available
under suitable terms. E.g., becoming a Sun licensee
is not acceptable.

* Access to the JCP. I'm told that at the moment there
are still terms in the JCP that prevent developers of
free Java implementations from participating. So, for
the most part, we stay away. This is particularly
unfortunate as participation in the JCP would be
mutually beneficial.

* Lift restrictions on subsetting. Those of us working
on free implementations all understand that there is
a huge amount of value in compatibility. We don't
want to fragment the platform -- we aren't MS. However,
free software isn't well suited for a "have one big
complete release" model. Instead we do things piecemeal,
as they are implemented. In the past anyway, Sun
has frowned on this sort of thing and made various
attempts (e.g., in JSR click-throughs, or even in
licenses at the front of books) to prevent this.

The next question, though, is "what's in it for Sun?".
What is their incentive for opening things a bit more?
Unfortunately, I don't have very good answers here, yet.
I do think the free software community and Sun could
be natural allies in this space. Java has made good
inroads into free software, however it is still a work
in progress. E.g., Mono has appeared, perhaps in 5
years C# will have displaced Java in the free world
as well.

...Slashdot is days late on the scoop. The Java community has already figured out that this is business as usual between Sun and IBM.

There is a lively discussion about how slow and cumbersome j2ee is on javalobby right here

These are advocates of Java complaining about how much j2ee sucks.

I for one think that you need to be a rocket scientists to write a large j2ee application that can perform realatively fast while anybody can write php applications that can run fast.

(* Do note that we are generally moving away from efficiency towards clarity and simplicity. *)

How do you explain that sh*t Java then?

Java is simpler and clearer than C++. Or do you disagree?

My point was that if it was compiled, it would have an edge over a VM.

You can compile it. But the report (and this one) shows that the compilation vs VM issue is quite irrelevant. You can create fast code with a VM!

Where did I say that Java sucked because that writer was stupid? It is both. Java AND that writer suck.

You put it on a page that is called: "Why Java Sucks". Put it on a seperate page if it's a seperate topic.

(* blaming the language for having flaws that are not explained (what is wrong with the reflection in Java?) *)

It is too convoluted. There is plenty of criticism of it on the web and ng's. Go look.

I know it has limitations. The point is that you should explain your claims. Complaining that X is lousy without giving proof or even telling people why it sucks will make me ignore it. Who are you trying to reach with your critique? Programmers that already know all about Java's reflection limitations (only an issue to experts really)? If they already know the limitations, what good does your page do? Your critique is pointless.

What is wrong with being multi-paradigm? C++ can be multi-paradigm.

Multi-paradigm means chaos then. I prefer clean design, not Perl or C++.

Only zealOOts think one paradigm fits all.

I don't remember saying that Java needs to replace all competing languages. I do think it's a very good one. BTW, you can use various scripting languages with Java. You can also call native code if Java doesn't cut it.

How hard would it be to add functions to Java anyhow?

Excuse me? Could you elaborate?