Preview of Java 1.5

gafter writes "An early access prototype implementation of the proposed new J2SE 1.5 language features is available. The prototype includes generics (JSR 14), typesafe enums, varargs, autoboxing, foreach loops, and static import (JSR 201). In other words, all the new language features planned for 1.5 except metadata (JSR 175). The prototype includes full sources for the compiler, written in the extended language. You can download the prototype from java.sun.com. It requires J2SE 1.4.1 and provides some examples of how to use the new language constructs. The prototype includes an experimental type system (variant type parameters) for Generic Java that is being considered for Tiger (1.5) based on a paper by Igarashi and Viroli at ECOOP 2002 . Comments and votes for the new type system are being gathered at bugParade."

Comments

good and bad ...?

[bubzer]

Some of these things are certainly nice (typesafe enums...) - but wouldn't it be nice to try and keep the java language *simple*? There are iterators for doing stuff like foreach-looping ... varargs? Why? It is an object-oriented language - take use of that polymorphism!

Re:good and bad ...?

[IO ERROR]

varargs? Why?

Because no language is complete without printf.

Anyway, I'm glad to see Java finally getting generics. This will make it a little easier to manage very large projects in Java. The only problem I see is that generic java usually sucks compared to the brand-name stuff (e.g. Lavazza).

Re:good and bad ...?

[bramez]

but wouldn't it be nice to try and keep the java language *simple*?

isn't syntactic sugaring all about making code more readable? I think boxing , generics, typesafe enums, static imports make the java language more simple to use.

It's just looking over the fence to the "sibling" languages (c++, c#) and copy what they do better.

Re:good and bad ...?

[Anonymous Coward]

There certainly is a tradeoff: If a language gives too many options to do one thing, it becomes confusing. A programmer usually develops a certain coding style. She prefers certain constructs over others. When you read code, you have to adjust to the style of the programmer who wrote the code, and possibly recognize constructs which you're unfamiliar with because they're not part of your coding style. Take the proposed for-loop extension as an example. Every Java programmer instantly recognizes the head of an "iterator for-loop". It's an idiom. The proposal adds syntactical sugar to supposedly help identifying this very frequently encountered situation, but it does the exact opposite: There are now two ways of looping over an iterator, and you have to be familiar with both if you want to quickly understand other people's code. If you want a good real-world example of what too much syntactical sugar does to a language, take a look at some Perl programs.

Re:good and bad ...?

[Daleks]

Some of these things are certainly nice (typesafe enums...) - but wouldn't it be nice to try and keep the java language *simple*?

Type-safe enums were added to eliminate previously verbose and obfuscated code. It simplifies the code without complicating the language.

There are iterators for doing stuff like foreach-looping ... varargs? Why? It is an object-oriented language - take use of that polymorphism!

What does polymorphism have to do with an enhanced the for-loop or variable arity functions? The enhanced for-loop ensures that collections are properly iterated across (no out of bounds exceptions). You honestly think that

for (int i = 0; i < C.length; ++i) {/* ... */}

is more complex than

for (int i : C) {/* ... */}?

Also look at what you can do with variable arity functions. Say you have a constructor for a collection class and you want to be able to initialize a variable number of default values. Well, now you can. Apple's Cocoa (Foundation) library uses this to allow easy construction of NSDictionary objects.


id d = [NSDictionary dictionaryWithObjectsAndKeys:@"foo", @"bar", @"biz, @"baz"];


The other way to do it would have been


id d = [[NSMutableDictionary alloc] init];
[d setObject:@"foo" forKey:@"bar"];
[d setObject:@"biz" forKey:@"baz"];


Aside from Cocoa's long parameter naming scheme, the first method is a shorter and a lot easier. It also uses fewer messages.

Re:good and bad ...?

[Dan-DAFC]

I agree. Enumerated types are something Java has been lacking for too long, so these type-safe enums will be welcome (though Joshua Bloch, the specification lead on JSR 201, has a nice alternative in his excellent Effective Java book).

I really don't care much about the rest. I'll give the generics and the autoboxing a go, but I don't really like the new for loop syntax. Firstly I think it's ugly, they've compromised to avoid adding a new keyword (I don't really know why, they were happy to add new keywords in 1.2 and 1.4) and it also means that for the first time we get built-in language support for classes outside of the java.lang package, which strikes me as a bit strange.

What would be nice from a purely aesthetic point of view (it'll never happen because of backwards compatibility) is if we could have a Java 2.0 (which would be confusing in it's self since 1.2 was "Java 2") that cleaned up the messy parts of the core libraries. Move the collections framework out of the java.util package either into the java.lang package (since we know have built-in language support for it) or into it's own package, remove all the of the methods/classes that were deprecated in or before 1.2 (developers have had enough notice to stop using them and legacy code is likely to continue running on old runtimes), fix naming inconsistencies (System.arraycopy should be System.arrayCopy for one, and do you call size(), getSize() or length() to find the size of something?).

As somebody pointed out below, varargs are not mentioned in JSR 201, they won't be in 1.5. I can see from my limited experience with C++ that they can be quite powerful but I'm not keen on them. They can turn compile-time errors into runtime errors and it would make method overloading more complicated.

Re:good and bad ...?

[cookd]

Iterators should not be used to replace the counting case:

for(i = 0; i < count; i++) { ... }

You can use iterators for this, but (depending on the implementation) it is likely to be slower, since the object in question must create an iterator instance.

Iterators should be used (in fact, are pretty much a necessity) on types that are not easily indexed, such as hash tables or linked lists. As long as the Java language doesn't have support for iterators, developers creating non-indexable container classes have to design and implement some kind of iterator themselves. With language support, the language enforces a particular design (making programs more consistent) and provides help with the implementation.

Yes, it is sugar, but it is useful sugar.

Varargs are also sugar. You could always just make the user create an array of objects as the variable parameters. But that takes a few extra lines of code for each call, and confuses the purpose of the code. You have to deal with the distraction of constructing an array instead of dealing directly with your problem.

Varargs makes a few tasks just a little bit simpler. It doesn't add any functionality, but it adds convenience.

CallStoredProcedure(db, "MyStoredProcedure", param1, param2);

Isn't that nice and simple? Syntactic sugar, when used appropriately, should simplify life for the programmer. In my opinion, "sugar" is appropriate if it provides a clean way to do something that would have been messy before. It should be avoided if it provides two equally good ways to do something. In the case of varargs, I think both criteria are met. In the case of iterators, the first is met, and the second is met as well as long as developers understand when iterators are appropriate and when they are not.

Re:good and bad ...?

[linux_student]

Too late! I just started to learn java about 5 months ago in school; whatever chance they had to make that language "easy"(a subjective matter of course) went out the window long ago. Nonetheless I am still learning and Java remains one of my favorite languages to date.

Re:good and bad ...?

[__past__]

You honestly think that
for (int i = 0; i < C.length; ++i) {/* ... */}
is more complex than
for (int i : C) {/* ... */}?

In a way, yes. The first uses the (little) possibilities the core language offers. The second uses a language feature that depends on a specific part of the class library.

So, even if the resulting code itself is easier to read, if conflates two layers of the language that should better be cleanly separated, IMNSHO. It basically boils down to the fact that you cannot change the class library anymore without possibly breaking the core language.

Re:good and bad ...?

[Arslan ibn Da'ud]

There are now two ways of looping over an iterator, and you have to be familiar with both if you want to quickly understand other people's code. If you want a good real-world example of what too much syntactical sugar does to a language, take a look at some Perl programs.

Ah, but Java's two for-iterator loops are slightly different. The 'foreach' IIRC provides you with a single variale that points to successive items in your collection...it does not provide you an iterator. This means you can traverse the items in the collection but you can't filter them or change the collection itself.

The old 'for' syntax is still necessary if you want to actually change the collection, eg to filter out objects from the collection, or to insert objects in specific places. The old syntax is more error-prone (since Iterator.next() is usually called in the body of your for loop, are you sure its being called *every* time???)

So both for syntaxes have inherent advantages and disadvantages. So they're both worthwhile to have around.

Re:good and bad ...?

[GrayArea]

Built-in support for iteration does not depend on packages other than java.lang, they specifically mention this in the documentation. There is a new Iterable interface in java.lang that the collections implement, so you can make your own classes participate in the same mechanism if you want.

Cleaning up the core libraries should never mean rearranging them according to some fleeting sense of pure aesthetics. Even a cleaned-up Java has to provide some amount of backward compatibility for existing code. Changing the collections' package just doesn't make anyone's job easier.

No subject.

[Daleks]

! But, . And finally, .

Just had to get that trolling out of the way. Now let the educated and well-formulated arguments begin.

Re:No subject.

[Kethinov]

As a "weenie who can't handle pointers" I take Java's slowness very seriously. I wish that a better method could be used to process Java programs because I believe that future high level programming languages are going to be modeled around Java. PHP certainly is being modeled around Java. Am I the only one here who'd like to some day be rendering serious 3d graphics through Java? I think the language has potential and I don't just shrug off its slowness as an inherent property, I want it to improve in that respect too.

Re:No subject.

[Mithrandir]

Am I the only one here who'd like to some day be rendering serious 3d graphics through Java?

No, but I've been doing it for years. Don't know which closet you've been hiding in, but there are heaps of alternatives for doing 3D graphics in java. Java3D, GL4Java, LWJGL and more. In fact, our (open source) toolkits use all of these and we have hundreds of users running on everything from PDAs up to CAVEs all done in Java. We've just released code to handle Elumens Domes/VisionStations too, which, again, is in Java (although that one required a small amount of native code to slap Java3D into gear to do it).

Take a look at Xj3D for more information.

Re:No subject.

[DickBreath]

Of course you can handle pointers!! I'm tired of running into Java programmers who are scared of lower level code (read: C).

I'm tired of running into C programmers who are scared of lower level code (read: Assembly).

I'm tired of running into GUI users who are scared to use the command line.

I'm tired of running into calculator users who are scared of using a slide rule.

I'm tired of running into automatic transmission drivers who are scared of manual transmisions.

I'm tired of running into people who use drive automobiles and are afraid to use a horse and buggy.

In fact, I don't think scared is the issue here at all. The real issue is automation. Something that always makes people more productive, and requires greater machine resources. (See all above examples.) In fact, using your own argument against you, I would argue that anyone here, even a Basic programmer, can learn to program Assembly, use a command line, use a slide rule, etc. In fact many of us were Basic programmers. Many of us do or did these other skills. That fact that you can be "macho" and learn pointers is missing the real issue. Automation.

In Java, you are trading machine performance for human performance. You simply eliminate the possibility of even having the all of the most common C/C++ bugs that plague so much modern software.

CPU cost is going down. People cost is going up. This trend has been going on for a long time. (Have you noticed this trend in the past 20 years?)

Back in the early 60's and 70's there were huge debates about whether "high level" languages (like the C you advocate) would ever be useful because the compiled code was so much less efficient than hand written code. (And yes, I know that argument in the late 70's that compilers would eventually write better code than by hand.) But the point remains, that even if this is or is not true, high level languages won.

Think about why that is for a moment.

In any sufficiently complex C/C++ system, you either end up implementing garbage collection, or end up with some complex disciplined memory management strategy, and still end up with object lifecycle bugs. In C/C++ you sometimes end up implementing your own miniature Lisp, even if you've never seen Lisp. But your own implementation of Lisp ends up poorly specified, and not throughly debugged.

Sounds like what C# has that makes it better...

[Anonymous Coward]

Surprisingly (!!!) all the things C# had (or will have - generics) that made it superior. This is going to be fun seeing these two compete. So far I am on the C# side but who knows :) this is really fun.

Too litttle, too late.

[mrright]

For years java zealots have told us that features like automatic boxing and templates are dangerous because they hide what really happens.

Now that java has them too, they are suddenly the biggest thing since sliced bread. Most modern languages have had automatic boxing for ages, and never made a big deal about it.

And about the new templates: they are just syntactic sugar. For example if you have an ArrayList, the elements will still be stored on the heap as Integer objects. That is very inefficient.

And what about VM sharing? Will it be in java 1.5, or will we still have to wait 30 seconds for java programs to start up?

Re:Too litttle, too late.

[Anonymous Coward]

And what about VM sharing? Will it be in java 1.5, or will we still have to wait 30 seconds for java programs to start up?

mod up. this is major pita that makes java almost unusable for small&trivial stuff. (ironically - the stuff it was designed for)

Re:Too litttle, too late.

[Dan-DAFC]

It's correct to say that the start-up time for JVMs is a concern (more so than actual Java execution speed) but fortunately things are getting better in this respect. Java 1.4.2 (which is in beta at the moment) has made some significant improvements in this area.

Re:Too litttle, too late.

[Call Me Black Cloud]

I believe one of the things Sun tried to get at was to make Java development easier. It's something they're working on across the board, as this article notes.

Without seeing (in the Java source code) how the templates are implemented I can't say that I agree or disagree with your statement that they will be inefficient, though I'm inclined to disagree based on your example. Templates or not, objects are going to be stored the same way. The difference is how those objects are retrieved. Right now you have to cast everything coming out of an ArrayList (unless the Object reference is sufficient)...not only is that being moved to the language but you also gain compile-time type checking. That will only serve to reduce errors and make the software more reliable. Templates are optional anyway - you don't have to use them. I'm looking forward to them.

I don't think you're ever going to see VM sharing. If applications can share VMs then one rogue app could bring down other apps by trashing the VM (never supposed to happen) or by poor thread management.

Either way you look at it, it's a good year to finally be going to JavaOne...

Re:Too litttle, too late.

[mrright]

"Without seeing (in the Java source code) how the templates are implemented I can't say that I agree or disagree with your statement that they will be inefficient, though I'm inclined to disagree based on your example."

Slashcode swallowed some brackets even though I was in text mode :-(

What I mean is the following: If you create for example an ArrayList of ints, the most efficient way to store these ints internally would obviously be an int[] and not an Object[]. But even though java uses templates, it still stores primitive types such as int in an Object[], so there is a huge temporary object creation overhead. Whenever you store an int in your IntArrayList, a new Integer object is created on the heap and an old Integer object has to be garbage collected. In .NET you just store a 32bit value in an array, which is a single operation on most processors.

The .NET templates will create a different class for each primitive type, so that primitive types will indeed be stored in their corresponding primitive arrays without creating objects on the heap. For classes, the .NET implementation behaves similar to the java implementation: There is only one internal class created for all reference types.

"Templates or not, objects are going to be stored the same way. The difference is how those objects are retrieved. Right now you have to cast everything coming out of an ArrayList (unless the Object reference is sufficient)...not only is that being moved to the language but you also gain compile-time type checking. That will only serve to reduce errors and make the software more reliable. Templates are optional anyway - you don't have to use them. I'm looking forward to them."

Me too. It is not that I dislike the new features. I just think that they could have been implemented better, faster and earlier.

"I don't think you're ever going to see VM sharing. If applications can share VMs then one rogue app could bring down other apps by trashing the VM (never supposed to happen) or by poor thread management."

VM sharing does not mean that all java programs must run in one process. But for most desktop applications this would make a lot of sense. You are right about the thread management, but you could always restrict the number of threads an application can create. Just have a nice XML file which describes how much resources each application may allocate. That is the way .NET does it, by the way.

If sun will not do VM sharing, you will never see decent client applications written in java. Just think about it: for each java application you start, the whole swing library has to be JIT-Compiled anew. What a huge waste of processing power!

Re:Too litttle, too late.

[tcopeland]

And don't forget Java Web Start apps, like this (Tetris) and this (GForge client).

Java Web Start is great stuff - always downloads the latest version, easy to deploy... don't know why more folks aren't using it...

Tom

Re:Too litttle, too late.

[Baki]

Generally, I'm sceptic towards syntactic sugar (such as operator overloading, or even overloading in general). However, if you call generics syntactic sugar, you don't know what they are or what you are taling about.

Sure, its implementation may be in terms of what already exists (i.e. internally you still have Lists of Objects, being cast into Integers or whatever). However, the burden of typecasting is removed from the programmer into the compiler, which is very significant and not syntactic sugar at all!

C++ in its first incarnations was also just a precompiler to C, so following your reasoning one might have called C++ just syntactic sugar. Or even a compiler as mere syntactic sugar w.r.t. assembly, since in the end it is machine code that runs in both cases.

No, getting rid of typecasts, a source of many errors and mistakes, is a big step towards a more safe and better readable language.

As far as the remaining lack of stack variables: I agree it would be nice to have them. However I consider this an implementation/optimization detail. It should be up to the compiler to decide whether to use stack or heap for a particular case (though I'm not sure if current compilers can make the best decision). Kind of like the 'register' keyword in C, that hinted the compiler to store an important variable in a register. Due to progress in compiler technology it has become totally redundant and even harmful.

Simplicity lost

[abies]

While, as a java developer, I'm looking forward to most of these changes, I'm a bit afraid that java may lose it's positions as simple OO language which can be used for teaching in schools. Java was originally built with idea that you can read every java program in the world without problems. A lot of expresive power was sacrificed because of that - most notable preprocessor (to avoid people designing their own 'languages' for each project and library, as it is done in C).
Anonymous inner classes was first major ugliness which came into language - not very clear, hard to explain to a newcomer. But with all these new proposals, significant complexity is added to code in terms of visual overview. This is not critical for developers - perl hackers are faring very well, despite of having language 10 times as complicated as java as far as syntax is concerned - but pure-OO, java-is-new-pascal-for-algorithms academic society will probably start looking for a new language soon... (ok, maybe not really 'academic', I'm thinking more about secondary-level school programming basics).

Re:Simplicity lost

[girl_geek_antinomy]

It's interesting that you say that about teaching, and I think you have a point. I'm a CS student at Cambridge University (currently avoiding finals revision) where Java is the fundamental teaching programming language, the one they teach you right up front, the examples language for code fragments in algorithms situations (well, along with ML) etc.

Actually though I think for this kind of teaching you can just use the simple subset of Java that's been about since 1.1 - after all, you're teaching principles of programming and OO - you can teach actual Java *development* down the line and cover the complexities, bells, whistles and dongles then...

Re:Simplicity lost

[jonathan_ingram]

Next term try teaching them Python instead.

Then, when they understand the concepts, you can introduce them to the syntactic nightmare that is Java.

Re:Simplicity lost

[the eric conspiracy]

Any language that uses whitespace syntactically is TOTALLY unsuited for teaching.

Re:Simplicity lost

[the eric conspiracy]

Java has several interactive interpreters. One such is DynamicJava.

Plus some very powerful debugging tools TOTALLY missing from Python that are very important for teaching programming.

As someone who has taught programming at a university level, and is also a practicing programmer I find the broken syntactical structure of Python completely disqualifies it as a teaching language. The use of non printing characters as syntax elements is ridiculous on the face of it.

Interested in learning more about these generics

[smittyoneeach]

You could troll and say that Java has finally caught up with where C++ was better than a decade ago.
More constructively, maybe the implementation will improve on things from all that time and experience.
Java is the best defense against the .Net onslaught. Good luck, Java.

Re:I'll care when native compilers become the norm

[73939133]

Java can walk on water and I'm still not going to use it to develop anything I expect anyone to use. Give me a native optimizing compiler and I just might reconsider.

You mean like GNU gcj?

For languages that are intended for general purpose use and especially for situations where performance/efficiency is important they're just a BAD idea.

You seem to think that by compiling stuff to native code things magically run fast when the problems are actually library design, class loader design, bad memory management, and other issues. Java's JIT is about as fast as natively compiled C code and Java's lousy performance is living proof for the fact that making a great native code compiler is not sufficient for getting good performance.

Python and Perl programs often run rings around equivalent Java programs in terms of actual, end-user visible performance and memory usage, despite being interpreted. If anything, the compromises people need to make to make languages easily compilable into native code make it much harder to build efficient systems in them.

Of course, it's not like we needed any more proof of that: the inefficiency and bloat of systems like Windows, Gnome, and KDE demonstrate the same point, as did several generations of systems before them. And generation after generation of programmers repeats the same mistake you are making.

Re:I'll care when native compilers become the norm

[afidel]

Native compilers have been available forever but they rarely gain you enough over JIT to justify the lack of crossplatform portability. If you are running a J2EE app as middleware for a huge ecomerce or CRM system, etc then sure recompile to native code, but for other things it doesn't make sense when the JIT compilers are 99% effective. The biggest thing slowing JAVA down is the lack of a decent GUI framework.

Re:I'll care when native compilers become the norm

[abies]

I'm surprised to see that there are still people out there which use 'interpreter' argument...

Anyway, there is a plenty of native compilers for java. I'm not sure if you have heard about certain compiler from free software group called Antilope or something like this - I think it is called gcc. They have a frontend for java, gcj, which compiles java source/bytecode to same intermediate stage as other compilers, thus sharing optimizing backed. If you don't care about paying few bucks, JET is very good compiler, written specifically for java, supporting 1.4.1. There is also few others, but I can tell only about these two from my experience.

Both these compilers are available for few years now. Problem is not with lack of native compilers, or performance of java in mixed mode offerred by Sun hotspot - problem is with mindset of poster. If you are not willing to use java - no problem. But please say it is 'religious' - everybody will agree with you, as you can have any beliefs you want. But do not try to back up religious statements with fake arguments.

Generic Java

[Darkforge]

If you, like me, didn't know much about generics, the best place to go to read up more is the specification off of which JSR 14 was based: GJ: Generic Java. Don't bother with the FAQ though... it seems to be mostly empty.

(Excuse my whoring, but Sun's link to GJ was 404.)

Re:Sounds like what C# has that makes it better...

[Jugalator]

Yes, I noticed this as well. I found it pretty interesting, and it reminded me of the old IE/Netscape browser wars. One implements the new features of the other. Let's just hope they don't get too carried away and bloat the language. :-/

To me, Java was a lanaguage with a minimum of "redundant" features. You can write a "for" loop without using "foreach". You can use a class instead of a struct. And so on... I'm actually a bit surprised that Sun are throwing in features the language doesn't really always seem to need. I thought that was C#'s area. :-)

Re:Finally...

[Daleks]

The only complaint I have is the new format for the for loop... for (int x : b) isnt really easy to read. foreach x in b or something like that, while a little more verbose would be a cleaner

Introducing new keywords may break old programs if they have a variable with a name identical to that of one of the new keywords. Using the colon sidesteps this.

Mod parent funny!

[simonecaldana]

Click on the link!

Java is passe

[73939133]

I've pretty much stopped using Java. Sun has broken their promises when it comes to making Java an open standard (and, in fact, they have several patents on core Java technologies). And technically, even with these additions, Java 1.5 is still behind C# in several important areas (native code/data interfaces, genericity, support for numerical computations).

Also, after trying to live with it for years, I have concluded that "100% pure Java" just doesn't meet my needs. "99% pure" is good enough for me: it means that porting is easy, but the last 1% of platform specific code is what makes the difference between applications that merely run and applications that integrate well with each platform.

I expect Java will continue to survive in some niches (most notably, bloated web services implementations), but Sun has largely missed the boat when it comes to creating a general-purpose programming language: it's too little too late technically, and they have annoyed too many people. I think C#, .NET, and Mono have a chance if Microsoft doesn't shoot themselves in the foot with stupid legal threats against open source projects. Otherwise, there are plenty of other languages; the choice isn't just between Java and C#, you know.

Re:Java is passe

[waaah]

If you don't know anything about it SHUT UP!

Java:
-Java as a language is not a standard but doesn't change much at ALL.
-Every API is developped through the Java Community Process .NET:
-C# + CLR is standardized (yes only a language and a VM)
-Other API's are NOT standardized and are in full control of Microsoft

I think that mono will have some major problems in the future. Sure they can implement C# and CLR, but they virtually have to reengineer all other API's, because there are no formal specs available.

Re:Java is passe

[73939133]

Other API's are NOT standardized and are in full control of Microsoft [...] I think that mono will have some major problems in the future. Sure they can implement C# and CLR, but they virtually have to reengineer all other API's, because there are no formal specs available.

How is that different from C++ and the Win32 APIs? The fact that Microsoft controls the Win32 APIs doesn't matter to me when programming in C++--I just write my code in Gtk+ or wxWindows. Likewise, the fact that Microsoft controls the .NET APIs doesn't matter to me when programming in C#--I can just use Gtk#.

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#.

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.

Re:Java is passe

[haxor.dk]

But what should I choose if I want and open, platformindependent programming language?

Generics

[The Bungi]

There's an apropos article over at kuro5hin. Well written, I think.

It seems to me that languages like Java and C# really don't need them.

Re:Generics

[be-fan]

One thing I never understand about anti-C++ rants. Where's the beef? All I see is a whole bunch of hand waving and vague references to pseudo object orientation, incoherency, etc. No real meat at all. So from my point of view, some real evidence:

1) C++ is a systems programming language. The lack of pointers would make it entirely unsuitable for that purpose. For normal use, you should use references or smart pointers. Not doing so is no excuse. Using a C-style array when you don't need it is akin to deliberately writing an infinite loop. It's entirely the programmer's fault.

2) The object model doesn't lack anything that Java's model has, except introspection (which is fragile at best). If anything, Java's model is equally broken, because everything is not an object. What exactly about the object model is missing?

3) What's wrong with the C++ syntax? How is it that different from Java's syntax?

From my POV, peoples' biggest problem with C++ is that it doesn't prevent you from hurting yourself. That's okay. I hate all the consumer protection bullshit, and Nader and his "don't run with scissors" party, so I have no problem with my language having some teeth. I do a lot of low level programming, and I find that C++, more than any other language, allows one to do that will still maintaining a high level of abstraction.

Is the single instance of VM in?

[Kjella]

...because there's nothing like running a 2kb calculator and a 2kb notepad and both have them run on separate 10-15mb VMs. That is a real drag for any non-monolithic use of Java (yes I do know of servlets etc.)

Kjella

Re:Is the single instance of VM in?

[Montreal]

No.
Sun are apparently looking at the work that Apple did to provide this functionality with the Apple implementation of 1.4, but it's not likely to be in 1.5 (see this chat transcript for the official line. Maybe 1.6 for non-Apple VMs?

varargs - shmarargs

[BranchingLichen]

JSR 201 says nothing about "varargs".

Good ol days

[ausgnome]

Oh for the good ol days when pascal was the teaching language

Re:Good ol days

[LordMazza]

Try Component Pascal. You can get a compiler here which will compile to either the .NET platform or to Java byte code, so you still have access to all that underlying modern stuff if you really want it. :)

Re:Sounds Promising

[tallniel]

"... The fact that I don't have to do this:
JPanel jp = new JPanel();
JComponent jc = ((JComponent)jp);
or Node xmlNode = (Node)xmlElement;
sounds quite good."

I think I get what you are trying to say, but the examples are bad. The first one doesn't require a cast now, as you are casting from a subclass to a superclass:

JPanel jp = new JPanel();
JComponent jc = jp;

works just fine (just tested in 1.4.1). I imagine the same applies to the second one too. Also, if this wasn't the case generics wouldn't help in this code. Generics only remove the need to cast when extracting an object from a container, if I understand things correctly.

Re:I'll care when native compilers become the norm

[spongman]

Give me a native optimizing compiler and I just might reconsider.

hotspot is a native optimizing (JIT) compiler. It takes Java bytecode as its input and generates optimized native code. Try disassembling some of the code it generates some time, it does a remarkably good job.

Dylan

[oodl]

Sounds like they are adding a lot of features that the Dylan programming language has had since it's release (approximately 1995).

But whereas the features were elegantly incorporated into Dylan since the beginning and are consistent and easy to use, I suspect that in Java they are a hack.

Wasn't Java designed to be a simple language?

Re:I'll care when native compilers become the norm

[mlk]

GCJ?
And as the 1.5 compiles to compatable byte code, can automaticly use the new 1.5 features (with the exeception of new classes.

Teach the kids Scheme or Smalltalk.

[BitwizeGHC]

Those two languages are far simpler, and let you really hammer the points about programming down without getting the kids confused about syntax rules.

Smalltalk has, essentially, only one operation: the message send. Send object X a message Y, and get Z back as a result. Even simple things like addition are implemented this way. While not blazingly fast (except in certain specialized implementations), the message-send semantic is surprisingly efficient: many complex real-world systems have been constructed using Smalltalk.

Scheme also enjoys the advantage of being small and simple, yet powerful. You don't need to know what the lambda calculus is to see how effective and intuitive Scheme's procedural semantics is. ("Lather, rinse, repeat." See? Tail recursion. It was there all along.)

Either way, it's better to use a simple language to teach students how to formulate plans for doing things (i.e., algorithms), and then hit them with fanciful syntax later rather than drop them into a popular, but bewildering for newcomers, language (which I consider C++ and Java to be).

The problem: Improving programmer productivity

[BjornStabell]

These additions seems to put Java on par with C#, but to make a quantum leap in expressiveness you need a dynamically typed scripting language.

Most applications these days can be written in higher-level languages, resulting in 5-10 times less source code compared to Java/C#, and making them correspondingly simpler to code and maintain.

Java doesn't really have a kick-ass companion scripting language. In MS world, VB plays this role. VB is really popular, but (I think most people would agree) a crap language and not really that high level. JavaScript just doesn't seem to cut it (pretty much only used in browsers).

Why doesn't Sun take a hint and phase JavaScript out in favor of a powerful multi-purpose high-level language like Python or Ruby? That'll put them miles ahead of Microsoft in terms of increasing programmers' productivity... and programmers' quality of life.

Re:The problem: Improving programmer productivity

[Billly Gates]

" Most applications these days can be written in higher-level languages, resulting in 5-10 times less source code compared to Java/C#, and making them correspondingly simpler to code and maintain."

Look here for more info. My guess is Sun is brewing something with the next edition of SunONE and Forte. Notice how Sun is targetting there new tool at VB users.

Its possible these features were added to java 1.5 so Forte can have a VB like ide to generate java code easier. After all, enums make things easier to read and are essential for new programmers to read your code.

Competition is great and I believe a great RAD and ide that is based on a fairly good langauge will give .net some tough competition. Its this ability that has attracted alot of attention towards .net.

Re:The problem: Improving programmer productivity

[MSTCrow5429]

JavaScript has nothing to do with Java, other than their similiar names. JavaScript, originally LiveScript, "was renamed by Netscape marketers who licenced the name to ride Java's Buzz" (Wired, July 2002, pg. 61). Javascript is actually an offshoot that sprung from both C++ and ANSI C (C89). JScript and ECMA Script sprung from Javascript.

Re:The problem: Improving programmer productivity

[Golthar]

Actualy, try looking at Jython

Sure, for small programs its not perfect (as you'd have to still run the VM), but this way you can integrate Java applications and use Python to script these applications.

Re:The problem: Improving programmer productivity

[DdJ]

Java doesn't really have a kick-ass companion scripting language.

Have you looked at BeanShell? I haven't started using it yet, but it looks like it has the potential to really empower scripting.

Re:The problem: Improving programmer productivity

[bellings]

JavaScript is a scripting language. Microsoft's .NET framework includes bindings to one low level languages (C#), one mid level language (VisualBasic), and one scripting language (JavaScript). If you pick up Visual Studio, you get bindings for J# and C++, too. Plus, lots of people are looking forward to F#, a functional language.

The point is that Sun really hasn't endorsed any alternative bindings to the Java platform. They certainly haven't endorsed any dynamically typed "scripting" languages similar to VisualBasic or JavaScript.

Obviously, JavaScript is available for the Java Virtual Machine, as are a huge number of other languages. However, Sun has never really embraced those alternative languages. That's a real shame.

And that's why the parent of the parent poster included Java, C#, and JavaScript in the same post.

Re:I'll care when native compilers become the norm

[KingRamsis]

no!
because the JIT overhead is not re-occuring, it happens once.

Re:I doubt that Java will succeed.

[Billly Gates]

Go do a job search on monster.com and count the java vs C++ programming?

Java is growing. Its not horribly complicated and buggy like MFC and the win32api and your not locked in with .net.

Corporations use Java for servlets and they use if for the built in libraries, low cost and portability.

Java is a great language and I am sick and tired of legalists complaining about it. First the LISP academics complained about Unix or anything non lisp. THe unix haters manual was a result of this. It went nowhere. Now we have smalltalk and Eifel purest who claim that everything else is inferior.

Your little world may be great in University teachings but in the real world they lack functionality and libraries to accomplish real world bussiness tasks.

Mono is very alpha and lacks many of the winform libraries that are mature on Windows. If you use it your asking for vendor lockin eventually which is Microsoft's goals. Look at the hasle SCO has made in the corporate world in regards to Linux? If Microsoft begins taking a similiar approach and everyone uses Mono then they are SOL. Its all Windows lockin. The microsoft version will always be better and more supported so your PHB's have a great argument to switch to Windows.

I chose to live in the real world and use what everyone else is using and that is java.

Re:Mini Ask Slashdot

[j-b0y]

Don't know about JBoss, but Tomcat is a breeze; untar and start it up; you can start drop in webapps straight away.

Now, if you're talking about a secure, robust Tomcat installation, using apache httpd to serve static content, well, that's another matter.

Tomcat is for one of the examples of the success of Java code married to the Open Source model; Sun likes Tomcat becuase they farm out RI work for the Servlet and JSP specs, leaving engineers to concentrate on, well, coming up with more convoluted specs. Sun and its ISVs neither can or want to make any money on a pure Servlet container + JSP implementation.

J2EE, on the other hand; well, Sun hates JBoss, as it is eating to ISV revenue and Sun can't create a monoculture around Java (as Microsoft has very successfully with Win32) if someone is going to give implementations away for free

Sun deserves all that will happen

[Fuzuli]

Ok, let's all try to see how Sun can be incredibly stupid.
You have a company that has a strong position in the Enterprise, and you have a technology that is pretty much accepted. Meanwhile your opponent is busy with conquering the desktop since it can't provide solutions strong and stable enough for the enterprise. What in god's name did you think MS was going to do? Was Bill Gates supposed to turn the others in the room and say "hey this was fun, let's do it again!" after MS has owned the complete desktop ? OF COURSE they'll try to dominate the Enterprise too!! .NET was announced almost 3-3.5 years ago. Sun saw it coming and did nothing. Bitching about how MS products sucks is not the solution. You should have used your advantage and experience in the Enterprise instead of letting MS slowly steal it from you. If Sun could have cared for what the industry has been complaning about in their technology, and implemented the necessary changes, by the time .NET is out, it would be just a ripoff. But look what we have here now: Sun, is trying to catch up with MS in the field where it had for years. You have a huge user base, you have a mature technology, why do you wait for opponents to catch up ? Java is not dead yet, but it's not hard to see why it'll be dead at the end, when you look at what Sun is doing..

Re:I'll care when native compilers become the norm

[sperling]

Java isn't an interpreted language, in the traditional sense. Interpretation implies that the runtime environment interprets the source as it progresses, and e.g. that errors that would have been caught compiletime by others, are reported runtime.

When it comes to performance, it's about time to kill the old idea that java performs so incredibly bad. Look at e.g. this article for a measurement of how well java performed a few years ago. I didn't at first glance find any articles doing similar comparisions using the more recent VMs, but as vendors put effort into still more optimizations, I'd not expect the results to be worse now.

Another aspect of this that you might not have considered is how the JVM is at an advantage over static compilers, as it has the possibility to generate native code *runtime*, using real information on e.g. branching to generate native code which'll keep the CPU pipelines filled. A static compiler cannot do this to the same degree, so it is possible to construct scenarios where Java performs better than natively compiled binaries.

Java Vs .net

[tonywestonuk]

To be quite honest, I dont care at all if .net is better than Java. The point is that .net is controlled by Microsoft, and currently only runs (officially) on M$ products. Mono might be outlawed by Microsoft at any point. You are at their mercy.

The ONLY reason that Sun hasn't relinquished control of Java, is that if they had done so, Microsoft would have been free to embrace/extend/ corner the market.... The same as what they did with Internet explorer.

So, how many non-geeks use anything but, or even know of anything but IE?

Businesses would standardise on MS java, and java on any other platform would become unuseable.. (just as there are web pages that are only useable in IE).

By stating "I'm using C# over Java" you are selling you sole to the devil...You wait till microsoft start extending DRM into the specification, therby relegating projects like Mono to the sidewalk, at this point it will be M$ .net, or nothing. Do not think this will not happen.

So, Its your choice. Choose to go with the, arguabily faster/easier to code offering by our (sarcasm) good friends at Redmond, or choose to fight Microsoft by writing code that will run on all platforms from mobile phones to IBM mainframes. Believe me when I say we will all be better off in the long run.

Re:Java Vs .net

[Billly Gates]

Speaking of mercy and fud responses from the pro .net/mono crowd you can always mention the SCO effect. Corporations obsses with legal costs and potential lawsuits. Company Image is not something that is easy to get back if its hurt. This is important when picking a solution

Most major corporations who are planning on moving to Linux if they have not done so are cancelling and puting their plans on hold thanks to SCO.

If you use mono at work assuming its mature enough and ms pulls a sco you can kiss your linux workstation goodbye.

According to MS halloween documents, legal fud got a negative response form %80 of all bussinesses.

Re:Sounds like what C# has that makes it better...

[cookd]

foreach isn't really redundant. It just gets used a lot when it shouldn't be used. If a type can easily be iterated-over with a standard for loop (for(i=0; i < obj.count; i++) { }) then you shouldn't use foreach. In .Net, at least, the iterator version is somewhat slower.

foreach is designed for cases where you can't simply use an index (i.e. obj[i]), such as a hash table or a linked list. In these cases, you need some kind of state for your iteration -- hence, an iterator.

While you can implement some kind of iterator without language support, language support in this case helps simplify the code. Instead of implementing the iterator yourself in your way (how many ways can this problem be solved?), you use the language-supported way. Much cleaner.

Syntactic sugar is bad when it leads to many ways to do something, but good when it simplifies the common case. I think iterators do this as long as they aren't used inappropriately.

Re:I doubt that Java will succeed.

[oops]

Wake up! When it comes to delivering enterprise solutions (I work mainly in the financial industry) then Java is the primary choice currently. I'm not (necessarily) defending the language, but as a consultant I wouldn't have the same choice of work specialising in any other language.

That may change over the coming years with .Net, but the current 'standard' is Java. Like it or lump it.

Re:Mini Ask Slashdot

[oops]

Here's how you install JBoss.

1. Download
   
2. Unpack
   
3. To run, find the run.sh and run it
   

for an out-of-the-box solution. To deply an app, just copy the app into the deployment directly. To configure, fire up a browser and point it at port 8080 (I think).

Haven't come across many app servers as simple as that.

More Wrong Choices

[ChaoticCoyote]

I program Java for several customers, from scientific to business apllications.

Autoboxing is yet another way of hiding overhead; the wrapper classes still exist, but are now a big "secret" masked by autoboxing.

Why add autoboxing to make containers look more "natural with POD types, then ignore the crying need to operator overloading in scientific and engineering applications? Why one piece of syntactic sugar as opposed to another?

Overall, I'm not terribly impressed. The new generics seem weak; I don't see an emphasis on fixing bugs, stability, or independent standardization. Much as I like Java, 1.5 does not address most of my needs.

Oh no!

[Julian Morrison]

A language which tons of people use for real apps and business critical stuff might become slightly less useful for academia! Panic, panic!

Er. Or, not.

Teach basics in python, algorithms in ocaml, bit-grinding in C.

Why a Large Bank Junked Java

[anonymous cupboard]

We see yet another evoloution of Java, another run-time-environemnt, each of which is subtly incompatible with the rest.

I am working with a large bank at the moment, one of the largest in the world and they have largely junked Java, except for running browser applets.

They liked Java, the class libraries were great but, sorry, it is too slow. I'm not talking about incompetent coders. They even had Sun in looking at some of the apps. The end result was a customised virtual machine - but it was still too slow and the incompatibilities were a killer. The VM had to work identically across the bank's generations of systems from different vendors. One gotcha, IIRC, was synchronisation, making it difficult to run a JVM across processors and to exploit them properly for performance.

End result was a switch back to C++ for back end apps. Java could still be used but only for non-critical front-end stuff. The bank may consider C#, but it seems that Java has had its day.

Maybe this sounds like a troll, but Sun should release their control of the Standard. This will slow things down, think how long it takes to get stuff into C++, but that stability gives everyone room to think as to whether a change is really necessary.

I don't like the idea of C# but at least MS handed it over to ECMA.

Re:Why a Large Bank Junked Java

[bokmann]

I'm tired of hearing that 'java isn't used in real-world applications", then some stupid example touted as proof. Java is used in plenty of real-world scenarios. The U.S. State Department uses java, and so do a large number of countries around the world to aid in the export control of nuclear, chemical, biological, and other hazardous materials.

Re:All the features of C++

[primus_sucks]

I like assembler. I don't want some stupid compiler getting between me and the machine.

ENUMs, yay!

[mekkab]

Shoot, my list of "things I would change about Java if I actually got off my ass and did something instead of complaining all the time" just got 1 entry shorter!

What am I going to bitch about now?!

Everyone's bashing java

[Julian Morrison]

...for getting less simple, but it was never simple to begin with. Simple would be to use weak-vars-strong-values typing like python. Making everything an Object and using that plus typecasts to do generics is not "simple", it's a hack. It uglifies your code, makes it less efficient, and (ironically) breaks strong typing.

Generics are also a hack, but at least they are an overt, clean one.

Re:Everyone's bashing java

[Jagasian]

The way generics are implemented in Java might be a hack, but parametric types are a very sound mathematical construction (see type theory, category theory, etc). When implemented correctly in a programming language, they can:

1. improve programmer productivity
2. improve quality of code
3. improve efficiency (speed/space) of developed software

However, I am sure Java's generics are nothing more than heavy syntactic sugar. Still, anyone who complains about generics in Java doesn't know very much about programming languages. Generics are a good thing, and Java's only mistake is that it didn't have them designed into the language from the begining.

Same goes for Java having "primitive" datatypes. Yeah, that just complicates both syntax and semantics. They seem to be patching up these problems with these new features.

Java is pragmatism over principals

[ggruschow]

So many of the posters here are missing the best reasons to use Java today. Java is highly pragmatic. It's a good, broad set of tools that's widely understood and supported, and often improved.

Java rarely wins in any particular niche. Relatively simple GUIs and COM objects are owned by VB (and Delphi). C++, C, and assembly rule in performance. Perl rules text processing. Python rules in ease of reading. ANSI C, Perl, Python may be more portable. Smalltalk, Eiffel, Lisp, Ruby, ML, Haskel, Forth, and a variety of others are a lot more true to a pure language concept. However, Java does an adequate job in most cases, and when you start crossing boundaries, it'll often be easier to do so in Java-land.

Java isn't innovative. However, it's constantly being improved. Sure, things like JDBC, Collections, SWING, NIO (async I/O), generics, threads, and concurrent garbage collection were available in some form elsewhere previously. They're all packaged into nice, free, portable, well documented, easy to use parts of Java though, and I'm happy to have them.

Java isn't as free as Emacs. However, it's mostly free as in beer, and it doesn't force it's freedom on you. It's certainly a whole lot freer than most things from Redmond. I admit, I don't care if a language is handled by a standards body, unless the company in question holds other monopolies it can abuse. I seriously don't think Sun is going to do anything so wacky as polluting the language to make COM (*cough* MS) or Object Pascal integration (*cough* Borland) easier.

Java's support base and (free) developer tools are just plain great. I love Eclipse, and IDEA and recent JBuilders are pretty nice too. VS.NET is good stuff as well, but contenders like Python are sorely lacking in this arena.

I still write plenty in other languages, but every year the percentage I write in Java goes up.. They keep filling holes (soft references, regexes, async I/O, .1s GC pauses) that were keeping me out of Java. I'm happy to see some more syntatic sugar in Java.. The things they're addressing will make a whole lot of code more readable.

Re:All the features of C++

[angel'o'sphere]

Avoid this crap. Go C++, or better yet Eiffel with C, and stop kidding yourself that Java getting a shiny "for" syntax is a reason for celebration.


Hm,
can you give in your wisdome a hint which library and toolset to use to let my Eifel/C program run on my YOPY, on my Mac and on my Windows PC?

I mean: there is an Eiffel compiler for YOPY, isnt it? And its GUI library is compatible with the one on my Mac, surely it is?

Tzzz.

Java neither has all the features C++ has, nor does C++ have all the features Java has.

E.G. multithreading support and object level synchronization. Java: + C++: -
E.G. garbage collection. Java: + C++: -
Should I continue? RMI? Serialization? Reflection?

When the STL came out, we had the FIRST!! standardized library for C++. Even the iostreams libaries still are platform depended today!

When Java came out, everything thinkable was inside of the core libraries. Networking, multithreading database access, directory services and so on.

Java might suck as a language, I myself said that often enough when I switched from C++ to Java. But that was 8 years ago. Java has improved and does no longer suck, especially with generics. However: the java libs allways where great, the documentation outstanding, the sourcecode available in case of uncertainty. How is that with C++? Standard threading? Since when? Standard GUI library?
C++ is a great language where the libraries and standards came far to late and where even in our days two compilers might get different ideas about your code. Portability is only possible if you restrict yourself to only a subset of C++ ... likely that subset you had in Java 1.1.

Regards,
angel'o'sphere

stop the FUD !

[Anonymous Coward]

Mono is alpha ! and is not, will not and never be any kind of a dotNet on a non MS platform.

Bill stated this clearly : "we will not port the platform to a non MS platform". This includes opening the code source or whatever that could their endanger captive user resources.

If you still think Java is a niche, is because since nearly 10 years you was sleepy ;-)

Java is not the "magic key" for "IT magic kingdom", it is real, effective, efficient and fit your need.

Java is real freedom. Because i can change my OS, the product i use, the business model i got without beeing linked to a provider.

For does who still see Sun as the "big bad wolf", i never pay Sun a buck and i did so in a legal way.

I run linux on clusers, with JBoss, a IBM VM on top of Dell machine (the only stuff i have to pay)! And the architecture i got could manage any kind of a load (as long as my ISP link will manage to pass it to me), because i can add whatever new machine i want (tnx to the multilevel clustering nature of the solution).

It is real, effective, efficient and fit my need ;)

What MS fears the most is Linux + Java. Because it is a more powerfull that they can even provide.

If the Linux gurus where stoping the bashing against Java and looks at the marvelous project made from the opensource comunity they will understand that Java is realy an opportunity to strengthen Linux as an OS leader.

-SLK

Re:Sounds like what C# has that makes it better...

[krumms]

My bet would be that C# was developed taken into consideration common complaints about Java - or things that were already planned to be added to Java 'some time in the future'.

And hats off to Microsoft for doing so, C# is a nice language.

I agree, however, that the next release of Java will raise a few eyebrows wrt 'fixing' Java's current 'problems' (if you could call them that - they're more like syntactic unpleasantries).

Should be interesting ;)

Java's not original

[Jonner]

I sure hope future languages aren't modeled on Java. That will retard language development like too much reliance on C has retarded it over the last couple of decades. But Java isn't even as original as C was. The language design is purely derivative, a cleaned-up, restricted C++ with some features added from other languages, according to Jim.

I'm not saying Java is a bad language, but that it would be a bad one to base others on.

Re:I doubt that MS FUD will succeed.

[nicodaemos]

The Java system is based on the cleaning of a partly object-orientated language: C++. I know C++ coders will hate me for this, but if you compare C++ to real object-orientated languages like Smalltalk or CLOS, you'll have to admit that it's the plain truth.

C++ is fast and less OO, Smalltalk and CLOS are slow and more OO. Since both classes of languages exist, obviously each user has different requirements and choose their level of OO and performance accordingly.

Secondly the Java interpreter scheme was extremely promising, too. However, SUN fuck this advantage totally up ... MS did recognize this potential much better with their .NET system providing a platform for a huge range of languages ranging from C++, C#, Java, VB to even Eiffel.

What exactly is the failure of the Sun VM? It runs on different CPU's and OS's. It has a published VM language for which people can implement compilers. Oh your argument is that the system libraries are inadequate. In what way do you feel they are less in capability than .Net?

And SUN failed unlike MS to provide decent interoperability here, because their Java VM was never really meant to run with other languages.

The common definition of interoperability and MS Interoperability(tm) are slightly different. Essentially, the MS definition is a very small subset of the more common definition. As far as MS is concerned, Interoperability is the ability for MS programs and languages to speak with one another.

So let me ask you, what is the real benefit of the CLR? Do you find yourself writing a lot of C++ in the morning and extending it with VB in the afternoon? No you say, it's to allow multiple programmers to work on the same monolithic application in their language of choice? Oh so the ui guys can code in VB and the backend people can write in C++ or C#. Mmmm ... I've seen many languages interoperate in monolithic applications such as C, Fortran, Tcl, Java so I'm not exactly sure what MS has added as new. And if we're talking about most applications which are distributed (ie. non-monolithic) nowadays, then the point of a CLR becomes even less clear.

Mensa member, beware of the high IQ

I don't often pick on people, but I think the combination of this signature with the post forces my hand. A more apt signature for this post would have been: MS shill, beware of the FUD

Re:Loops and iterators.

[bkocik]

Personally I don't like for loops with Iterators, it just seems not quite right (I think it's a hang-over from my days as a Pascal programmer).

I think you meant hold-over. But since you were talking about Pascal, maybe hangover is a bit more appropriate. ;)

Re:All the features of C++

[be-fan]

ISO C++ was standardized in 1998. GCC 3.x (came out in 2001) supported every language feature except "export" which is now believed to be a mis-feature. All the compilers I use on a daily basis (GCC 3.2.2 and Intel C++ 7.1) compile every bit of code I've thrown at it.

Re:I doubt that Java will succeed.

[be-fan]

The fact of the matter is that operator overloading always leads to evil abuses.
>>>>>>>>>
I've seen many C++ libraries, and I've never seen an evil abuse of operator overloading. Of course, I work mostly alone, so I don't encounter crappy programmers that often. But I don't think that a language should sacrifice completeness and orthogonality for the sake of bad programmers.

Some of which are evident in the C++ standard libraries as glaring examples of how irresistively seductive the temptation to abuse operator overloading is.
>>>>>>>>>
Its not the same operator. One is the bit-shift operator, and is only defined for integral types, because it only makes sense for integral types. It's just like how the % operator is only defined for integral types, and not floating point ones. The other is the stream operator, and is the one that can be overloaded. The fact that they look the same is irrelevent. In Java, addition and concatenation are both operator+, and nobody seems to have a problem with that! Integral division and floating point division is both operator/, and again, nobody seems to have a problem with that. Beyond that, the C++ streaming mechanism is a lot more flexible than Java's method of requiring printable objects to have a toString method.

iteration

[jefu]

While most of these changes are quite positive, I think the iteration mechanism still could use some changes. Most simply, along with :
for (int i : C) {... }
also allow :
for (int i : C.iterator) { }
so that iterators other than the default (the SimpleIterator named "iterator") could be used.

This would not complicate the iterator syntax much and would make using different iterators easy - and thats something that is often needed.

Since the "C" above is an expression, it could be a function that returns an "Iterable" - allowing interesting hackery to provide alternate iterators using inner classes or other fun. However while I think this allows programmers to do about what they need, it does not make things exactly readable and that is a bit bothersome.

Another thing I'd like, and would like to have efficient and easy to use, is a way to iterate over the indexes of an array - in particular a multidimensional array. I get tired of doing things like the following (which I can't get to indent easily) :

for (int i = 0 ; i < ilim ; i++)
for (int j = 0 ; j < jlim ; j++)
for (int k = 0 ; k < klim ; k++)
b[i][j][k] = a[i][j][k] + 1

It would be much easier to do something like

for ( (i,j,k) : a.indexes) { ... }

In a way, no.

[Latent Heat]

for (int i = 0; i is something I understand and can read in an instant. I call this a "C-ism" in that from C to C++ to Java to C# it means the same darned thing, and it occurs so often I don't have to blink when I see it.

for (int i : C) {}

or more properly

for (CMemberType cMem: C) {}

is something that I have to scratch my head about. The fact that people conflate i with c_mem and confuse a collection member with a loop index tells me that the new construct is going to give problems.

Yeah, yeah, Law of Demeter and all that style stuff, you shouldn't be pulling values out of objects and doing logic on them, you should be telling an object what to do and have it do it. But you can take all this OO purity so far, and the first way is instantly recognized by every C, C++, Java, and C# programmer.

You take all this OO purity stuff so far and you have something that looks like Objective C, Smalltalk, (God forbid) Eiffel, or C++ STL on a bad hair day. I am a Pascal person myself, but as of 2003 I am willing to concede that C-style syntax has won: there is a huge "installed-base" of programmers familiar with it. I am all in favor of staying consistent with it instead of going of inventing all kinds of bizarro syntax.

Re:I'll care when native compilers become the norm

[Glock27]

Buuuuzzzzzz! Wrong! Nu-uh!

That is impossible. Java has to do the same as the C code, plus the extra overhead of doing the JIT. There is no way Java can be "as fast".

Ah, the "impossible" word. ;-)

You're presuming that the ahead-of-time compiler can "know" everything that the JITC can. That isn't true, in many common cases.

Another point regarding JITC compilation is that it can be for the exact target processor, something not typically the case for traditionally compiled programs.

All that said, current JVM performance certainly varies between 'better than C++' and 'worse than C++', with pathological cases in both directions.

The current 1.4 JVMs actually took a hit on some math operations, though that is supposed to be fixed in 1.5.

I hope gcj gets to the point where it supports the latest language spec. The libraries are tougher, and many of them aren't needed for interesting projects. For certain applications, an ahead-of-time compiler is nice.

By the way, for a good example of a 'fast' Java program, check out Eclipse from www.eclipse.org.

Re:oh come on.... download the files first.

[bigfleet]

The changes mentioned in the other products have been integrated into JSR-14. So while it would appear that maybe nothing that big has happened, you in fact have a useful 1.5 preview.

Scout's honor.

Teach the kids Scheme or Smalltalk.-eToys.

[Anonymous Coward]

I agree with Squeak one can teach some powerful ideas even to kids (which is one of Alan Kay's goals). You can just like Java run applets in your browser.

NEWSFLASH: Java not solution for all code projects

[Kunta Kinte]

Java is not the fix for all code projects. No language is.

I don't like the idea of C# but at least MS handed it over to ECMA.

Microsoft has handed C# to the ECMA, not .NET.

The language is insignificant compared the the framework, that is the large set of APIs, libraries, documenation, and endorsements that come with the language.

C# being offered to the ECMA is a marketing ploy.

Look at ECMAScript. It's a standard isn't it? Now how come we still have to be careful which browser we're in when we write JavaScript/JScript for the web?

It does not matter what ECMA says. Microsoft will always have the de-facto standard on C#, because they produce the environment Visual Studio .NET used by most professionals, they distribute the most runtimes/CLR, they produce the documenation, they have the marketing muscle ( $40B in the bank ).

Don't fall for this cheap trick.

Re:I'll care when native compilers become the norm

[Kunta Kinte]

If you are running a J2EE app as middleware for a huge ecomerce or CRM system, etc then sure recompile to native code,...

I don't see any performance issues in my J2EE apps.

Java is slow largely becuase of JVM startup and GUI framework. But J2EE Apps don't have to worry about either of these. The J2EE Server's JVM is started only on Application startup, which only happens when you need to restart your J2EE Server. And there's no GUI layer ( JSP for presentation ).

Truth is in large server-side apps, I'd expect J2EE with JSP to kick the crap out of PHP, PERL and others.

Collections should be first-class entities

[Admiral Burrito]

Also look at what you can do with variable arity functions. Say you have a constructor for a collection class and you want to be able to initialize a variable number of default values.

You can already declare arrays in-line. So if they were to define an appropriate constructor, you could do List l = new ArrayList(new Object[] { "foo", "bar", "baz" }).

That is verbose of course. What they really should do is add collection manipulation stuff to the language, so you could go List l = ( "foo", "bar", "baz" ) and be done with it.

I believe that that scripting languages get most of their advantages (more functionality with less code, easy to develop in, etc) because they have collections as first-class entities. It's not as if it would be polluting the language... How often do you write code that doesn't use some kind of aggregate data type? For the language to not recognize that is just silly.

Re:C# Genericity ! Stop the FUD.

[Hognoxious]

Well, it's personal preference. Some like sin(), others Math.sin().

Personally, i think it's awesome.

The Math object is the classic demonstration of where the object paradigm breaks down. Sin is a function. It just is. Shoehorning it into an arbitrary object that simply doesn't correspond to anything in the real world is pure dogma - OO for the sake of OO.