Slashdot Mirror

A little detail: "Java" is both a platform and a language. C# is just a language, one of several that runs on the .NET platform. (Microsoft doesn't like the word "platform", but it's the only one that fits.) So when you're analyzing market share, you need to compare Java with .NET, not with C#.

The figures you quote show .NET doing pretty good, though still lagging way behind Java. One little improvement in the Java language is not going to spell the "death nell" for the .NET platform. That would be true even if .NET didn't have the backing of the biggest software company on the planet.

What is bad news for .NET is the fact that Sun seems to be capturing a lot of developer mind share with its Java Community Process, which is where this proposal comes from, along with a lot of other good stuff, including JSR 166, which originated outside Sun, and has successfully added a major improvement in concurrency to the Java platform.

The JCP won't spell the "death knell" to C# or .NET either, not as long as they have MS's backing — and are essential tools on Windows. But it will certainly help Java hold onto its lead.

A little detail: "Java" is both a platform and a language. C# is just a language, one of several that runs on the .NET platform. (Microsoft doesn't like the word "platform", but it's the only one that fits.) So when you're analyzing market share, you need to compare Java with .NET, not with C#.

The figures you quote show .NET doing pretty good, though still lagging way behind Java. One little improvement in the Java language is not going to spell the "death nell" for the .NET platform. That would be true even if .NET didn't have the backing of the biggest software company on the planet.

What is bad news for .NET is the fact that Sun seems to be capturing a lot of developer mind share with its Java Community Process, which is where this proposal comes from, along with a lot of other good stuff, including JSR 166, which originated outside Sun, and has successfully added a major improvement in concurrency to the Java platform.

The JCP won't spell the "death knell" to C# or .NET either, not as long as they have MS's backing — and are essential tools on Windows. But it will certainly help Java hold onto its lead.

or, better, Resin [not completely free]

even a basic stand-alone Tomcat (yup, a Java server!)

or, better, Resin [not completely free]

even a basic stand-alone Tomcat (yup, a Java server!)

Sun is releasing the Java libraries under the GPLv2. The article never really explicitly makes that clear, but given that they're talking about the Java2D library it should be deadly obvious that they're releasing the entire J2SE library under the GPLv2.

An appendix to this specification motivates and defines a policy for the removal of existing features from the platform.

Per that policy, this specification proposes the removal of the javax.sound.midi package in a future release of the platform. This package is not often used and typical implementations of it require a large data file, about half a megabyte in size, which is a significant component of minimal Java Runtime Environment (JRE) download bundles.

This proposal does not mean that the javax.sound.midi package will be removed in Java SE 6. This proposal is merely the first step in the feature-removal process defined below. This proposal serves as a warning that this package may be removed in a future release of the platform, but whether it is actually removed, and in which release, is a decision for future expert groups.

In no particular order:

Java as Open Source will help in creating smaller versions - perhaps very lightweight browser-plugins - optimized for particular use (media, number crunching, etc.). These browser plugins will help revive Java as a thin-client/web2.0 (3.0?) player in browser-based apps, possibly even making some small inroads against Flash. The 'apollo' project from Adobe may put the kibosh on this, but the increased-eyeballs angle will likely prevent a complete obliteration from happening to desktop Java.

Java will become even faster. Although this has happened in 2006, with the release of Java 6, the full impact will be a refitting of the niche Java apps out there to work specifically with Java 6 and the speed improvements there. This will give some Java some good PR points and case studies with the 'Java is slow' crowd (which I'm definately a member of).

(As I think one of the panelists in the article said) - there will be a greater acceptance of dynamic languages (ruby/php/python/etc) in Java shops, as Java6's support for dynamic languages (JSR 223 I think) will help increase productivity for Java devs willing to think outside their javaBox.

• New database connection API, JDBC 4.0: JSR 221
• New version of web services API, JAX-WS 2.0: JSR 224

• New database connection API, JDBC 4.0: JSR 221
• New version of web services API, JAX-WS 2.0: JSR 224

• New database connection API, JDBC 4.0: JSR 221
• New version of web services API, JAX-WS 2.0: JSR 224

• New database connection API, JDBC 4.0: JSR 221
• New version of web services API, JAX-WS 2.0: JSR 224

Maybe as open source software people will be able to look at it and ask *why* does it have to take up so much memory to do such simple jobs? Compare for example Azureus (in Java) to bittorrent (in Python).

You have been allowed to look at the code for many years. It is not like there is some easily fixed bug, I think it has more to do with the them spending more time on stability and getting more speed. Sun engineers have been working hard on the memory use issue for a while now. For instance, in the upcoming Java 6 they moved away from memory mapping whole jars, and instead only mmaps the file "central directory" and read in the rest of the file only as needed.

Also, they appearently liked what Ethan Nicholas wrote so much they hired him to work on a minimal kernel version of Java. See also JSR 270 and JSR 277 which for the first time will allow removing parts of java, and if they are needed later, dynamically loaded at runtime. So you can have server java without including AWT/Swing/3D/Media, and desktop Java without xml parsing etc.

Maybe as open source software people will be able to look at it and ask *why* does it have to take up so much memory to do such simple jobs? Compare for example Azureus (in Java) to bittorrent (in Python).

You have been allowed to look at the code for many years. It is not like there is some easily fixed bug, I think it has more to do with the them spending more time on stability and getting more speed. Sun engineers have been working hard on the memory use issue for a while now. For instance, in the upcoming Java 6 they moved away from memory mapping whole jars, and instead only mmaps the file "central directory" and read in the rest of the file only as needed.

Also, they appearently liked what Ethan Nicholas wrote so much they hired him to work on a minimal kernel version of Java. See also JSR 270 and JSR 277 which for the first time will allow removing parts of java, and if they are needed later, dynamically loaded at runtime. So you can have server java without including AWT/Swing/3D/Media, and desktop Java without xml parsing etc.

Another example of a very, very large fork was GnuEmacs/XEmacs.

It is not unprecidented, if someone had good reason to do so. However I don't think it would happen because pressure enough to seek a fork of that size would at least try to work through the JCP java standards body to add what they were seeking. And many things people would like to do with Jaqva can be done as libraries, fewer things need to modify the language itself or the bytecode structure.

Only now that MS has started championing a pretty much official IronPython effort has Sun discovered dynamic languages, and started working towards making the JVM more dynamic-languages friendly.

Actually, there is more than a *slight chance*.

The jvm will support(in java 7) a great deal of what is necessary via this jcp:
http://jcp.org/en/jsr/detail?id=292

it's approved and everything!

Really, the only thing that is actually needed to make it perfect( for smalltalk, my true love ) so far as I know is to make code hotswapping a guaranteed thing. But with this feature, the status quo won't suck. And goodbye slow reflection.

The JRuby folk can also help iron out bugs in the JDK/JRE which inderectly benefit all Java developers/users. Also this will hopefully ease off the preassure to include everyones' favourite feature X into Java, something that in my opinion is threatening to turn Java into an even bigger mess than C++ (you know, an octopus created by nailing extra legs on a dog).

Fourthly, because there is just a slight chance that Sun will decide to make the JVM more flexible and amenable to languages other than Java.

JSR 223, a framework for "allowing scripting language programs to access information developed in the Java Platform and allowing scripting language pages to be used in Java Server-side Applications" has been kicking around at least since 2003 and is included in the upcoming JDK6 which comes with the Rhino JavaScript engine included. Other scripting people like JPython and Groovy have done great work (from what I understand, I'm not a fan of dymanic languages myself).

Good that this was finally posted on Slashdot, I was a bit peeved when my submission was rejected.

Then again, java would also have to completely revise their J2EE APIs, but that's a different rant...

You mean ... like this?

The purpose of Enterprise JavaBeans (EJB) 3.0 is to improve the EJB architecture by reducing its complexity from the developer's point of view.

I know, I shouldn't feed a troll....

You are the reason they were reluctant to make it (fully) open source.

You obviously are confident you know more about what makes a good language than the designers of Java do. Have you read even one paper at jcp.org? Have you looked at the people who make up the JCP? IBM, Apple, Cisco, Intel, HP, ATI, NVidia, Creative Labs, Google (!), Apache, Apogee, Namco ... you really think you're smarter than their combined intellect and months of discussion? Trust me, you're not.

I'm sure you and a lot of others are already giddy with excitement over the idea of making a "better Java" with const and operator overloading.

When you understand the "less is more" principle, you'll begin to understand why all your pet features don't belong in the language.

I know, I shouldn't feed a troll....

You are the reason they were reluctant to make it (fully) open source.

You obviously are confident you know more about what makes a good language than the designers of Java do. Have you read even one paper at jcp.org? Have you looked at the people who make up the JCP? IBM, Apple, Cisco, Intel, HP, ATI, NVidia, Creative Labs, Google (!), Apache, Apogee, Namco ... you really think you're smarter than their combined intellect and months of discussion? Trust me, you're not.

I'm sure you and a lot of others are already giddy with excitement over the idea of making a "better Java" with const and operator overloading.

When you understand the "less is more" principle, you'll begin to understand why all your pet features don't belong in the language.

Clearly you've never read the JSR-168 spec or you'd know that portlets are little web applications that adhere to standards so crippling that the easiest way to communicate between two portlets on the same server is to utilize the clients' web browser in a convoluted AJAX hack.

Since you didn't say what kind of server you're building, I'm going to assume:
- ...
- the language is C, C#, or C++, and not Java (process-based servers in Java?)

But I've never heard of MS suing an open source project or programmer. All MS can really do is change their software so it no longer interops with OSS (which hardly "crushes" any OSS) or distribute GPL software without making the source available.

OSS hasn't posed a serious threat, yet. But if Mono does take off, Microsoft will be looking to crush it. Which means that they'll use any dirty trick they can think of, including patent warfare. While they're pretty new to patents these days, I have no doubt that they'll abuse them if they need to. Some examples of former history:

- Microsoft promised "royalties" to SpyGlass for each copy of IE sold. IE was released for free, thus Microsoft didn't have to pay.
- Microsoft refused to license Windows 95 to IBM in time for the launch if IBM didn't sever their relationship with Netscape.
- Microsoft "offered" to make Netscape a Windows-only product, and threatened to crush them if they didn't agree. (We know what happened there.)
- Microsoft annouced the non-existant Windows product when Visi-On became a threat to their DOS market.
- Microsoft refused to license NT 4.0 code to Citrix so that Citrix could update their NT 3.51 product. Instead, Citrix was "graciously" offered to give their technology to Microsoft in exchange for the ability to market their ICA protocol as an add-on to the Windows Terminal Services product created with Citrix's technology.
- Microsoft sics the BSA on companies who refused to upgrade to the latest version of Windows. (Because they must be pirating, you know.)

Those are just a few off the top of my head. There's a whole backlog of Microsoft's misdeeds that I could dig up. The scary part is that former Microsoft employees often admit to these misdeeds with pride! (see: Barbarians Lead by Bill Gates for an example.) Microsoft will do anything it takes to ensure dominance. They are not an entity you willingly trust if you can help it.

There are plenty of Java libraries that are not part of Sun's source, and whose specs are not even freely available.

Name one. I dare you. I'm willing to bet you'll find the specs right here.

Of course if you RTFA, you would know that this is what Stallman means when he refers to the "Java trap".

No, this is not what Stallman refers to. He believes that Java is a trap because the source code is not "free as in freedom", and that you'll be "trapped" by the convenience. He also complains that Sun doesn't allow him to call his software an implementation of a standard unless he's 100% compliant with the standard. (Duh.) God forbid that Sun require that implementations of a standard actually implement the standard.

because it's not a proprietary standard

Neither is Java.

http://www.jcp.org/en/home/index

Like it or not, the JCP is a REAL standards committee with thousands of members whos only goal is to standardize Java and Java-based technologies.

because it's not a proprietary standard

Neither is Java.

http://www.jcp.org/en/home/index

Like it or not, the JCP is a REAL standards committee with thousands of members whos only goal is to standardize Java and Java-based technologies.

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,

JSR 179 is the standard for J2ME location services. http://www.jcp.org/en/jsr/detail?id=179

Java's language features were updated only when it got some competition from C#.

According to http://www.jcp.org/en/jsr/detail?id=14, discussion on generics officially began on May 11, 1999. (Exactly seven years ago.)

According to http://www.jcp.org/en/jsr/detail?id=201, discussion on enums, foreach loops and autoboxing officially began on December 3, 2002.

According to http://www.jcp.org/en/jsr/detail?id=175, discussion on annotations officially began on March 19, 2002.

Those are just the beginnings of formal proceedings. It's probably safe to assume the concepts were in someone's head well before those dates. The JCP doesn't just let every whimsical thought immediately become a JSR, after all.

But you shouldn't need hard dates. Compare how many times Microsoft has created something from scratch successfully, with how many times they've copied other people's work. Suggesting they invented those language features is like suggesting AOL invented the Internet.

Java's language features were updated only when it got some competition from C#.

According to http://www.jcp.org/en/jsr/detail?id=14, discussion on generics officially began on May 11, 1999. (Exactly seven years ago.)

According to http://www.jcp.org/en/jsr/detail?id=201, discussion on enums, foreach loops and autoboxing officially began on December 3, 2002.

According to http://www.jcp.org/en/jsr/detail?id=175, discussion on annotations officially began on March 19, 2002.

Those are just the beginnings of formal proceedings. It's probably safe to assume the concepts were in someone's head well before those dates. The JCP doesn't just let every whimsical thought immediately become a JSR, after all.

But you shouldn't need hard dates. Compare how many times Microsoft has created something from scratch successfully, with how many times they've copied other people's work. Suggesting they invented those language features is like suggesting AOL invented the Internet.

Java's language features were updated only when it got some competition from C#.

According to http://www.jcp.org/en/jsr/detail?id=14, discussion on generics officially began on May 11, 1999. (Exactly seven years ago.)

According to http://www.jcp.org/en/jsr/detail?id=201, discussion on enums, foreach loops and autoboxing officially began on December 3, 2002.

According to http://www.jcp.org/en/jsr/detail?id=175, discussion on annotations officially began on March 19, 2002.

Those are just the beginnings of formal proceedings. It's probably safe to assume the concepts were in someone's head well before those dates. The JCP doesn't just let every whimsical thought immediately become a JSR, after all.

But you shouldn't need hard dates. Compare how many times Microsoft has created something from scratch successfully, with how many times they've copied other people's work. Suggesting they invented those language features is like suggesting AOL invented the Internet.

• Concurrent Programming in Java: Design Principles and Pattern (2nd Edition), by Doug Lea.
• Java Concurrency in Practice by Brian Goetz, Tim Peierls, Joshua Bloch, Joseph Bowbeer, David Holmes, and Doug Lea.
• Effective Java Programming Language Guide, by Joshua Bloch. Though this is a general programming guide, its chapter on Threads contains essential "best practices" for concurrent programming.
• Concurrency: State Models & Java Programs (2nd Edition), by Jeff Magee & Jeff Kramer.

You should also note that your complaints about the limitations of Java concurrency are addressed in JSR 166, which has been part of the Java platform since 5.0. This defines a new package with many nifty features. There's excellent coverage in this JavaOne talk.

> No", who would run PHP on Java anyway?

Those who are fed up with the JSP crap: http://www.onjava.com/pub/a/onjava/2004/06/09/jsf. html?page=1

> Why?

Because Apache/PHP on Tomcat delivers java based content more than two times faster than Tomcat standalone: http://php-java-bridge.sourceforge.net/NEWS

> Why would open-sourcing it help?

So that we don't have to re-invent the wheel everytime a new API comes out: http://php-java-bridge.sourceforge.net/server/docu mentation/API/javax/script/Bindings.html. Note that it is (C) by Nandika Jayawardana , Sanka Samaranayake, a clean-room implementation of the abandoned JSR223 API from SUN: http://www.jcp.org/aboutJava/communityprocess/edr/ jsr223/

Also note that the JSR223 API is *not* part of the official java, rather a re-written API which has been inspired by JSR223. If java were free software (not necessarily open-source) that crappy JSR223 API whould have never appeared.

> No, what is lacking?

Support for Unix Domain Sockets. Because of this the FreeBSD Java implementation is 300 times (!) slower than the Java implementations on Linux, Solaris or Windows:

http://groups.google.de/group/comp.lang.php/browse _frm/thread/1eeeddb37086688/8d3414d188a327a9?rnum= 2#8d3414d188a327a9

And

http://php-java-bridge.sourceforge.net/snaps/FreeB SD/TestServ.java

Interesting post, just have issue with this one point:

For the same reasons as above. Quick, easy, graphical, sharable. Java is more restricted in that it can't really be run as a script - it can barely be run when compiled into bytecode! - so you don't get the same feel of "what happens when I change this here".

Java can very easily be run as a script throught the use of BeanShell which is now officiallyl JSR 274

I threw together a pretty simple IDE for kids to do this called JTurtle. Still needs a little work, but it was a fun app to write :)
Kids get syntax highlighting, a C/C++/Java style syntax, and instant feedback. JTurtle can be used to write procedural or object oriented scripts and the full java API is accessible if they want to do something more advanced.

That stuff sounds really interesting. Do you have links for some of the research?

Yes. The best place to look is the specifications at the JCP.

JDO 2.0 is

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

EJB 3.0 (including JPA) is

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

I've heard of hibernate, but not the JPA. Is that going to be part of the standard JRE? I hate having my code rely on goofy 3rd party add-ons.

JPA is going to be a standard part of J2EE, but can be used stand-alone with JRE. There are many vendors providing implementations - Sun, Oracle, JBoss, BEA, JPOX, Versant. A significant number of these are going to be open source (JBoss, Oracle, BEA). Hibernate is also going to provide an implementation of JPA.

That stuff sounds really interesting. Do you have links for some of the research?

Yes. The best place to look is the specifications at the JCP.

JDO 2.0 is

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

EJB 3.0 (including JPA) is

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

I've heard of hibernate, but not the JPA. Is that going to be part of the standard JRE? I hate having my code rely on goofy 3rd party add-ons.

JPA is going to be a standard part of J2EE, but can be used stand-alone with JRE. There are many vendors providing implementations - Sun, Oracle, JBoss, BEA, JPOX, Versant. A significant number of these are going to be open source (JBoss, Oracle, BEA). Hibernate is also going to provide an implementation of JPA.

In 5 years, it's possible that making everything parallel will be a basic principle just like making modular code.

I've been tasked with re-writing this document so that it describes Java concurrency in terms of JSR 166 instead of the more primitive thread management currently described. It only took a little research to convince me that I'll not be able to do more than scratch the surface. It's a huge topic. What I plan to do is guide the reader to a simple use case involving caching in a ConcurrentHashMap. (I still haven't figured out what to cache: it has to be resource-intensive enough to make the example realistic, but not too complicated. Ideas, anyone?) Then I'll point people to several thick, dense books such as this one, this one, and this one. After which they're on their own.

Mildly interesting but in terms of modern games it won't cut the mustard so then you are looking at smaller games and a platform to learn on. IMO there is only one top platform to learn game programming for and that is the Java mobile phone platform J2ME that even comes with a standard (and pretty simple) 3D API. Its also the fastest growing gaming market out there at the moment, and its still an area where mere mortals can break in and create the killer game and make money. Aiming at the PC market means you are against the multi-million dollar budget folks and that just isn't sensible.

If you want to learn game programming... get a decent phone.

Several folks pointed out that you could get the midlet (the term for the type of app sprint runs) on the phone by hosting it yourself or downloading via a cable, and bypassing Sprint's site and the need for a developer's certificate.

They are correct, but they are also missing part of the story.

They part they are missing is: in order to use some of the APIs on the phone, your midlet must be "blessed" by the operator. Technically it has to say the protected features it wants access to and be signed by the manufacturer or operator. All this is covered in the MIDP2.0 (JSR-118) spec. I was a member of the committee that wrote that spec.

So, if you want to write a local game you don't need any of that magic: you can do everything you want via the "untrusted" (that is: unsigned) profile. But to do some of the more advanced features (like using GPS data, or being able to be woken up when not running - push registry) you have to be signed by the manufacturer or operator.

Anyone who's read to this point will probably have noticed that the folks who make the phone or sell the phone (manufacturer or operator) are able to bless applications, but the folks who bought the phone cannot. This wasn't an accident.

When the committee was working out the details of the protection model manufacturers and operators were well represented. The only third party developers present were companies that were beholden to operators. There were no end users or corporations represented, so their interests didn't get a lot of weight.

I don't think it was evil intent by any of the parties. Its just that went these standard committees meet each representitive makes sure their interests are protected, and those who aren't present don't get a voice. This is a very common problem for most standard committees; its not unique to the JCP or MIDP. But it does help to explain why you, an 3rd party developer is a second class citizen even for your own phone, let alone your customer's phones.

For example, VB programmer may with some training be able to move his old VB code's business logic to .NET server.

Wrong. VB.Net is very, very different to VB6 to the point where much of the code will have to be rewritten to either run or run well. Not to mention that there will be extensive training required for VB6 developers to learn the more OO ways of VB.Net.

and that way looking far ahead of Java where you can only 'plug in' with Java only.

Wrong. There are many languages that will run on the JVM e.g. Python, Groovy, COBOL. See here for a full list. Not to mention that having multiple languages is a nightmare in itself for support, maintenance but thats just IMHO.

Besides Microsoft with it's traditional method, is trying to support .NET much as it is possible.

Great. One company supporting .Net. For Java we have: Sun, IBM, Oracle, BEA, Apache, CA, HP, Novell, Apple etc etc. Just look at the list of supporters for the JSR-168 (Portal) and JSR-170 (Content). The JSR process whilst not perfect is a great part of Java and why the platform is doing so well.

More I look .Net, more I've started to wonder why it has been so overlooked.

Easy. (a) Because Microsoft is the ONLY company involved. And that company just happens to have a long history with anti-competitive behaviour (b) Because I want a choice of which servers/OSs to developer and deploy on (c) I want competition so the quality of all the technologies will increase. .Net provides none of these. Java provides all of these.

For example, VB programmer may with some training be able to move his old VB code's business logic to .NET server.

Wrong. VB.Net is very, very different to VB6 to the point where much of the code will have to be rewritten to either run or run well. Not to mention that there will be extensive training required for VB6 developers to learn the more OO ways of VB.Net.

and that way looking far ahead of Java where you can only 'plug in' with Java only.

Wrong. There are many languages that will run on the JVM e.g. Python, Groovy, COBOL. See here for a full list. Not to mention that having multiple languages is a nightmare in itself for support, maintenance but thats just IMHO.

Besides Microsoft with it's traditional method, is trying to support .NET much as it is possible.

Great. One company supporting .Net. For Java we have: Sun, IBM, Oracle, BEA, Apache, CA, HP, Novell, Apple etc etc. Just look at the list of supporters for the JSR-168 (Portal) and JSR-170 (Content). The JSR process whilst not perfect is a great part of Java and why the platform is doing so well.

More I look .Net, more I've started to wonder why it has been so overlooked.

Easy. (a) Because Microsoft is the ONLY company involved. And that company just happens to have a long history with anti-competitive behaviour (b) Because I want a choice of which servers/OSs to developer and deploy on (c) I want competition so the quality of all the technologies will increase. .Net provides none of these. Java provides all of these.

Both have a reputation for being slow, insecure,

Maybe on Slashdot... Java has an excellent track record for security. Compare with the PHP worm that swept the net, or PHP based framworks like NukePHP that are hacked so regularly that sites are unusable. .Net I haven't kept up with, so I don't know how they do security in real life.

Server side java is REALLY fast. On artifical benchmarks, java can be as fast as C++, and these people wrote a high performance Linux cluster monitoring tool in Java.

If you need more proof, Java is now the preferred language for Boeing when doing mission critical and real time software. NASA used it during the Mars mission...

and proprietary.

You can join the Java Community Process for free as an individual and vote for how future versions of Java will look like, Sun has handed over control over just about everything but the Java trademark to this JCP. There are also plenty of open source implementations of compilers and JVMs. Sun keeps donating stuff to the open source community. DTrace, Solaris, 1600 patents, cryptography tech....

J2ME is the subset, cut down version for embeded devices like PDA's/Mobile phones etc.

J2EE is a superset of Java which adds the Enterpise level extensions to the core Java technology.

In summary :

* Java Servlets
* Java Server Pages (JSP
* Enterpise Java Beens (EJB)
* Java Connector Architecture (JCA)
* Web Services
* XML services

You can read the full spec here :

http://jcp.org/aboutJava/communityprocess/pfd/jsr2 44/

If you're concerned with the web development market (sounds like you are), then C# is superior in many respects, codebehind being #1 in this regard in my opinion. I, however, tend to develop libraries of commonly used primitives early in projects, so after about the first month, everything sort of becomes the same.

And that shows you know crap about Java web development technologies. Probably you're a refugee from ASP or PHP that found the "marvelous world of codebehind" ignoring that only kid developers would actually put logic in the page itself.

And then you cite "libraries of commonly used primitives" !! What!? You mean, implement the class hierarchy representing the business model you previously defined, and how would that be different from any other language?

I just don't want to believe that you do procedural programming on C# because of putting "primitives" instead of "abstrations" on libraries.

Sun Microsystems owns Java, don't trick yourself into thinking that its an open standard just because it's distributed with source.

http://jcp.org/en/home/index

Enjoy.

Now see how other companies have a say in how Java technology evolves while with Microsoft everyone just follows (and get screwed with the next incompatible version). Don't come with that opensource crap, the only vocal people about such thing ARE NOT JAVA DEVELOPERS, Java developers would rather have their arm chopped off THAN HAVE TO SELECT BETWEEN 5182 INCOMPATIBLE FLAVORS OF JAVA, just like we do today with Linux.

So, 5182 different "distributions"? Is that what a conscious developer wants? I don't think so.

Unix was so successful in having hundreds of based versions, that Windows could win and now we use this crap. All I can say about it is F*** OPENSOURCE ZEALOTS, I want a consistent compatible portable Java, and not Joe's Java, Debian GNU/Java, or Mandrake Java.

Anyone is free to implement Java, as a matter of fact, a lot of people already did. See project Apache Harmony, the only thing is that it MUST be 100% compatible with Java in order to be called Java.

Can you find a Java standard anywhere? A JVM standard?

Yes indeedy, do. Mr. PsychicX, I would like to introduce you to the Java Community Process, a full up standards committee encompassing pretty much all the major technology companies in the industry. Java and its extensions all go through this process before being considered final.

Whether you as a developer want to acknowledge the JCP or not is irrelevant. It has been acknowledged by pretty much everyone who does matter, making it a true force in the industry.

Even if you don't like MS, you've gotta admit that from a freedom point of view, .NET beats the crap out of Java.

I admit no such thing. Microsoft has released only the core of the system into the standards committee, and has made no real promise not to enforce patents that would allow them to crush an actual implementation of the .Net system. (As opposed to a "feel good", minimalist implementation that's mostly incompatible with Microsoft's version.)

Under the JCP, ALL APIs in the Java library, ALL bytecode requirements, and ALL Language requirements are published for anyone to implement. The only real power Sun weilds over anyone's head is the ability to deny the use of the "Java" name if they can't live up to the specs.

Sorry dude, but you've been seriously duped.

I think it's pretty damn obvious which runtime system I'm a fan of.

Yes, you're a fan of Microsoft. aka "The Bad Guys". Simply because you fell for a "feel-good" trick of theirs. Nice going.

P.S. Here's the spec for 1.4, the spec for 1.5, and the working group for 1.6. You can join the committee and have your say in the design of 1.6, if you'd like. Now that's a real standard!

Can you find a Java standard anywhere? A JVM standard?

Yes indeedy, do. Mr. PsychicX, I would like to introduce you to the Java Community Process, a full up standards committee encompassing pretty much all the major technology companies in the industry. Java and its extensions all go through this process before being considered final.

Whether you as a developer want to acknowledge the JCP or not is irrelevant. It has been acknowledged by pretty much everyone who does matter, making it a true force in the industry.

Even if you don't like MS, you've gotta admit that from a freedom point of view, .NET beats the crap out of Java.

I admit no such thing. Microsoft has released only the core of the system into the standards committee, and has made no real promise not to enforce patents that would allow them to crush an actual implementation of the .Net system. (As opposed to a "feel good", minimalist implementation that's mostly incompatible with Microsoft's version.)

Under the JCP, ALL APIs in the Java library, ALL bytecode requirements, and ALL Language requirements are published for anyone to implement. The only real power Sun weilds over anyone's head is the ability to deny the use of the "Java" name if they can't live up to the specs.

Sorry dude, but you've been seriously duped.

I think it's pretty damn obvious which runtime system I'm a fan of.

Yes, you're a fan of Microsoft. aka "The Bad Guys". Simply because you fell for a "feel-good" trick of theirs. Nice going.

P.S. Here's the spec for 1.4, the spec for 1.5, and the working group for 1.6. You can join the committee and have your say in the design of 1.6, if you'd like. Now that's a real standard!

Can you find a Java standard anywhere? A JVM standard?

Yes indeedy, do. Mr. PsychicX, I would like to introduce you to the Java Community Process, a full up standards committee encompassing pretty much all the major technology companies in the industry. Java and its extensions all go through this process before being considered final.

Whether you as a developer want to acknowledge the JCP or not is irrelevant. It has been acknowledged by pretty much everyone who does matter, making it a true force in the industry.

Even if you don't like MS, you've gotta admit that from a freedom point of view, .NET beats the crap out of Java.

I admit no such thing. Microsoft has released only the core of the system into the standards committee, and has made no real promise not to enforce patents that would allow them to crush an actual implementation of the .Net system. (As opposed to a "feel good", minimalist implementation that's mostly incompatible with Microsoft's version.)

Under the JCP, ALL APIs in the Java library, ALL bytecode requirements, and ALL Language requirements are published for anyone to implement. The only real power Sun weilds over anyone's head is the ability to deny the use of the "Java" name if they can't live up to the specs.

Sorry dude, but you've been seriously duped.

I think it's pretty damn obvious which runtime system I'm a fan of.

Yes, you're a fan of Microsoft. aka "The Bad Guys". Simply because you fell for a "feel-good" trick of theirs. Nice going.

P.S. Here's the spec for 1.4, the spec for 1.5, and the working group for 1.6. You can join the committee and have your say in the design of 1.6, if you'd like. Now that's a real standard!

Can you find a Java standard anywhere? A JVM standard?

Yes indeedy, do. Mr. PsychicX, I would like to introduce you to the Java Community Process, a full up standards committee encompassing pretty much all the major technology companies in the industry. Java and its extensions all go through this process before being considered final.

Whether you as a developer want to acknowledge the JCP or not is irrelevant. It has been acknowledged by pretty much everyone who does matter, making it a true force in the industry.

Even if you don't like MS, you've gotta admit that from a freedom point of view, .NET beats the crap out of Java.

I admit no such thing. Microsoft has released only the core of the system into the standards committee, and has made no real promise not to enforce patents that would allow them to crush an actual implementation of the .Net system. (As opposed to a "feel good", minimalist implementation that's mostly incompatible with Microsoft's version.)

Under the JCP, ALL APIs in the Java library, ALL bytecode requirements, and ALL Language requirements are published for anyone to implement. The only real power Sun weilds over anyone's head is the ability to deny the use of the "Java" name if they can't live up to the specs.

Sorry dude, but you've been seriously duped.

I think it's pretty damn obvious which runtime system I'm a fan of.

Yes, you're a fan of Microsoft. aka "The Bad Guys". Simply because you fell for a "feel-good" trick of theirs. Nice going.

P.S. Here's the spec for 1.4, the spec for 1.5, and the working group for 1.6. You can join the committee and have your say in the design of 1.6, if you'd like. Now that's a real standard!

The answer to your question is no. Java has clearly borrowed some things from C#, though C# itself heavily borrows from Java. The EJB 3.0 spec for example will make use of dependency injection. Take a look at Groovy which will be integrated into Java (javax.script in 6.0.)

Now it is true that as a more widely used (on the Enterprsie level) language, Java is going to move more slowly than C#. C# is newer and trying to take mindshare from Java, so it must move faster. Just having a great IDE is not enough.

I'm not sure I'd call it a "glacial pace". There are plenty of enhancements being made to Java (the platform and language) beyond convenience enhancments. See JCP.

You're comparing a decent templating engine (Smarty) with crap Java technology (JSPs.) Most modern Java programmers disdain JSPs and use other, better templating technologies. Try using Velocity . Requires no recompiling when you make changes and is a very very easy templating language that provides an amazing amount of power (you literally can drop items into a hashtable of VelocityContexts and then access them by using "$" notation... such as "$user.name") If you want something that will really rock your world, check out JSF or Tapestry (it turns web programming into writing an event-driven application, like desktop apps.)

The problem with most PHP applications is that they don't scale. I don't mean that in a "PHP SUXORS! YOU CAN'T WRITE S$!@ IN IT"... I mean that most PHP applications aren't built with any real caching implementations (like this gallery software, or phpbb, or nuke, etc...) and the PHP frameworks that I looked at don't really provide that functionality.

The stuff availble for Java is just so much more powerful. You have the Hibernate OR mapping package that provides an amazing amount of OR work for you, including the ability to plug in multiple transactional caches, session caches, database connection pools (including the ability to have clustered caches across multiple boxes.) You have complex messaging architectures to talk to and keep multiple machines in sync. You have great web service APIs and great search engines that can be plugged in. Stuff to that degree just doesn't exist for PHP.

It often shocks me to see so many "Enterprise Level" PHP apps released with no caching implementation... you shouldn't see ANY home page hit a database on every hit. (And yes, you can easily avoid stale content by eviction, injection routines.)

So yes, you can definitely write decent stuff in PHP. But for the highly scalable enterprise environment, the libraries and packages that exist for Java and ASP just don't exist.

The other thing I hate about PHP is that there just is no IDE that is of the caliber of Eclipse for PHP (and PHPEclipse just ain't there yet.) A professional IDE allows me to introspect objects, trace stacks, change variables on the fly per hit and control each thread individually. This kind of power makes debugging and performance testing so much easier and more powerful than a PHP app. Good luck trying to seriously profile a PHP app...

So yea, PHP has it's place. It's wonderful for quick one-offs. I just wouldn't want to code a massive user load, transactional, high availability, multiple machine cluster application on it.