Slashdot Mirror

Yes, C# and the CLR are ECMA standards but that standard is controlled exclusively by Microsoft. May I freely implement C# or the CLR? Of course. May I do anything to try and change that standard? Only if I go to work for Micrsoft or give Microsoft a lot of money.

On the flip side. Java is standardized by the Java Community Process. IBM, Novell, Red Hat, Apache, BEA and of course Sun are all members of the JCP and decide on the Java standards. To say Java is not a standard is absolute ignorance. The JCP is just as much of a standards body as the W3C. Any individual can join the JCP for free and corporations can join for a nominal fee. Can you get more open than that?

Is Sun's *implementation* of Java open? No. Is the Java standard open. Yes. Are there open implentations of Java? Yes.

People repeatedly argue that C# and the CLR are more open than Java. This is asinine. The entire Java stack from the language to the JVM to J2EE are all open standards by the JCP. I can implement any part or the whole thing without paying a red cent to anyone. Only a very small portion of .NET is an open standard.

If you develop a Java program on Sun's Java platform, you are liable to use Sun-only features without even noticing. By the time you find this out, you may have been using them for months, and redoing the work could take more months. You might say, "It's too much work to start over." Then your program will have fallen into the Java Trap; it will be unusable in the Free World. -- RMS

I generally respect RMS, but I have a problem with this. Like it or not Sun (and others via the JCP) set the Standard for Java. I fail to see how using the Standard is falling into a trap.

The real reason Java would be unusable in Stallman's "Free World" is because the current, free compiler is sub-standard.

I shouldn't use the features supported by Sun, Blackdown and IBM because the GNU Java Compiler hasn't caught up with the pack?

Now, whose trap is that again?

Looks like Groovy has been voted in unanimously by the JCP Executive Committee. Sun, in particular, seems enthusiastic about it by their comment.

If the rest of the process goes right, it appears to be on its way to eventual adoption.

There might be an advantage in having a tie-in language between Mono and Java platforms that is so similar to C# and Java syntax (the language is designed for Java people to pick up easily), but with some claimed advancements. Gnome can still tap into the C# and Java programming pool, hardcore C/C++ guys may find it a decent compromise and swallow their pride long enough to play with a new toy without admitting that they're using C# or Java. And, should M$ try to "extend" the C# language that they cloned from Java to make it more difficult for Open Source implementers, they would already be using a more stable (referring to language, not performance) Open Source language to depend on.

= 9J =

Looks like Groovy has been voted in unanimously by the JCP Executive Committee. Sun, in particular, seems enthusiastic about it by their comment.

If the rest of the process goes right, it appears to be on its way to eventual adoption.

There might be an advantage in having a tie-in language between Mono and Java platforms that is so similar to C# and Java syntax (the language is designed for Java people to pick up easily), but with some claimed advancements. Gnome can still tap into the C# and Java programming pool, hardcore C/C++ guys may find it a decent compromise and swallow their pride long enough to play with a new toy without admitting that they're using C# or Java. And, should M$ try to "extend" the C# language that they cloned from Java to make it more difficult for Open Source implementers, they would already be using a more stable (referring to language, not performance) Open Source language to depend on.

= 9J =

Looks like Groovy has been voted in unanimously by the JCP Executive Committee. Sun, in particular, seems enthusiastic about it by their comment.

If the rest of the process goes right, it appears to be on its way to eventual adoption.

There might be an advantage in having a tie-in language between Mono and Java platforms that is so similar to C# and Java syntax (the language is designed for Java people to pick up easily), but with some claimed advancements. Gnome can still tap into the C# and Java programming pool, hardcore C/C++ guys may find it a decent compromise and swallow their pride long enough to play with a new toy without admitting that they're using C# or Java. And, should M$ try to "extend" the C# language that they cloned from Java to make it more difficult for Open Source implementers, they would already be using a more stable (referring to language, not performance) Open Source language to depend on.

= 9J =

As long as you pay the fee, swear eternal fealty to Sun Microsystem Incorporated

No, you sign an agreement, the terms are not that harsh. There is no fee for individual memebers.

name all your software projects after coffee

Actually, after several years it was agreed that astronomy related names also were acceptable. ;-)

After this initiation ritual, you will be allowed to observe the gods of Java as they restlessly toil, and finally, after a ten years apprenticeship you will be allowed to speak.

No, once you are a member, you can simply mail a JSR, draft specifications or final ballot.

Compare this with Mono:
Join mailing list.
Say "Hey, I'd like to suggest/try this".
Response: "Cool!"

Well, I can mail one of my friends and say "Hey, I'm going to build a spaceship!". He might reply "Cool", or maybe "So you have finally lost your last shreds of sanity then?". So what? What do my friends or Mono have anything to do with the JCP?

You got to be kidding.
PHP has two primary strengths: architecture and standards.
Java is a general purpose language build from the ground up as an OOP. Java is used from embedded systems, mobile phones, desktops, webapps to world class enterprise projects. Java has a sound definition as a language and its virtual machine. Java standards are defined by the JCP with formal methods for approving changes including Apache.
AFAIK PHP is used only in webapps. OOP was added as an afterthought. PHP is a project of the Apache Software Foundation.
Architecturally has native standard access to databases and there are drivers for every db, supports distributed transactions, has message queues, takes advantages of multiprocessors, JIT native compilers in the VM, libraries for every need. Don't know about PHP but for what I know Java has a more advanced architecture.

The majority of java webspace applications were written before css and xhtml were mainstream.
What apps are you talking about? The PHP changelog shows that PHP 4.0 was released in may 2000. The great mayority Java webapps are based on servlet API 2.2 or later which where release on april 2000. Please explain how Java apps are less suportive of css and xhtml than PHP. BTW, how many PHP 3.x webapps are there?

I predict that there will be a need for css and xhtml conversions among the big java web apps and this will be readily delegated to PHP.
If I would have a Java webapp that needs to support css and xhtml it would be ridiculous to rewrite the app in another language, when it could be easily adapted. How would I explain it to my customer? There's nothing in Java or PHP that prevents using css or xhtml or making them automatically supported.

I don't mean that PHP isn't useful, but Java has just a broader scope.

Sun have a chance !

a Sun Virtual Machine ( SVM ) that has libs for java and can be targeted well by other langs

start with the JVM fix the Java memory model
(JSR 133, which has been active for nearly three years see article on fixing it and links at bottom located at )

let ADA and fortran target it well
(i.e. think about take floating point IEEE754 seriously but get it out there and tune later)

really not that hard look at Programming Languages for the Java Virtual Machine

Start with something you know well and adapt it

if it was refered to the ITU I bet they would love it and make it a standard !

regards

John Jones

The developers of C# unfortunatly had the luxury of looking at Java and taking what they wanted, along with doing some other things differently. Java isn't open source, and MS had the sense to open source / standardize the basic bits of C#.

You'd think people would have learned by now about the Java Community Process, a far more useful standards body (composed of companies and individuals) than a puppet ISO committee.

Java is a standard in all the ways that matter.

The developers of .Net did have the luxury of looking over Java and enhancing it - which they did to some extent (more in some areas, less in others). But of course they are also Microsoft, and so went there own way on some things to their detriment - and they simply didn't have time to copy everything, especially not all upcoming parts of the JCP. One thing I can't believe is that they didn't put in Generics from the start - I guess they were waiting to see of the JSR went on that one before committing the .Net implementation!

Now while everyone can point fingers and laugh at .NET, this is very smart for them. It makes it easier and cheaper for developers to make consistant apps in current and future versions of windows. If developers rely on ms code to handle the grunt work and they just do the stuff that makes their program, then they have a lot less overhead. And with microsoft grabbing it's balls and betting on security and stability, they can handle the backend bugs with their updates. True, that requires them to actually patch, but if they start with a much more stable and efficient groundwork, you'll see a lot less patches then now.

Did you realize that .Net is undergoing a major change in Longhorn, and everyone is going to have to fix a lot of code?

While they could get the benefits you name, they have only just finished copying what's in Java and starting to think about what else they could add - that goes in Longhorn.

P.S. - You want a glimpse into the future of .Net capabilites? Take a look here. Microsoft does...

There's also nothing preventing Sun from deprecating half the API on a whim.. in fact, they do that all the damn time.

I'd love to see you support that statement with facts. As far as I am aware, Sun categorically cannot "deprecate half the API on a whim". Like everyone else they are bound by the Java Community Process and have to implement what the Expert Group has specified for any given Java standard (JSR).

November 2003 Election Results.

or it is a standard not controlled by a single "for profit" entity

The standards are driven and approved via the Java Community Process which includes many people and organizations.

Apache Software Foundation, Apple, BEA Systems, Borland, Caldera Systems, Cisco Systems, Compaq, Ericsson, Fujitsu Limited, HP, IBM, Insignia Solutions, IONA Technologies, Macromedia, Matsushita Electric Industrial (Panasonic), Motorola, Nokia, Oracle, PalmSource, Inc., Philips, RIM, Siemens AG, Sony, Texas Instruments, and Zucotto Wireless, as well as an individual participant, Doug Lea, representing the research and education communities.

Those are the EC seats. Sun just has a permanent seat on that board. The board (not Sun themselves) make the decisions about what gets added to Java, as per:

Sun, and the other Executive Committee (EC) members, serve as technology oversight groups for the work of the Expert Groups. The ECs do not micro-manage the day-to-day workings of Expert Groups. Rather, the ECs have the opportunity to review the work of each Expert Group at well-defined points as their specifications proceed through the JCP. The primary function of the ECs is to ensure that specifications do not overlap or conflict with one another and that the specifications meet the needs of the industry segment for which they are being written.

You can find a list of what is currently being added here. You can join (as an individual for free), or have someone who is a member, submit your own JSR (here's how) to be added to the language. If the board (again, not Sun) agrees that it does not conflict with other JSRs, then you put together your Expert Group. Information on how this procedure works can be found here. Here's their recommendation on the expert group YOU put together:

The Expert Group should be large enough to ensure reasonable industry representation and diversity of opinion.

If you really have an interest in all of this, I would recommend joining the JCP, previewing the proposed JCPs, voting on them, etc. I have joined, and plan on writing up some JSRs when I have some time.

Apache Software Foundation, Apple, BEA Systems, Borland, Caldera Systems, Cisco Systems, Compaq, Ericsson, Fujitsu Limited, HP, IBM, Insignia Solutions, IONA Technologies, Macromedia, Matsushita Electric Industrial (Panasonic), Motorola, Nokia, Oracle, PalmSource, Inc., Philips, RIM, Siemens AG, Sony, Texas Instruments, and Zucotto Wireless, as well as an individual participant, Doug Lea, representing the research and education communities.

Those are the EC seats. Sun just has a permanent seat on that board. The board (not Sun themselves) make the decisions about what gets added to Java, as per:

Sun, and the other Executive Committee (EC) members, serve as technology oversight groups for the work of the Expert Groups. The ECs do not micro-manage the day-to-day workings of Expert Groups. Rather, the ECs have the opportunity to review the work of each Expert Group at well-defined points as their specifications proceed through the JCP. The primary function of the ECs is to ensure that specifications do not overlap or conflict with one another and that the specifications meet the needs of the industry segment for which they are being written.

You can find a list of what is currently being added here. You can join (as an individual for free), or have someone who is a member, submit your own JSR (here's how) to be added to the language. If the board (again, not Sun) agrees that it does not conflict with other JSRs, then you put together your Expert Group. Information on how this procedure works can be found here. Here's their recommendation on the expert group YOU put together:

The Expert Group should be large enough to ensure reasonable industry representation and diversity of opinion.

If you really have an interest in all of this, I would recommend joining the JCP, previewing the proposed JCPs, voting on them, etc. I have joined, and plan on writing up some JSRs when I have some time.

Apache Software Foundation, Apple, BEA Systems, Borland, Caldera Systems, Cisco Systems, Compaq, Ericsson, Fujitsu Limited, HP, IBM, Insignia Solutions, IONA Technologies, Macromedia, Matsushita Electric Industrial (Panasonic), Motorola, Nokia, Oracle, PalmSource, Inc., Philips, RIM, Siemens AG, Sony, Texas Instruments, and Zucotto Wireless, as well as an individual participant, Doug Lea, representing the research and education communities.

Those are the EC seats. Sun just has a permanent seat on that board. The board (not Sun themselves) make the decisions about what gets added to Java, as per:

Sun, and the other Executive Committee (EC) members, serve as technology oversight groups for the work of the Expert Groups. The ECs do not micro-manage the day-to-day workings of Expert Groups. Rather, the ECs have the opportunity to review the work of each Expert Group at well-defined points as their specifications proceed through the JCP. The primary function of the ECs is to ensure that specifications do not overlap or conflict with one another and that the specifications meet the needs of the industry segment for which they are being written.

You can find a list of what is currently being added here. You can join (as an individual for free), or have someone who is a member, submit your own JSR (here's how) to be added to the language. If the board (again, not Sun) agrees that it does not conflict with other JSRs, then you put together your Expert Group. Information on how this procedure works can be found here. Here's their recommendation on the expert group YOU put together:

The Expert Group should be large enough to ensure reasonable industry representation and diversity of opinion.

If you really have an interest in all of this, I would recommend joining the JCP, previewing the proposed JCPs, voting on them, etc. I have joined, and plan on writing up some JSRs when I have some time.

how about making J2EE more sensible?

Java 1.5 now incorporates metadata.

Sun has lost control of the Java development space. It does not provide leadership anymore or set the agenda. Open Source does.
There is a wellspring of innovation in Open Source that beats the productivity of Microsoft's friendly tools.

It mentions the JCP but ignores the power of that organisation over the OSS world. Open Source certainly does NOT provide the leadership in the Application Server space, BEA, IBM and SAP do. Open Source does not provide leadership in the IDE space, BEA, Borland, Compuware and IBM do. Open Source does not provide leadership in the J2ME space, Sun, Nokia and Ericsson do.

What annoys me about this article is its assumption that XDoclet and Ant can be compared with a J2EE application server. And that _standards_ are not important. The JCP is the key to all of this. In the same way as Ethernet won because it was a standard the JCP lays down standards for the Java space. ANYONE can take part, it doesn't even cost you money. And you can have a say in the direction of the platform, in a much more direct way that you could have with Linux for instance.

The point this misses is that Java has not succeeded as well as it has by being fragmented, it has succeeded because it is standardised. The JCP enables all of the partners to determine what goes into the platform. Sun propose JSRs, but so do IBM and BEA... and Oracle.... and SAP... etc etc etc.

Open Source could learn much by looking at the JCP.

Consider Wi-Fi, why is 802.11x successful ? Because its all open source ? Or because a regulated standard works well in a commodity marketplace.

Sun with have commoditised the Application Server and Mobile platform spaces. The JCP has for several years been the key to that success.

The trouble with Open Source advocates is sometimes they see everything as a nail.

Three specific quotes:

Q: How many people are currently JCP members?
A: The JCP has over 500 company and individual participants.

Q: What prevents Sun from controlling or dominating the groups that develop and maintain Java specifications?
A: Sun, and the other Executive Committee (EC) members, serve as technology oversight groups for the work of the Expert Groups. The ECs do not micro-manage the day-to-day workings of Expert Groups. Rather, the ECs have the opportunity to review the work of each Expert Group at well-defined points as their specifications proceed through the JCP. The primary function of the ECs is to ensure that specifications do not overlap or conflict with one another and that the specifications meet the needs of the industry segment for which they are being written.

The following EC members elected by the community during the JCP EC Elections in October and November of 2001 took office on November 20, 2001: Apache Software Foundation, Apple, BEA Systems, Borland, Caldera Systems, Cisco Systems, Compaq, Ericsson, Fujitsu Limited, HP, IBM, Insignia Solutions, IONA Technologies, Macromedia, Matsushita Electric Industrial (Panasonic), Motorola, Nokia, Oracle, PalmSource, Inc., Philips, RIM, Siemens AG, Sony, Texas Instruments, and Zucotto Wireless, as well as an individual participant, Doug Lea, representing the research and education communities

I think ESR doesn't understand that there could be open-source implmentations of Java if only he wanted one (in fact, there are). The Java specs are public, and anyone can implement against them if they feel like it. In fact, this whole thing can be thrown back to ESR -- he has said that open source projects come into existence because someone somewhere needs to "scratch an itch". So if Eric has an itch, he's free to start scratching.

Maybe he's talking about opening up the specs, but what would that mean exactly? There's good reason to say that it's happened already. Sun flirted with the idea of turning the specs over to a standards body some years ago, but it soon became clear that Microsoft would try to influence any such organization and bastardize the language. Remember, cross-platform portability is one of the highest-priority features of Java, the main reason it's interesting at all for Sun and many other players, but it's precisely what Microsoft most urgently would try to destroy. About the same time, Microsoft created a version of the JVM shot through with Windows dependencies and lacking some libraries they were required to implement, all in violation of the license, for which they were duly bitch-slapped by the courts (a set of facts that many Slashdotters curiously like to overlook). Sun learned the hard way that they couldn't go along with any standards process that could endanger cross-platform portability.

So now there is the Java Community Process, over which Sun has only limited control, and in which organizations such as the Apache Group participate. Arguably, this is at least as open as the standards processes for many open-source projects. Anyone can access the code to Apache software and the Linux kernel, for example, but only voting members of the Apache Group decide what goes into and out of Apache software, and essentially Linus and his lieutenants decide what goes into Linux. The JCP has its faults, but being strictly proprietary or less open than most of the open-source projects are not among them.

Finally, I'd like to know the grounds for ESR's claim that Sun's alleged control of Java is "throttling acceptance of the language in the open-source community, ceding the field (and probably the future) to scripting-language competitors like Python and Perl." Java has one of the largest development communities in the world with lively activity among open-source developers -- think of Jakarta. And although Perl and Python developers tend to disintegrate into a blue rage when somebody says this, Java is the language of choice for a wide range of industry projects, including the most business-critical applications, and Perl and Python certainly are not. (Flame away if you like, flail against the windmills, rage impotently against the stubborn truth.) I think ESR's insinuation of a dim future for Java due to the displeasure of open source developers is just blowing smoke.

Has this guy not heard of the Java Community Process or am I just really mistaken about how it works?

It's not the language, it's the libraries that are important and which microsoft have got control of. At leat with java you've got the JCP which is more open about the future of Java than anything coming out of microsoft.

Well....you obviously don't understand what the real issue is.
If it was about IDEs, then Sun would go after Borland, JetBrains, etc.

The real issue is Eclipse's fracturing Java with the introduction of SWT.
Sun has gone through great lengths to maintain a focused, extremely well defined, and open methodology for extending the Java language , APIs, and frameworks. It's called the Java Community Process

If you want to address shortcomings in the Java language, or introduce new APIs, or frameworks, you can submit a JSR (Java Specification Request) for review.

IBM pulled the old, take the ball and go home masturbatory routine with SWT--totally disregarding the JCP.

That's the issue. And I think Sun is justified in defending the JCP.

However, I'm standing ground on the comparison between MS & Sun w.r.t. Java technology. I'm not going to argue the case of weather or not Java should be open source. But what Sun is doing, licensing the spec and allowing other companies to build their products around that spec, and compete on their relative merits, is a far, far cry from what MS does with its IP. Sun has never claimed that Java is "open" in the Open Source sense of the word. What they can claim, is that the technology is developed implemented, and deployed in an open, industry accepted manner. Keep in mind that many of the fortune 500 who are embracing Linux/OSS also have large investments in Java technology.

I cannot agree with your statement regarding the "legal minefield" of Java technology. What IP/Licensing cases (except JBoss/Apache - which was an affirmation of the LGPL) can you recall from the past year?

Ok, so now that Java is on the retreat they try to enter a new area?

It's probably because there's no Java user community or usefull implementations out there. And it has virtually no practical application on the desktop for that matter. Maybe because it doesn't do 3D or sound. Or is not so usefull as far as scalable RDBMS abstraction or a real application server for the enterprise. Maybe they need to move into the mobile market. What's really needed is a good Java IDE to get developers on board. Changes should be driven by the software community and making the source open would help as well. Sun should also be making improvments in Java's next(?) version.

You're right, I guess "we" should just cut our losses.

yes, it sure would be nice if I could just deploy it as is to other IDEs!

Sure, it would be very nice. In fact, there is already a JSR for that matter:

http://www.jcp.org/en/jsr/detail?id=198

Just curious -
have any of the slashdotters used rule-based frameworks for real-life projects?
What do you think about Java Community Process Rule Engine JSR?
What about frameworks that try to keep things simple, like Ruleaid?

For your information the JCP is working in an interoperability API to script web pages in J2EE using PHP as a language.

This will be available with PHP as a working example, but it will be possible to use qny other scripting language instead.

The scalability/security/transactionality/etc stuff could be handled by the J2EE back-end. It will be just another way of scripting webpages, using PHP instead of JSP.

Check JSR-223 for more information.

Ricardo

Congratulations.

My favorites are ruby and C#/.net and they compliment eachother so well.

I'm curious, care to explain how these languages compliment each other??

I think Mono is the most important open source project second only to linux, because it will make the most advanced software platform in existence available for free on unix and windows.

Saying .NET is the most advance software platform in existence does not magically make it so. I can come after and say "no, you wrong, Java is the most advance platform", and we would have gotten absolutely nowhere.

I disagree with your assertion, by the way. And I have a few hundred JSRs at JCP.org to back me up.

Most of Java's development is done in the open. Which means tool developers have a heads up on what changes are coming and even have a say in it too boot.

It is also interesting that it is a useful tool for identifying those among us that are zealots and not software idealists. :-)

(i)I don't think that Mono makes much sense currently because it's a implementation of a development platform specifically designed to increase Microsoft's market share at the expense of everyone else.

(ii)Because Mono does not have any say in the spec it is implementing *and* the writer of the spec is historically hostile.

If that makes me some type of "zealot", I'll accept my title :)

I think that this is a bad analogy, as I have seen hard core Java apps that are less than 70k in size (Think Embeded cell phone/PDA apps) thats not an SUV. This guy hates SUV's and he Hates Java so he has equated them. Automatically makes this a bad analogy and more of a rant. In fact In my experience there is not a lot in this life that makes a good analogy to software engineering

Personally I dislike Java, Mainly for its unpredictable garbage collection and all the issues listed in the other comments above dealing with incompatable JVM's,deprecation etc, etc, etc. And I have had some rough experiences in mixing Java with Reused Legacy Code in Other Languages(Situations where Management,Customer and 3'rd Party Vendors don't give a lot of choice as to waht languages you can use)

What really scares me is that there is a big push for a real-time Java for the military in hopes that Ada can be replaced with Java:
Java in Mil Article
J-Consortium
JCP

Probably should have taken this one offline. Whoops.

However, I maintain that it is rare to need it in C++ otherwise.

Especially if you use something like ACE.

The point is that this is another requirement imposed on the programmer, whereas again in C++ it's handled by the language itself via templates.

That's true, it's an idiom in Java. The good news is, a lot of people complained, so templates are going into the language for 1.5. Before Sun committed to that, a ton of people used GJ. I don't look on wrapping as much of a problem, because usually the generic container doesn't do everything I want, so I end up wrapping the container anway (e.g. I want to label all the apples).

If you're unlucky, and the finalizer never runs, you have a resource leak. Alas, even Sun's own material sometimes implies that the finalizer will always clean up, which is not a safe thing to do.

That's because there's a lot of myths surrounding garbage collection. The GC doesn't read minds, and if there is heap left above its threshold, it's not going to make an attempt at cleaning up garbage. In small programs, you may not even see finalizers run before the program exits, which is usually not an issue. In memory intensive or long running programs, you end up with gigantic pauses when the GC decides to suddenly clean things up, much to the astonishment of the horrified programmer standing in front of the large group of VC. The myth is that the System.gc() call has no effect (or can't be trusted to have an effect), so no one bothers to call it. The truth of the matter is that System.gc() should be called once in a while, simply because the GC can't read your mind. So Sun's documentation isn't lying about the finalizer. It will clean things up, but the GC has to get involved with the object first.

At any rate, it's much better practice to call my_stream.close() explicitly in a finally block when you're done with the stream.

Oh definitely. Although with your own classes, you may want to implement finalize anyway, and have it call close or whatever. That way, if somebody forgets to close, it'll get cleaned up eventually.

In each case, you just use these to access your resources, and never have to write the release code again. If the resource ownership is handled by whatever library supplies the resource -- and in decent libraries it invariably is -- then you never have to worry about the release issue at all, and you never have to write even a single line of release code yourself.

That's what I was trying to point out. There's quite a few interfaces in Java as well that manage their resources so you don't have to. Actually, you've given me an idea for something more generic.

Didn't someone later write a lengthy criticism demonstrating that that idiom wasn't so safe after all, though?

From what I remember, they didn't implement it correctly. However, this too will soon be a moot point. Check out who the spec. lead is.

Generic types have been added to Java for public release in version 1.5.
There is an early access release of the compiler for generics.

For those people who want generics now, there is a non-Sun implementation of generic types.

But Java doesn't have the resources of Microsoft pushing it forward

Correct. It has the resources of Sun, IBM, BEA, Oracle and many others.

Sun doesn't seem to be interested in letting go of their platform any more than MS does.

Really? That will come as news to the members of the JCP. I hope you've taken steps to inform them that they're wasting their time.

In the beginning...Sun made AWT and it was very low level hardward/OS linked.

Then came Swing, which was more abstract, higher level, and less hardware specific, with more functionality in some areas and less in others.

Then came SWT, which came about to increase speed by moving closer to the lower level APIs, to avoid lots of bloat, to be closer to host OS look and feel, and once again more hardware/OS specific and this was good..

There are always differences, and more differences

---
Sun doesn't plan on abandoning its development all together (see Project Rave) I beleive it is suppose to be a new IDE implementation, but still based on Netbean foundation.

New Java Specification Request also include a common java ide plugin standardization, so this may be another reason they are doing some of this.

If you look at IBM's involvement in the Java Community Process for J2SE and J2EE you'll see there are over 20 IBM-led efforts under the umbrella of a process that is managed by Sun.

Sun may not have product to capitalize on Java, but as a steward of the standard, the company is still in a uniquely powerful position.

I'd have to agree with people's assertion that performance intensive apps should use a custom protocol and preferably binary based or some kind of delayed stream parser that only accesses the XML node when the app calls for it. I believe Sun has an API in the works for XML stream parsing JSR 317. It's too bad the jsr is still in public review phase. I've written custom parser in the past using SAX and it can definitely improve performance if you convert it to an object model. The question is trade off between being generalized and performance.

In the case of a webservice that uses schema, it's going to be hard to get around the performance issue. An obvious solution in situations where XML is required is to send as little as possible and only get the nodes you need. In that respect XPP2 and XmlTextReader help, until you need the entire document and you use the whole document.

1. This is a proof of concept that Microsoft's "Managed C++" stuff may be an interesting technology.

   If really Managed C++ isn't too much slower than C given the standard optimizations Managed C++ may become a viable platform for development in the end. We will see what will happen as Microsoft's JIT compiler matures.

2. If it is viable for Quake 2, it might be viable for any future game coming to PC, XBOX or even Phantom. Remember that having .NET (or Java with JNI as well, see this nice soviet Sturmovik simulator which really owns you ;D ...) allows you to access several non time-critical libraries (chat, rankings), or to prototype in an easier way several features that you wish to implement, without introducing slowdowns in the development and security issues (XBox savegame hack anyone?).

   I can remember Sony and other vendors being interested in a Java Gaming Profile for consoles... a very hefty addition to J2ME with JNI libraries for Physics, "Game Lobby" functionalities and mp3 streaming. That JCP anyway seems (in my experience) to be stalled. We will see if adoption of Managed C++/Managed DirectX will occur and will help the adoption of "Virtual Machines" technology in game consoles as well and revitalize the interest. Many titles, like Nihilistic Entertainment (of Zerstorer fame) Vampire The Masquerade use or used Java as a powerful scripting engine.

3. Anyway, remember that if you find Managed code to be too slow for your projects, you can always bridge your code with COM+, as Direct-X up to version 8 do succesfully :D... then using a COM+ component is easy as hell with .NET (let's hope that Mono makes this easy for Bonobo components too soon).

+ + + +
And now imagine embedding Microsoft Flight Simulator 2004 with Excel.NET... oh WAIT!

I guess I'm too much of a hard ass to expect the IDE to do so much, but you're right. Compile time validation is a Good Thing. Another would be visually displaying the /> tags. I've gone so long without a visual form editor for JSP, I feel like a king whenever I do Swing development. Supposedly JSF is supposed to address this. We shall see.

You're right that that allows you to have mutliple singletons (since thats what the parent post was about), but classloaders don't completely isolate programs from each other. A classloader can't load a dll if its already been loaded by another classloader in the same VM, for example. And unless a classloader is badly behaved, you're going to get the same stdout, stderr, and system properties.

There is a JSR on this which is going to introduce more isolation facilties, as part of the 1.5 "Tiger" release.

You're right that that allows you to have mutliple singletons (since thats what the parent post was about), but classloaders don't completely isolate programs from each other. A classloader can't load a dll if its already been loaded by another classloader in the same VM, for example. And unless a classloader is badly behaved, you're going to get the same stdout, stderr, and system properties.

There is a JSR on this which is going to introduce more isolation facilties, as part of the 1.5 "Tiger" release.

When things like JSR 184 "come of age". The "classic" games of 2006 could a quick game of network Quake while you wait for your bus.

Whatever you're smoking, can you share it with the rest of us?

First off, in essence, Java is a specification. Sun's implementation of the Java spec is the reference implementation, not the only one. And at this point it's a reasonably open specification at that. The JCP is a farce, you say? Then how do you explain the fact that the all of the new features coming out in Java 1.5 went through that process? Or that the majority of optional class libraries, such as Java Cryptography Extensions (JCE) and Java Advance Imaging (JAI), also went through that process? Have you tried participating in the process, or is bitching about it enough to satisfy you?

Other folks (most recently Redhat, as discussed in this Slashdot story) have been considering doing a completely open-source implementation for some time. I'm guessing we'll see one at some point, although realistically I don't see the need for it.

Secondly (and this provided me with my biggest laugh of the day by the way), do you actually believe that Microsoft was trying to fix the problems with Java?? In that case, I'll sell you the Brooklyn Bridge if you want it.... But getting back to the point here, from scores & scores of court documents it's obvious that Microsoft's purpose for "extending" Java was to fragment it & keep their desktop monopoly intact.

Believe it or not, even on Slashdot the "Just open-source it & all the problems will go away!" response is not always relevant. Sorry to rant, but stupid posts sometimes get me going.... I need a beer.

--Mid

If you have met Graham Hamilton you will know he has a brain the size of a planet. He may not have been involved in Java for 7 years but he has done a lot. Anyone who can be spec lead for jsr 59 and jsr 47 at the same time must know a few things.

If you have met Graham Hamilton you will know he has a brain the size of a planet. He may not have been involved in Java for 7 years but he has done a lot. Anyone who can be spec lead for jsr 59 and jsr 47 at the same time must know a few things.

The .NET Framework has a SLIGHTLY smaller footprint than the latest version of Java (46.5 vs 47.3 on my workstation). And it does more stuff -- a lot of the add-on packages for Java, including all of their J2EE crap, parellels what's already in the Framework. Not that it matters...including the framework on an install CD is trivial, and most Windows Update and XP users have it already.

You said it yourself. You can't really compare size like that since there is more to .NET than just the libraries and the VM. .NET uses a huge amount of bread&butter stuff in the Windows libraries, something which obviously can't be used by Java. At least not in the same way, since Java has to work on more than one platform.

.NET does NOT integrate the web into windows applications. .NET allows users to create web apps in much the same interface as standard windows forms, using a system called WebForms.

True, but it does integrate .NET into the web. It makes it very easy to build applications with much more "intelligence" on the client side, similar to building a XUL application using Mozilla.

The downside (or advantage, if you're Microsoft) is that you will only get these "rich" client experiences when running Explorer, preferably on Windows. But that's the whole point. Lock-in by pretending to be open, it's brilliant.

It also allows regular ASP pages to be compiled into faster versions a la JSP/Servlets.

True again, but they are still slower than JSP's on fast app servers, for example Orion. (disclaimer: I don't have the latest benchmarks so things may have changed).

What's cool about .NET is that the IDE supports all sorts of really useful data transformation and reporting mechanisms using SQL/XML/etc built right in...no rolling your own data access methods (though I end up doing it anyway).

These things has been available in Java IDE's/libraries/toolkits for longer than I care to remember. I believe it started with Sun's JavaBlend (which agreeably wasn't very good, but a lot has happened in the 6 or so years since it came out).

Today we have several frameworks, suitable for different needs. For example Hibernate, JDO, or, if you simply want a fast persistance layer: Prevayler. There are more, of course.

Also note that the the JDO specification allows different vedors to plug in different implementations so you're not relying on a single vendor. This goes for pretty much all of the J2EE specifications as well. I'll take that over Microsofts solutions any day.

.NET is better than Java for apps that will always be used on a Windows PC, because: - It has a much faster graphics interface, while maintaining a robust graphics toolkit.

And how do you know that your apps will always be used on a Windows PC? Do you have a magic crystal ball that can see into the future? Do you really want your apps to be limited to Windows only? Also, with the latest versions of Java, the speed difference (for well written applications, mind you) is neglible. Take a look at IDEA for a good example of a very efficient Swing application. And if you really believe you need native widgets, take a look at SWT, which Ecplise is built upon. But it's a pain to program in, and it's only really cross-platform on Windows. All other platforms suffer from the same problems as Swing apps do.

It has a better messaging mechanism (Events/Delegates are a GODSEND and are the sin

Effect number two:
A complete j2ee free-speech webserver installation online in under two hours.

Effect number three:
???

Effect number four:
PROFIT! :D
(or at least a major headache in Redmond).

+ + + +
Please note that the Java Community Process controls the standard. Of course Sun is a major player in it, but its standards are published, stable, and you know that your code is still going to work in three years or more. Something that doesn't happen when you code in some strange languages. :)

If anyone is going to make a virtual machine platform which takes the general design of Java, adds 3 opcodes to the platform, removes parts of the core libraries and replaces them with optional APIs and ships the platforms as "Java", Sun is going to sue his ass off.
Sun is already strong on the lawsuit against Microsoft.
Microsoft back then tried to replace java access to native machine features - jni - with a Microsoft proprietary library accessing activex objects, and java remote invocation process - rmi, based on Corba's IOOP - with another library based on COM+...
Sun demonstrated that Microsoft was wrong, and then won the lawsuit... the outcome however (barring the monetary reimbursement part) was ludicrous.

At least now we Java Programmers are programming in REAL JAVA, which works REALLY on different platforms, and not something that remembers unportable C/C++ for the splintering and fragmentation between platforms, compilers and coding styles.

+ + + +
No, I don't want to start a Java vs C/C++ flamewar.
Java is a tool suited for some works.
C/C++ are two other tools suited for other works.

Newsflash: Microsoft has gone and made a better Java -- C#, and funnily enough they not only standardized it with recognized standards bodies (which Sun has never done with Java), they've also released their own shared source version and have not at all stood in the way of third parties making their own implementations (dotGNU, Mono, etc).

• Microsoft still have options to deter the development of an open-source .NET implementation if they want to. They have the patents.>
• EMCA standards do not garantee much. EMCAScript anyone? We're still coding for JScript, and Javascript, even if EMCA "standardized" the language.
  
• Sun has the JCP @ JCP. Most Java standards development has been done through the JCP for years now. Sun recently had 4 of they JSRs turned down! They won't happy, but had to accept that the specifications won't be accepted as they are. I believe the specific standard increased the minimum requirements for Mobile Java. The process is open and does work.
• Oracle, IBM, and some of the largest software development companies in the world have billions riding on Java. These companies have always had and continue to have a say in how Java is done. I'd trust that situation over a bought specification to a patent-protected technology owned by a monopolist anyday.

I suspect Microsoft will tolerate dotGNU, Mono, as long as they see it beneficial to do so. Also, the language and runtime is not much. The true power of .NET and Java is in the wide amount of libraries available to these languages. I really wish the Mono team good like to replicating that in a source compatible manner. It would be no small feat.

I think you're argument is a little naive.

Gtk+, wxWindows, would only be a small subset of the .NET libraries or JAVA core libraries. There is a very large amount of APIs in those frameworks, from Messaging APIs, to binary component standards, object serialization, goes on and on and on. It's also very hard to get an entire team of developers on the same page concerning all these issues, so having them all in a single framework is very cost effect. Cuts training costs, etc. Think of what it would take to cover the ground needed to reimplement .NET. This is not a trivial task.

Furthermore, you don't need Sun-style central control over everything in order to get good cross-platform toolkits, as toolkits like Qt, FLTK, and wxWindows show. C# will have good cross platform support, either by successfully cloning .NET, or by binding to an existing cross-platform toolkit, or by creating a new cross-platform toolkit just for C#.

Yes we do need Sun's control. Because this was the only thing that prevented Microsoft from trashing Java last time they tried, and Sun has effectively handed much of it's control to the Java community process. Browse that site a bit if you would like to know what true community development/standardization is ( ie. compared to the patent/ip riddled shared source nonsense ).

You see, the fact that C# doesn't come with philosophical baggage like WORA and "100% purity" is an advantage as far as I'm concerned. What WORA and "100% purity" has brought us is lousy implementations of Java on Linux, and APIs that don't even let me access environment variables.

That's your biggest gripe with Java :)

"100% Java" means that "this product wasn't written my a company hostile to the java effort, eg. microsoft, who has included apis that are specific to their platform instead of using core apis which work on all platforms"

It is sad that this is needed, but it is.

That's how it exactly works, go look at the spec. 'SimpleIterator" is a read only iterator interface that does not have the "remove" method, java.util.Iterator now extends that. Any expression that has a type of Iterable, including arrays, will work in the enhanced for-loop.

Take a look at JSR 121 over at the JCP, which is slated for the upcoming Tiger release (Java 1.5).

It's actually interesting to see the development of the JVM, separately from the rest of the platform. Essentially it is parallelling the development of hardware-based computers, moving from being a unitask environment to finally being a multitasking environment under a managing OS.