That's exaclty what Java needs. MORE bs apis. Eventually we won't have to code anything because Java will already have an api for it and any idiot will be able to code it and have no idea how to make it nice and efficient.

Hell, I once had a college professor tell me "its okay, if Java runs slow, throw more hardware behind it". How's that for the coders we have coming out of colleges these days?

Reminds me of vb. runs slow but damn is it pretty!

Please god, someone tell these ppl about c++

Whenever I see someone say "we need another language" I read as "we need to squeeze more IT money in training, certification and 800-page in-a-nutshell, for-dummies or in-24-hours books and people won't fall for this with languages which already have more books about it than there are self-help books".

I am a Java fanboi. Is it really bloated? Won't the new, marvelous, light, enhanced language suffer the same destiny later? I wouldn't mind having the AWT removed (at least most of it) but it seems a case of fixing what ain't broken.

Before the flame war starts, I was a Pascal fanboi, and a (shudder) Prolog fanboi way back, before Borland stabbed our collective backs.

Ha Ha Ha!!!! ROFL

But seriously, yes, RE: Rafael, I would like to see the AWT removed too but reincarnated as a plug-in library as we still have a lot of stuff out there relying on it.

I like Java as it is. Like ANSI C, its a lean 'small' language that's easy to learn and write.

The exception is generics, which I haven't yet needed or used. IMO features like that belong in a preprocessor, not the language itself.

Yes, I've looked at C++ and recoiled, shuddering. Its a bad case of uncontrolled featureitis and bloat. Many C++ programmers seem to feel the same way: most of the C++ code I've looked at has been vanilla C with added // comments and nary an object in sight. Why didn't they just write ANSI C?

OTOH, I like the thought of a change to the try..catch mechanism. Some halfway house between catching Exception and tediously listing every individual exception would be nice, but does it really need syntactic sugar? Maybe the addition of intermediate exceptions to group related specific exceptions would be a better way to go.

Personally I like the collection of classes in the SDK and its extensions. Packages like Swing, JDBC and JavaMail are what gives the language its power and the ability to write complex programs fast. Maybe the answer would be to break the SDK class collection into a small set of base classes (i.e. the current java.lang classes) and a set of optional larger collections that could be installed or omitted to suit the user and the programming task: If you're mainly writing realtime command line code you mightn't need XML, a GUI or JDBC but a set of ASN.1 classes and their supporting packages might be useful.

Microsoft know about compatibilty, it was their bread and butter for a long time.

Old Joel posting illuminates: http://www.joelonsoftware.com/articles/APIWar.html

On Vista, MS removed the old help system. But users can download from the windows site (except I doubt that it's tested any more).

Basically, users can get it to work - but most users will not understand or be bothered to download the "legacy help system". And by presenting it in this manner, ISVs are forced to spend money porting their help system to the vista one (meaning that they have to maintain two - one for XP and one for vista).

Java like vista and any other have an economy built on top, any removal of a public API is going to ripple problems through the ecosystem causing end users to pay more in the end. Those banks that might have built everything on top of AWT will pass the rewrite charges onto their customers eventually.

A platform is for life not just for mishmash.

Pile it on the more the better people who talk about small languages aren't using them for very much. If you think the people who make the api aren't writing efficient code you should be using a different language, anyway no one is forcing you to use them. Everything under the sun and then some, otherwise you might as well put a bullet to it's head.

I figure Java is already super bloated, so fattening it up won't really hurt anyone. I'd really rather have people use Python or Scheme all the time.

Or Java could strip out all of their crap and leave a sleek, fast, almost new language that breaks all backwards compatibility. Call it Java X or something.

While I'd agree that there is a degree of bloat in Java, and that there's a whole swath of APIs I've never personally used, if any particular API is removed, it'll always impact someone.

AWT being an example. We recently had a project which involved embedding ActiveX controls in a Swing app (don't ask). As Swing popup menus are lightweight, the AX controls trampled all over them. Our solution was to use the heavyweight AWT popup menus.

So by all means remove AWT or others from the core API, but they must remain available as plugins to ensure legacy code continues to work, preferably transparently (eg some sort of Maven like dependency downloads)

The first poster's comment says more about the professor than Java. I'm a java developer in the real-world and we do care about performance here.

I like the dynamic languages like Python and Ruby too, but I don't see them being able to replace Java in the enterprise area. For one, many companies have a huge investment in Java already.

A bloated language is something like PL/I, which had *built-in* types for just about everything and (according to Bill Plauger, I dont' know, I wasn't around then) abandoned imperial units only after the British Empire did. This whole approach to language design was rendered unnecessary with the arrival of object oriented languages about a quarter of a century ago.

A language spec may be bloated, even though the language is fairly simple, if there are a lot of awkward edge cases. Name lookup in C++ is the best current example. Hardly anyone has serious problems with it in practice, but it was a real bugger to specify. (Those two facts may be connected.)

A bloated library surely falls into the category of "what you don't use, you don't pay for". (If that's not true for your preferred language, then I'm afraid there's no hope for it. It is terminally broken by design.)

A library spec may be bloated if one insists that almost every library that has ever been useful must be shipped with any "standards compliant" implementation. Most languages don't do that, although Microsoft's .NET family seem to have committed to the entire Windows API being "part of the bundle". A self-inflicted injury, in my view.

Java strikes me as a relatively small language with a gimungous library. It wouldn't be hard to "lose" parts of the latter from the mainstream, as long as they remained available for legacy code, so why is this even controversial?