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

[Anonymous Coward]

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

These fragments have different meanings.
In the first loop, i is 0, 1, ..., C.length-1.
In the second loop, i is C[0], C[1], ..., C[C.length-1].
That's why they chose e as the loop variable in the example "for (int e : a)". The loop variable is not an index.

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

[ebash]

I'm not an expert in writing compilers but i think that if properly done the for loop oven an array won't have any impact. When the compiler will parse a statement like for (i : arrayVariable) it will know at compile time that "arrayVariable" is actually an array[] so it can replace the byte code by something like for(int i = 0; ...

Re:good and bad ...?

[cookd]

But the iterator is not standardized. Part of the spec is to introduce an Iterable interface, which standardizes the iterator.

Re:good and bad ...?

[cookd]

I guess it depends on the implementation and the final precise spec of the standard. If you do:

void ItFunc(Iterable itAble)
{
for(Iterator it : itAble)
{ ... }
}

the compiler has no way of knowing that itAble might be an array and doesn't actually require an iterator.

Re:good and bad ...?

[addaon]

What part of the class library? Unless you think C is some instance of a standard class from the class library... but I can't think of a single class with a length member variable. I was assuming that C was an array which, although it extends Object in java, is not a class from the class library.

Now, assuming this also works on Collections objects, it will, indeed, be a hack, but no more so than serialization or cloning. We've done worse things to java for less reward.

Re:good and bad ...?

[bellings]

varargs? Why? It is an object-oriented language - take use of that polymorphism!

How are varargs and polymorphism related? Or, rather, for a language using single dispatch, like Java, how are varargs and polymorphism related, in any way?

I don't know if you've noticed, but Java doesn't do method dispatch based on the runtime type of a methods arguements. In other words, the methods's arguements have nothing to do with the polymorphism of a method. So, how could something like varargs, which is a change that effects the arguements to a method, be replaced by single-dispatch polymorphism?

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

[dubious9]

Those funky java guys like to avoid keywords because they will possibly invalidate older code that uses the keywords as identifiers. The goal with this release was to make sure that old code will still compile with the new version and class files will still run on older jvms.

Introducing keywords generates lots of flack from companies that support java because then they will have to go back into their older code to make sure everything works right. It's a decision that would have cost millions of dollars. Why add foreach when 'for' will do?

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.

Re:good and bad ...?

[BenTels0]

I think he either means avoiding variable argument arity in favor of increasing the number of overloads of a method name, or thinks that varargs means having something like a union-type argument where the same argument can either be of type A or of type B and wants to replace the whole mess with a common supertype C.

Of course, you don't need variable arity methods in Java (and they haven't been proposed, don't know where that came from); once you have a (raw) collection type, you have an infinite (well....) number of arguments right there.

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.

[jericho4.0]

Of course you can handle pointers!! I'm tired of running into Java programmers who are scared of lower level code (read: C). Get the K&R book and read it start to finish already!! A decent amount of experience programming in any procedural language will make looking at C a lot clearer.

Java's slowness is an inherent property, sorry. It's just a function of its design, not a flaw. 'Serious' 3D grahics will always be done at a lower level than languages such as Java, if 'serious' means 'state of the art'. Most interesting 3D code is written in a language specific to that domain (OpenGL, Cg, vertex shaders) anyway, so it's not like any other language has an advantage .
I think Java is a great language, for what it does. No one language can be everything for all people, and learning one language shouldn't stop you from learning another.

Re:No subject.

[bokmann]

before you troll about 'serious 3d graphics', I think you should take a look at Java 3D and applications that use it such as WilmaScope>/a>

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.

[Hard_Code]

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

Some day? There is both pure Java (YES) 3D support as well as natively accelerated OpenGL support in Java, under the Java3D package. Maybe this is not the "serious 3d graphics" you were talking about (CGI films?), but 3d is definately possible on Java.

Re:No subject.

[digidave]

The only thing worse than people who say Java is slow is those who say it is fast.

Re:No subject.

[wmshub]

You know, I think any C/C++ programmer who actually looks at how their time is spent eventually decides that they have wasted enough hours chasing down one-past-the array bugs, free-then-access bugs, and just plain wild pointer bugs. Java may run more slowly than C/C++, but these bugs pretty much just can't even occur in that language. I envy the people who are scared of pointers to begin with, stick with java, and never have to waste their time on these bugs. Sure, most programmers are smart enough to learn how pointers work - but I have yet to meet a programmer who can code in pointers and explicit memory deallocation without creating some very very nasty bugs once in a while. Sure, in C++ you can use smart pointers of various flavors to ease the pain, but they only get you so far and without true garbage collection and runtime reachability systems you can't always avoid these problems.

That being said, my current job is doing C++ work for a few reasons, and "java might not be fast enough" was one of the things that came up when the language was being decided for this project. Oh well.

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.

Re:No subject.

[jericho4.0]

I agree with all of that. My point was that for some things (ie; 3D programming), not all languages are created equal. A programmer isn't really a programmer until they seperate 'writing a program' from 'writing Java' (or whatever).

Taking your manual/auto transmission example, an automatic is fine for almost anyone, and there's no shame in not knowing how to drive a stick, but if you want to become a competitive racer, then you're going to have to learn.

Re:Sounds Promising

[jedigeek]

I think generics are one of the most promising additions. I used to work with them in Ada years ago and always thought they'd work well in Java, and perhaps help with a few common bugs.

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.

[EJB]

> 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?

Omygod I'm responding to a troll.
a) Upgrade your P133
b) Upgrade from 64 megabytes to something reasonable
c) Nobody cares that the application server which runs a business application takes 20 seconds to start

Not that VM sharing wouldn't be nice to have, but for the typical uses of java, like server applications or IDE's, 10-20 seconds to start is no problem at all.

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.

[1010011010]

I have another question -- how long until there is a JDK for RedHat9 and its spiffy new threading mechanism?

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.

[jeti]

> Not that VM sharing wouldn't be nice to have, but for the typical uses of java, like server applications or IDE's, 10-20 seconds to start is no problem at all.

Which is an interesting observation in itself. If you remember, Java was once called Oak and was planned to be used on embedded devices.
Then the internet hype began, it was renamed to Java, and marketed for internet-centric applications with an emphasis on the client.

Java didn't cut it on the embedded market (although some smartphones sport Java ME as a little extra). Java didn't cut it on internet clients. It has now found a small nieche on enterprise servers.

And your comment makes it sound as if Java was designed for that nieche and other targets wouldn't matter at all.

Re:Too litttle, too late.

[mabinogi]

> Java was once called Oak and was planned to be used on embedded devices.

An embedded device is not likely to be running a general purpose operating system, that then has to start a JVM for every command...

It's likely to be running the JVM from power on to power off, and the single application will run in that JVM for the whole time.

Also, looking at the flaws of J2SE in that regard, and assuming they apply to J2ME is a little naive...

Re:Too litttle, too late.

[angel'o'sphere]

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

Could you point out such a Zealot? No Java Zealot ever said that. In fact it was planned in the first Java release and got dropped due to time to market restrictions. Later it got postponed and postponed, for J2EE, probbaly, no idea.


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.

Here speaks the expert it seems :-)
Could you kindly point out the relation between templates, ArrayLists, Integer objects and the heap?
For the unaware: there is no relation.

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? Progress doesn't come from early risers - progress is made by lazy men looking for easier ways to do

If you like VM shareing, why dont you modify the start up scripts of the Java applications you use to share one single VM?

As long as no application calls System.exit() it works perfect.

Tzzz.... its so easy ... but its more easy to flame around, I guess. Your post is FUD, to bad it got modded up to 5.

Regards,
angel'o'sphere

Re:Too litttle, too late.

[angel'o'sphere]

Java didn't cut it on the embedded market (although some smartphones sport Java ME as a little extra). Java didn't cut it on internet clients. It has now found a small nieche on enterprise servers.


I would estimate that 75% of all code which is written is code to be executed on enterprise servers. Most bigger companies have business applications which are not off the shelf but self crafted.

90% of enterprise applications are written in Java in our days. At least in germany. And the scarese reports from other countries :-) dont show any difference there.

So: do you call ~50% off all code written in our days a smal nieche?

Regards,
angel'o'sphere

Re:Too litttle, too late.

[angel'o'sphere]

Thre are hundrets of descent cleint applications written in Java.

E.g.: CoeGuide from omnicore.com.

I dont think that VM sharing helps the masses.
Your suggestions about thread management in XML files seems not to cut it either. A lot of programms are designed to use a fixed number of threads. Restrict the number of threads below that fixed value and the program does not run at all.

Also you see problems where are none. Two Java Apps in the same VM can't interact with each other (at least not without planning to do so) that means they can not cause havoc on each other except for causing VMErrors, wich are likely errors in the VM, thats why they are named like that.

The only problem is: System.exit(). Because that closes the VM and exits all other programs on the same VM as well.

So: the easy solution is to modify the library, to change System.exit() to behave different.

But that is a short sight solution, as there are side effects.

I think you need to rewrite the thread management to get a descent "one VM only" Java. Also you have to rewrite JIT compiling. Because your words about recompiling Swing for each java app .... thats as well happening if you run two apps in the same VM. Because the codebase of the two apps are seperated via the usage of seperated ClassLoaders. The jit compiler would need to realise that two classes laoded are indeed the same class and that it can reuse allready compiled code.

Bottom line: the amount of code changes to make a shared VM is not trivial. The impact will likely even break old code relying on specific behaviour in the existing VM environment.

And as long as you can not point out a solution ... why dont you simply stop flaming?

angel'o'sphere

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.

[Ed Avis]

First rule of computer journalism: no technology exists until Microsoft invents it.

Corollary: most language features are too obscure, complex and dangerous, until Java adopts them.

Re:Too litttle, too late.

[the eric conspiracy]

you also gain compile-time type checking

Elimination of run-time casting errors tipped the balance in favor of inclusion of generics into Java. Syntactic sugar is one thing, but the increase in reliability that can be gained through the use of generics is a very powerful argument in its favor.

Re:Too litttle, too late.

[AdamInParadise]

"The only problem is: System.exit(). Because that closes the VM and exits all other programs on the same VM as well."

Then there is no problem left, because this one was solved in Java 1.1! It's called the SecurityManager. It assigns rights to applications according to some arbitrary rules. It can handle different applications running at the same time in a single JVM. Usually, rules are assigned according to the origin of the program: applets run in some kind of a sandbox while local applications get full access.

Of course you can program you own SecurityManager in order set your own rules but unless you are looking for a very specific security model, the default one is good enough.

Now there is some more fundamental problems with JVM sharing but since Apple did it in their implementation of Java, Sun should be able to sort it out.

See my homepage for a nice article of mine about JVM sharing.

Re:Too litttle, too late.

[Montreal]

I posted this further down, but Apple already provides a single-VM solution that Sun are looking at. It probably won't be in 1.5 though.

Re:Too litttle, too late.

[Milo77]

If sun will not do VM sharing, you will never see decent client applications written in java.

Just because you've never seen decent java client apps doesn't mean they don't exist - it means you've never seen them. I uses eclipse (uses SWT) daily and I seriously forget that I am using a java application. I've also written several client applications that use SWT and the users typically can't tell the difference between them and native windows apps. That's because visually there is *no* difference, and performance wise there isn't any either (clients avg computer is ~500mhz).

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.

Re:Too litttle, too late.

[cakoose]

Gernerics are not about extra efficy, but about the compiler flagging errors.

Does anybody know if the class cast will be ommitted? That would be an efficiency increase.

Re:Too litttle, too late.

[Kunta Kinte]

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.

This is not a good comparison. You are faulting Java for your bad decision in choosing a collection class.

'ArrayList' is a list of 'Class Object' objects. In .NET you probably have an array of 'Class Object' objects as well, ie. An array of the lowest common denominator object in the language libraries. Previous Microsoft developed libraries have the same thing, eg. MFC has 'Class CObjectArray'.

This is not a language specific issue, this is how object orient collection classes are usually done, as far as I've seen. There is good reason. You can iterate through the resulting collection assuming each item has the member functions of your base object class. And that's a very useful assumption.

There is nothing stopping you in Java or .NET to write a list class for type int. Not because it's not found in java.util or where does it mean that it can't be done. In fact this is so trivial, I can't figure a reason why it would be included in the core Java libraries.

Re:Too litttle, too late.

[rhavyn]

The new threading system in Red Hat 9 is still a pthreads implementation. Java should automatically take advantage of it without any changes.

Re:Too litttle, too late.

[4of12]

It has now found a small nieche on enterprise servers.

Today's enterprise servers are the embedded devices of the next decade.

I think, though, that Sun would like for Java to catch on a little faster than that timescale suggests, though:)

Re:Too litttle, too late.

[dkf]

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.

No. In Java an array of ints is an array of 32-bit values that is stored in memory as an array of 32-bit values. There are many OO purists who howl and scream about this as they'd prefer the situation you (mistakenly) outline, but that's the way it is. Now, the array itself is an Object, but so's everything else that can be passed around by reference...

Some of your other points are valid though. I'll let you guess which ones... ;^)

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

[afidel]

This is offtopic so no +1...
If you want to teach clean OO principals with a language that is not cluttered with a bunch of stuff that makes programs harder to read then look into Eiffel. It is the most pure OO language around and almost all the skills learned can be transfered to other OO languages like Java and C++. And now that the CLR support Eiffel the argument against it being a usefull language for real work is lessened (the fact that it is used by HP for firmware and the european space agency for Ariana firmware escapes people who used to claim it was a worthless academic language). That and it has the advantage of design by contract so you can enforce and instill good programming practices in those young minds =)

Re:Simplicity lost

[Glorat]

But do you have to use all the new complex features?

Besides, if the answer is that you must use these new features or doing X isn't easy, might that not suggest the new feature has made life simpler for developers?

Re:Simplicity lost

[Glyndwr]

I agree. I'm a PhD student at Cardiff Uni and I've spent a lot of time teaching Java to undergrads, some of whom have limited programming experience. It was once a beautiful teaching language, but every new version of the language makes it harder and harder for beginners.

Don't get me wrong, I also code Java and I love the new features; the trick, as you say, is to focus on teaching a subset. Nevertheless, I await with dread the point next semester when a student points to a piece of example code with an inner class and asks "what's that?"

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

[Glyndwr]

I've thought of this, and I'd love to, but as a lowly PhD student I find it difficult to change the primary teaching language of a 700-strong computer science department. When I'm king of the world, I'll add it to my ToDo list.

Re:Simplicity lost

[Glyndwr]

Oh, and I don't regard Java as anything even close to a syntactic nightmare. But then again I do a lot of Perl so I have a warped perspective.

Re:Simplicity lost

[j-b0y]

and the european space agency for Ariana firmware

Surely ADA, not Eiffel? I've never heard of anyone using Eiffel for On-Board Software.

Re:Simplicity lost

[Jan Venema]

Yes you do, because you have to read other people's programms as well. For instance SUN proposes variance to make for more intuitive use of generics:
public static <T> void fill(List<-T> list, T o) { ... }
public static <T> void copy(List<-T> dest, List<+T> src) { ... }
this becomes difficult to read and understand what the author was trying to express.

Re:Simplicity lost

[aurelien]

"I'm a bit afraid that java may lose it's positions as simple OO language which can be used for teaching in schools."

I will be soooo happy when this happens. Python is the language that should be used for teaching in schools - you see, it's simple OO language, a simple functional language and has the real advantages of an interpreted/dynamic language : dynamic strong typing.

It also has a vastly more clearer syntax and is vastly more easier to read that any piece of Java crap.

Ditch Java, go Python.

In the end, Java is just the Cobol of the 90's and will die very slowly while causing a lot of pain and brain damage to a lot of poor programmers - and students. Sun deserves to be punished for that. They will be soon...

Re:Simplicity lost

[Jan Venema]

Collection<E>{
E[=] toArray();
<T extends E[-]> T toArray(T a);
}
Collection<Number> cn;
Number[=] nea = cn.toArray();
Number n = nea[0]; // ok
nea[0] = new Integer(3); // ok - can insert any subtype of Number
cn.toArray(nea); // so, I can use Number[=] where a Number[-] is expected

Re:Simplicity lost

[afidel]

You are correct, it has been 6 years and the failure of ADA code to correctly catch an exception was used as an example of where design by contract could have negated a $500 million dollar loss. But if HP uses it for printer firmware I doubt it's much less robust than ADA for imbedded applications. btw for a list of some high profile uses of Eiffel in commercial and scientific environements see: Here and Here

Re:Simplicity lost

[Jonner]

Well, I believe it was designed for embedded consumer multimedia electronics devices. You're right, though: it was not designed for teaching. The main thing has disappointed me about Java is its lack of expressive power and flexibility, so if language extensions improve that, they can't be all bad.

And, as people have been mentioning, Scheme is a far better example of simplicity and power in a small package. It has far simpler syntax than any other language I know, but is more extensible than all of them. One would be hard pressed to find a language feature or programming style that can't be well expressed in this 28 year old language.

It seems there isn't a whole lot of interesting stuff happening with language design, at least that's very visible. Others have mentioned (I haven't learned it yet) the simplicity and power of Smalltalk, a language of similar vintage to Scheme. Is there anything new under the sun (no pun intended) in language design? If there is, it's probably in something like Eiffel (another one I should learn sometime) or one of the pure functional languages like OCaml (there's another one for the list). Meanwhile, most of the world continues to use languages descended from a portable assembler.

Re:Simplicity lost

[obsidian head]

First of all Python is not superior, from what I've seen so far it is a nice pascal OO successor with a little bit of lisp and other languages blendet in, nothing really new.

"New" does not mean superior.

No explizit varables and types (which I would consider unsafe for bigger projects)

By that I believe you mean no explicit, static typing. Instead of telling the compiler, "Here are some types, tell me when there's a type error," you tell it, "Here's my unit tests, tell me if there's an error."

it is just another OO scripting language which gets more hype than it deserves.

Do you program in python? Because it's not an "OO scriping language." It supports OO, but there's no reason to use OO if you don't want it.

Re:Simplicity lost

[abies]

No, in your example, you do not expect Number[-], you expect 'T extends E[-]', which as far as I understand, means totally anything. E[-] could be Object[], so T extends Object[] can be any array (am I right?). So code behaves exactly as it should, you have just created bad collection interface.

Re:Simplicity lost

[the eric conspiracy]

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

Re:Simplicity lost

[be-fan]

Any language that doesn't have an interactive interpreter is TOTALLY unsuited for teaching.

Re:Simplicity lost

[gbjbaanb]

yay. I second that totally.

Not only should universities be teaching students *about* programming, including techniques and best practices, they should never, ever give the students anything they can take to the workplace thinking better than the employees.

Too many students come out of CS courses thinking Java is the only progamming language, and have difficulty moving to whatever the company uses (because they know how to do something in Java, they dont understand the technique - they only know the practise), but also come with a less than flexible mind-set.

Sometimes its no wonder companies prefer grads who don't have a CS degree.

Re:Simplicity lost

[Hanji]

It's not exactly Java, but Beanshell works pretty nicely

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.

Re:Simplicity lost

[top_down]

Only library programmers will usually write things like that. In normal use you just use sort(...) and fill(...) and the compiler will generate the right function for you depending on the arguments. At least that is how it works in C++.

I dont know how good the implementation in Java is, but for C++ everbody I know who learned it, loved it. It is a large part of what makes C++ such a sexy language.

Re:Simplicity lost

[Tony-A]

Too many students come out of CS courses thinking Java is the only progamming language, and have difficulty moving to whatever the company uses
Good grief. What ever happened to the "Teach Pascal, Use Fortran" mentality?

Re:Simplicity lost

[be-fan]

However, DynamicJava isn't really Java. It's an extension of Java that makes it more palatable for interactive use. Java by itself is too structure-happy to make it suitable for interactive use.

The use of non printing characters as syntax elements is ridiculous on the face of it.
>>>>>>>>>>>>
Not at all. None of the other language fields (mathematical and human languages) bother with explicit delimiters to group related statements, so the use of synactical block delimiters is totally alien to non-programmers. If the computer doesn't need it, and it is more natural for a human to use whitespace as a delimiter, why bother with explicit delimiters in the language?

Re:Simplicity lost

[j-b0y]

Yes, but all this 20/20 hindsight stuff is very interesting if you're only interested in retrofitting today's technology onto that developed more than 10 years ago. Where was DBC and Eiffel then? Stuck in academia, no doubt. I wouldn't be surprised to see of the innovations in Eiffel make their way into other environments (except Java, of course, where the recommended solution to adding DBC to Java was of course, to program in Eiffel. Gee, thanks.)

Re:Simplicity lost

[Hard_Code]

If anything these proposals INCREASE simplicity. If you ever deal with collections, you will be familiar with all the myriad (brittle) casting that has to go on. Likewise with iteration over collections. Genericity simplifies the former, and the alternative collections-based for loop simplifies the latter. If you have ever tried implementing enumerations in Java you know you have two (poor) choices: 1) hardcoded numeric constants, or 2) hardcoded static object instances. Both of these are ugly and add more complexity. Moreso for static imports, where people end up doing the wrong thing by implementing an interface to gain access to its constants without full qualification, but unintentionally binding themselves to the contract of that interface. These 1.5 changes are all about simplifying things the developer community has been griping about for a long time.

(that said, yes there are ugly complicated parts of java but they are relatively few and far between and are not increased by these proposals)

Re:Simplicity lost

[abies]

If anything these proposals INCREASE simplicity.

I'm not a native speaker of english language, but increasing simplicity sounds very strange to me - I would rather think in terms of decreasing complexity. I know that in theory it is the same, just sounds a bit like oxymoron to my untrained ear... Anyway, as you might have noted, I have said nothing against foreach or enums. I have only said, that while
String str = (String)list.get(1);
is ugly, it is easier to understand than construct like
E[-] toArray(E[-] arr);

I'm absolutely pro the new changes - and variant-based generics promise to solve dark areas of previous java generics solution. I'm just worried about fact that adding quite a few new magic operators to language increases amount of knowledge you need to start understanding other people's code.

Re:Simplicity lost

[Minna Kirai]

Any language that needs an interactive interpreter is TOTALLY unsuited for classrooms.

Re:Simplicity lost

[be-fan]

Like Scheme, Lisp, and Smalltalk?

Re:Simplicity lost

[semanticgap]

The use of non printing characters as syntax elements is ridiculous on the face of it.

Python is hardly unique here. Most languages I know use spaces or tabs to separate tokens. How is that not using "non printing characters as syntax elements"?

Re:Simplicity lost

[gbjbaanb]

I could say that java is percieved as an all-pervasive language that will fulfill everyone's needs forever, but I don't really know.

What did happen is that many unis needed to move away from procedural Pascal programming to OOP, when they cast around looking, Java seemed to fit the bill, or was hyped up at the time.

I'd prefer them to teach Oberon, use C++ nowadays. ho hum, instead we'll just have to keep giving the 'hotshot' kids the oldest, legacy programs to maintain :-)

Re:Simplicity lost

[iabervon]

None of this is particularly complicated, really. Generics are easy; rather than saying something is a List, you say it's a List of Somethings, just like you've always done with arrays. Variance is a bit trickier, but you don't need to use it unless you're writing a library (since you know the exact types you intend most of the time). Enums are easy; they do the obvious thing better than you could sanely implement it otherwise. The rest of the stuff is simple syntactic variation, doing the obvious things.

Anonymous inner classes are terribly ugly syntax, but neither too difficult, nor are they necessary to teach to students. They are, at least, preferable to the alternatives in the situation where you actually have any reason to use them.

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

Finally...

[loony]

Glad to see that .Net seems to have a good side - it gives Java competition and we finally see some of the nessecary improvements.

Static Imports are especially nice - Instead of Math.abs() one can finally just use abs().
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 solution...

Re:Finally...

[abies]

Indeed, foreach would be more clear - they even have mentioned it in design document. But unfortunately, java has to be backward compatible with previous versions of source code (look at the mess with assert keyword), so they have decided to go a bit more ugly, but fully compatible route.

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.

Re:Finally...

[mlk]

I think this could of be avioded with java-doc like systax at the class level, so /* @useNiceForEach */
Maybe?
But its too late to suggest now.

Re:Finally...

[abies]

I really hate hiding things important to syntax inside comments. Borland pascal had it (turning on/off interrupts etc) and it was ugly. I'm kind of purist as far as comments are concerned - for me, comment should be a whitespace for a compiler.

Re:Finally...

[xv4n]

Indeed. Unless they introduce pragma statements (import jdk15; // or something similar) we are pretty much stuck with our current keywords. So instead of the more readable

foreach(element in myCollection) { ... }

we'll get the sugarless version

for(element : myCollection) { ... }

think of it as diet-cola syntax =)

I doubt that Java will succeed.

[Krapangor]

While the interpreted compile-once-run-everywhere and the garbadge collection scheme and pretty nice and useful, Java will take down the road to oblivion in the long term nevertheless.
Why will this happen ?
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.
Java's goal where to simplify and objectize C++. However during this process some of the most promising parts of C++ where thrown out - operator overloading and generic programming. But this Java's power was seriously crippled and it will never reach the state-of-art level of academic theory of OO-languages.
Secondly the Java interpreter scheme was extremely promising, too. However, SUN fuck this advantage totally up by concentrating on their modified C++ clone. 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.
Some people will now protest that "There is this Gonzo++ implemenation of the Java VM." This is indeed true, people got stuff from C++ to Lisp running on the Java VM. But this argument is rather pointless: the power of a modern VM system does not lie alone in the interpreter, but in the system libraries, too. And SUN failed unlike MS to provide decent interoperability here, because their Java VM was never really meant to run with other languages.

Personally i think that these design flaws will kill Java in the long term. There might exist many apps with Java these days, but this holds for Cobol, too. Even people in the OSS community start to realize this and move the MS's .NET system with projects like MONO etc.

Re:I doubt that Java will succeed.

[afidel]

Java isn't going anywhere for the same reason COBOL isn't going anywhere, IBM made it a standard for backend and middlewhere software. There is so much J2EE code out there that not many large business can afford to drop Java at this point. From what I've seen there are not that many large projects centered around the CRL and C# and due to scalability concerns and vendor lockin concerns I really don't think there will be that many.

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:I doubt that Java will succeed.

[KingRamsis]

I'm not defending Java...

it will never reach the state-of-art level of academic theory of OO-languages.

the very nature of the native machine that the software runs on is not object oriented so some mapping glitches are expected you cannot expect to treat everything as an object and get an efficient program, so when given the choice of Integer and int I would blindly choose int and only wrap it in an Integer object only when needed, as you said it is an academic theory.

Secondly the Java interpreter scheme was extremely promising, too. However, SUN fuck this advantage totally up by concentrating on their modified C++ clone. 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.

Nothing can stop you from writing your own compiler that generates bytecode that runs on the JVM directly, I've seen implementations of a C, C++ compilers that emits bytecode ready to run on the JVM.

And SUN failed unlike MS to provide decent interoperability

well I agree they were slow but not completely failed.


Personally i think that these design flaws will kill Java in the long term

it is too early to judge with every new version of the JDK I hate Java less and less,

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:I doubt that Java will succeed.

[Golthar]

Try the IBM VM, its 100% java compatible.
There is also BlackDown.
HP has its VM
BEA has one..
The list goes on

Google Java SE directory

Re:I doubt that Java will succeed.

[smallpaul]

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

If everyone always uses what "everyone else is using" then there will be no language progress. When Java came out I was an early adopter because sometimes somebody needs to move beyond what "everyone else is doing" (which was C/C++). I've since moved on to Python.

Re:I doubt that Java will succeed.

[the eric conspiracy]

some of the most promising parts of C++ where thrown out - operator overloading and generic programming.

Did you even read the article? This version implements generics. As far as operator overloading, that is a VERY controversial feature.

As far as .Net providing a platform for a wide variety of languages, you have been reading too much Microsoft hype. The languages that people will use are C# (a Java clone) and VB.Net (a version of VB with some Java-like features grafted on to it). Attempts to move other languages like Eiffel to .Net have run into problems with limitations in the underlying CIL - written primarily to support Java-like languages, NOT other paradigms like those of Eiffel - so we end up with Eiffel#, a bastardized Eiffel that guess what works like another kind of Java.

Oh, Guess What? That wonderful CIL that supports all those other languages does not support generics yet.

Re:I doubt that Java will succeed.

[Jonner]

Which one of those doesn't use code licensed from Sun?

Re:I doubt that Java will succeed.

[Jonner]

I find those companies on this list of Java Licensees, so I doubt their implementations are independent. Neither is Blackdown, according to their FAQ. I would be a lot less wary of using one of the listed implementations of Java than using Microsoft's .Net, but Sun does still own Java and I'm still not aware of any completely independent implementations that are not way behind the official one.

Re:I doubt that Java will succeed.

[be-fan]

Lack of operator overloading is a defect in a C-style language. Look at it this way: operators in a statically typed language like C++/Java are just functions. Since function overloading is allowed, operator overloading should be allowed as well. Not allowing overloading of operators is not orthogonal. Further, most of the accusations of ambiguity have no basis, since the operators for the built-in types are predefined, and thus not overloadable. In 99% of cases where operator overloading should be used, it simply adds meaning rather than changing existing meaning. Of course, there is the accusation that operator overloading can be used to "lie" in an interface. But you can always write a function called "doThis()" that instead does "That".

Also, Java generics have nowhere near the amount of generative power that C++ templates have. Together, C++ templates and operator overloading are two very powerful building blocks. They let you implement abstractions cleanly, and allow user-defined types to behave like built-in types. These building blocks make smart pointers, numeric class templates, expression templates, and all sorts of other features available. Because Java lacks these basic building blocks, it has to resort to certain hacks, like making a distinction between value and address semantics for operator==, and allowing certain string-related classes to overload operator+, but not user-defined classes.

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.

Re:I doubt that Java will succeed.

[rmayes100]

You can always use Kaffe if it bothers you to have any Sun code in your Java VM. Lot's of choices with Java...

Re:I doubt that Java will succeed.

[rumil]

As of the .NET Framework v1.1, CIL does support generics. C# will not support them until the next release of the framework (rumored v2.0). You can still write straight IL to use generics or develop another language that supports them.

Re:I doubt that Java will succeed.

[Jonner]

Kaffe is great. So are GCJ and Classpath. However, none of them yet provides all of the libraries or functionality of the Sun based implementations, so you wouldn't necessarily be able to easily switch between Sun based (including the licensed ones from other vendors) and the Free Software ones.

I'm not saying that using Java is a bad idea; I've done it myself and may again in the future. I'm just pointing out that Sun does own it. It's not standardized and vendor independent in the same way that C, C++, Fortran, Common Lisp, or Ada is. Unless one is careful to only use the subset of the Java platform provided by the Free Software implementations, one will be somewhat dependent on Sun. However, I would trust Sun to steward their ownership a lot more than Microsoft.

Re:I doubt that Java will succeed.

[Golthar]

I supose most complete versions indeed use Sun's code, but how is this different than the .net crowd?

At least Sun lets others make implementations based on Java as where with .NET all you can mimic is the CLR and C#, not its class lib.

Kaffe and GCJ can be used if you don't depend on Sun's classlib too much

Re:I doubt that Java will succeed.

[Jonner]

I'd certainly go with one of the Sun based Java implementations over anything from Microsoft any day. The only way I'd consider writing C# or anything .Netish would be using Mono or DotGNU.

Yes, Kaffe and GCJ and Jikes and Classpath are great, but typical Java projects (even Free Software ones) do depend on the Java libraries. More to the point, how could you write any Java program without them? System.out.println is a library function, just like printf is in C. Projects like Kaffe and GCJ and Classpath implement the interfaces and functionality of the Sun libraries as much as possible, but they never quite keep up with the latest.

Re:I doubt that Java will succeed.

[tshieh]

Paul Prescod wrote:
> When Java came out I was an early adopter because sometimes somebody needs to move beyond what "everyone else is doing" (which was C/C++). I've since moved on to Python.

You were an early adopter of Java and have since moved on to Python?

Look at this posting from November 5, 1998:

http://groups.google.com/groups?q=pack+hasn%27t+ch osen+Python+three+years&hl=en&lr=&ie=UTF-8&oe=UTF- 8&selm=36427906.88E410EE%40monmouth.com&rnum=1

Posting by Ted Shieh, replying to assertions by Paul Prescod.

Paul Prescod wrote:
> the pack hasn't chosen Python yet. Three years from now, they
> will and you will and I may be on to something new.

Well, do you want to bet? How about this, we'll count how many times Python appears in the want ads vs. Java in the New York Times on the first Thursday in November of 2001?

I think you're wrong, and we won't have to wait until 2001 to verify the truth or falseness of "they will and you will." Just check the want ads in a national newspaper from time to time.

>It makes no sense to go to an *effect* of power when you can go directly
>to the source. Examine the languages, compare the lines of code it
>requires to do various jobs.

You should think a little more before you say "no sense." Here's a link worth visiting:
http://dir.yahoo.com/Computers_and_Internet/Progra mming_Languages/

I suppose that if I listen to you, I should ignore how widely each of these languages are used and simply evaluate them all at "the source." Of course, it's going to take me awhile to get through them all; I have to prioritize somehow. I guess I can start with the language called "ABC" (which I had never heard of before, but I guess I shouldn't let that be a factor).

It makes total sense that I would want to consider the more readily measured effect of power. One of effect of power is the popularity, and we can use the numbers next to the links as a kind of Web Popularity. It is biased in favor of Internet-oriented languages, sure, but these numbers are still mostly in line with what you'll see in the want ads (which is something of some importance). Java, C, C++, Perl, and VB all get high numbers and often appear in want ads. ABC, cT, and Cecil get 1's. And I wouldn't be surprised to see other languages not on this list. Should I give ABC and C equal attention? Sure, if I want to quit my job to work on my comparison full-time. Ultimately, most of code because that is what we get paid to do, and it makes a lot of sense that we should pay attention to whether we can get paid to do it now and and in the future.

It makes total sense.

Well, your 1998 prediction didn't come true by 2001, and it still hasn't come true. The "pack" hasn't chosen Python and neither have I. Are you going to admit you were wrong? My guess would be no. Maybe you'll argue that the "pack" actually has chosen Python. And I'll admit that Python has had a few successes, like BitTorrent. I'll even admit that the language has some nice characteristics. But, chosen by the "pack?" No.

I'd say that if the "pack" is starting to move onto something else, that something else is PHP.

In 1998, you mentioned that you may be on to something new by 2001. Well, on to something new yet, in 2003? Just asking - I'm not assuming what your answer will be.

Re:I doubt that Java will succeed.

[Golthar]

Indeed they don't, which is a real shame.
Fortunatly depending on what you are coding on, classpath and some extra libs may help you out.

For game programming, classpath with LWJGL (an Native opengl/al wrapper) will do just fine.
And as GCJ and Kaffe are 1.1 code compatible, it will compile fine too.

Its a shame Sun wouldn't take the extra step to open source their VM in an GPL or at least Open source fashion.
Perhaps in tandem with their JCP..

IMB help us out please ;-)

Re:I doubt that Java will succeed.

[the eric conspiracy]

I find your argument regarding orthogonality to be unconvincing.

Operator overloading is not present in Java because of a design decision based on a pragmatic observation that operator overloading is a feature that does considerable damage to the the readability of source code. This is not some theoretical argument. It is based on real-world experience. You may make an argument that this is 'not the way it should be' and languages should not be designed to accomadate bad programmers, but the fact is that it is indeed the way it is.

Leaving out a feature because it is more misused than used properly is a quite defensible design decision.

The fact is that all languages contain compromises to accomodate 'bad programmers'. In fact you could argue that any language other than machine language is a compromise that accomodates bad programmers.

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

[jericho4.0]

You are so flamebait.
A language is a language, none are 'perfect', and the only realistic benchmark of a language is the job to be done. Demanding a native compiler of Java negates the purpose and design of the language.
I have my favourites (go Python!), but languages have gone from machine code to assembly to C, and as great as C is, I hope we don't stop there.

All the features of C++

[Chromodromic]

With none of the performance.

Anyone still convinced that Java is neato needs another viewpoint; Paul Graham's is reasonable.

Anyone convinced that Sun is anything different than Microsoft, oh, except for being less successful, is delusional. How's that Java standard comin'?

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.

"What's that? Oh yes sir! I'll have those UML diagrams detailing the Bloggorgian-Rienmarch Reverse Upside-Down Cake Factory Singleton Dweeboid Pattern for you by next month! Then we can start coding!"

Re:All the features of C++

[Billly Gates]

Funny that the majority of programming jobs are Java oriented. Thats right C++ is now number2.

Businesses use Java because its cheaper and quicker to get results then C/C++ or Eiffel. Not because of the features of the language or speed but because of the built in libraries.

For speed C++ is there but higher maintanability and higher development costs outway its benefits for most server oriented tasks.

After all if your app uses sql heavily its not the VM/execution speed that is the bottleneck but latency from your lan and database. Studies as well as experience has confirmed this.

Re:All the features of C++

[Anonymous Coward]

Java is NOT slow. For numerical work I use IBM's JVM which has occasionally given me BETTER performance that optimised C++. Sun's 1.4 VM is typically 10-30% slower than C++ in most cases, I find.

Even a slight performance hit is well worth the safety and security of Java. Many products and companies were wrecked through the use of C++ as a development language in the late 80s and 90s, as a result of buffer overlow and pointer bugs.

Re:All the features of C++

[primus_sucks]

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

Re:All the features of C++

[Dr. Evil]

Fully.... there isn't a compiler which implements the language fully. Plenty of compilers do what they do correctly and clearly document their limitations and extensions.

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

Re:All the features of C++

[CommieBozo]

No, instead you like some stupid assembler getting between you and the machine. If it doesn't have a front panel, you're too far from the metal.

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:All the features of C++

[be-fan]

Almost all of those "features" you mentioned are actually in the Java *libraries* not in the language. C++ has libraries that do exactly the same thing, in pretty much the same way. The only thing it doesn't have is reflection (and consequently serialization) which really does need language-level support. I think its actually a good thing that C++ has a minimal standard library. A language is supposed to be composed of basic building blocks. Entangling all these libraries with the main specification is not clean design. It might be useful, for when having a library quick at hand is more important than choosing among competing libraries to find the best one, but I hardly think that's a good critereon for long term quality.

Re:All the features of C++

[rjh]

C++ is an abomination. 13 Years after the standard there STILL is not a single compiler that implements the language correctly.

As be-fan has (correctly) pointed out, it's only been five years since the standard was published. Several compiler suites are within epsilon of complete conformance (GCC 3.x, Intel 7.1), and last I heard the latest iteration of Kai C++ (they got bought out, but I forget by whom) even supports the export keyword. So yes, there are compilers which implement the language correctly, for reasonable definitions of "correctly".

Secondly--of course C++ is a mess. C++ was specifically designed to be a mess. It was designed to be a mess because the Committee knows the problem set is a mess. C++ has direct support for procedural, object-oriented and functional programming, when pretty much every other language out there tells you to pick one and stick with it[*]. C++ has generics and the Standard Template Library, which is so breathtakingly cool that it's hard to explain to people who don't understand it just why it's so great.

C++ is an abomination? Sure. Most of us C++ programmers will happily admit that it's an abomination. But if you're willing to make the (significant!) investment in learning C++, and learning it well, then it can pay enormous dividends.

My favorite two languages, incidentally, are C++ and the LISPs (Scheme particularly).

[*] Admittedly, you can make Scheme act like anything you like, but Scheme doesn't natively support OO. If you want OO, you've got to hang a bag on the side.

Re:All the features of C++

[drewness]

E.G. garbage collection. Java: + C++: -
There are garbage collectors for C++. For example, Hans Boehm has a Boehm-Demers-Weiser garbage collector on his page at HP. We wrote a Scheme (a very minimal subset of it actually) interpreter in one of my cis classes this quarter and the prof recomended that we could use something like that if we ever wanted to finish it. (As is it leaks memory like crazy. No deletes at all.) Look at the current users: gcj, gnu objective c, mzscheme, dotgnu. So, I don't think you can say C++ has no gc.
That being said, I'd take Python or Lisp over either of them any day.

Re:All the features of C++

[Dr. Evil]

None of them make that claim. They state their limitations clearly.

Databases claim to use SQL when they don't implement the whole language. Ditto for web browsers and HTML/CSS.

Re:All the features of C++

[toriver]

With none of the performance.

There are two kinds of performance in this world, and I am sure our customers like to get their software three months earlier better than the 0.2 ms faster response times the C++ app would net them.

Try running Java apps without the -Xint flag next time, so the JIT/Hotspot can do its job.

Anyone convinced that Sun is anything different than Microsoft, oh, except for being less successful, is delusional. How's that Java standard comin'?

I am sure the MANY members of the JCP - of which Sun is one - are just as good at guiding a standard as those ISO committees and whatnot. Ever seen a full implementation of SQL 92 anywhere? Hey, look, this Win32 program doesn't compile on an ISO-certified C++ compiler, call the, er, what authorities exactly?

Re:All the features of C++

[Chromodromic]

Well, firstly, it depends on the app, but C++ affords a helluvalot more than a 0.2ms improvement for most things. As for delivery times, it's what your shop is used to, and that's just the fact. I'm quite sure that a Java team would take an extra three months to deliver a C++ app, but a C++ team would be right at home. For me, I head a C++ team, and our clients are quite pleased. So far we have no requests Java.

Secondly, please don't try to say that Java isn't Sun's property, because it is. Yes, there are many members of the JCP, because Microsoft has many competitors. But this proprietary platform biz is about competition, not about excellence. If it were about language expressiveness and efficiency, then we'd all be using Common Lisp. If it were about the best OOP platform, then we'd all be using Smalltalk or Eiffel. The fact remains, however, very, very few of us are using those platforms, even though they're so great at what they do. Instead, we're using languages like C++, which significantly complicates C with OOP features, and Java and C# which tie the developer DOWN to one company's or, if it'll make you happy, one group of companies' way of working. Money, money, money. Java is crap, buddy. It's just another piece of software that some company desperately wants you to embrace. It's not altruism, it's not brilliance, it's not "the future".

Don't believe me? Let's have a little contest: Take two programmers sitting down at some keyboards, coding from scratch a given system requiring OOP (to be fair to Java, which is so freakin' imperative there should be a new category for it) and have one use Java and the other use Eiffel. Given equal ability, let's see who finishes first. Let's see who has fewer bugs. Let's see who's code is more readable.

Java is just some load of marketing crap that you've been taught to believe is great. Still don't believe me? Well, put your money where your mouth is. I've learned Java. Have you learned Eiffel?

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. :-)

Good

[tijsvd]

This is good. The Java language evolves and becomes more powerful. Note that these features can be implemented in the source-to-bytecode compiler, resulting in backwards compatible bytecode, that can be run on older JVMs.

A novel idea

[wigle]

Instead of trying of to convert C++ programmers to Java using trivial new syntax, why don't they add multi-level class inheritance?

public class ConvertedJavaSoftwareEngineer extends SloppySoftwareEngineer extends LazySoftwareEngineer extends SoftwareEngineer

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?

Re:Java is passe

[multi io]

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

So you're saying you don't use Java because Sun controls it, but you're using C#, whose APIs Microsoft controls -- which doesn't bother you because you could just use *Gtk#*? If you want to write Unix-only applications, it hardly makes sense to use C# at all.

Re:Java is passe

[amoe]

If you want to write Unix-only applications, it hardly makes sense to use C# at all.

Note that GTK+ works on Windows since 2.0, and looks nice given appropriate theming. I don't know about Mac OS X, but considering it's built on BSD, surely it's only a matter of time? (It's entirely possible that it's happened already, actually. If I wasn't so lazy I'd google it. ("But you are lazy, right?" "Aww, don't get me started...")

Re:Java is passe

[73939133]

So you're saying you don't use Java because Sun controls it,

I'm phasing out my use of Java not because "Sun controls it", but because Sun has done a poor job over the last few years with the control they have had.

If you want to write Unix-only applications, it hardly makes sense to use C# at all.

C# is easier to use and safer than C++, yet it gives me full access to native APIs. And it's standardized. Seems like a great application programming language for UNIX to me. Why doesn't that make sense to you?

Re:Java is passe

[Kunta Kinte]

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

I think you're argument is a little naive.

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

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

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

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

That's your biggest gripe with Java :)

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

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

Re:Java is passe

[steve_l]

Note that Java1.4.2 does something very slick with floating point stuff on PIII and P4: it offloads float arithmetic to the SSE ALU, and double arithmetic on the SSE2 unit (if present), which do speed up floating point a lot -I think more than ot the box FP generation from the MS C++ compilers (though the intel vtune and codeplay vectorizing C++ compilers have an edge). So they are not neglecting the old FP performance. This increases its value for scientific work, like grid based stuff.

That doesnt affect the validity of any of your other arguments, however.

Steve

(who as an Axis developer works on one of those bloated web service implementations)

Re:Java is passe

[73939133]

Gtk+, wxWindows, would only be a small subset of the .NET libraries or JAVA core libraries.

That's fine. There are plenty of other libraries. Mono programmers can use the best of C, C++, C#, .NET, Fortran, and Java (!) libraries in their programming because C# and Mono interoperate easily with all of them.

It's also very hard to get an entire team of developers on the same page concerning all these issues, so having them all in a single framework is very cost effect.

You are making the same mistake that people who bet on Microsoft made, you are just picking a different wannabe monopolist.

Because this was the only thing that prevented Microsoft from trashing Java last time they tried,

Java needed a good trashing because Sun just wasn't doing their job. And the changes Sun has made to Java in 1.5 pretty much confirm Microsoft's complaints. The fact that Microsoft is the evil empire doesn't mean that they are always wrong.

Browse that site a bit if you would like to know what true community development/standardization is ( ie. compared to the patent/ip riddled shared source nonsense ).

Java is covered by numerous Sun patents, and unlike C#/.NET, those patents cover core aspects of the runtime. Sun has not dedicated those patents to the public domain, but they are using them to control who can and cannot implement Java. Furthermore, Sun has successfully used the same legal strategy as SCO--making contamination claims. As I was saying: I don't know whether Microsoft will cause IP problems or whether they will play fair, but I already know Sun doesn't.

As for the JCP, I consider it an underhanded attempt by Sun to get free development done for their proprietary platform and to control what would otherwise be open source efforts entirely outside of Sun's control. In fact, the JCP may well preclude APIs developed under the JCP to be used in Mono or .NET, while giving Sun free use of them; why should people volunteer for that sort of thing?

Overall, I'd love to see Microsoft's monopoly destroyed, but not at the cost of handing the keys to open source software to Sun, which would be the result if Java became widely used on Linux. And Java is too poor technically anyway to play any significant role on Linux.

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.

Re:Generics

[Anonymous Coward]

Did you actually understand the article you linked to? It specifically says that inheriting from a common base class (which is Java's "solution" to the same problem) is not a good replacement.

It's criticism of templates as they are in C++, not criticism of generics in general.

Using dynamic OO style containers in a statically typed language is one of the biggest mistakes of the original Java design.

Re:Generics

[be-fan]

Systems programming is still done in C; some embedded work uses tiny subsets of C++ (which have often been described as "C with classes")
>>>>>>>>>>>>>>>>>>>>&gt ;
Right now, I'm doing a C++ kernel with exception handling, smart pointers, the STL, the whole shebang. All I had to do was write a few hundred lines of runtime support code. Try doing that with Java. FYI, the OS X I/O manager is C++, and many NT kernel drivers these days are written in C++.

If you can afford "smart pointers" and reference counting,
>>>>>>>
Reference counting smart pointers boil down to an overhead of one word per pointer, and an indirect increment for object creationyou should be using a higher-level language that clarifies.

you should be using a higher-level language that clarifies
>>>>>>>>>>
Java isn't a high level language. Both are mid-level. Properly written Java code just looks a lot like properly written C++ code. A real high level language is something like Python, and maybe Smalltalk and some of the functional languages.

rules out entire categories of catastrophic stupid mistakes.
>>>>>>>>>
Using proper practices can do this in C++. It is not a stupid mistake if someone uses a C-style array, or a raw pointer, instead of a std::vector or smart pointer. That's a concious decision on the part of the developer. Once you decide to use the unsafe features of C++, the language assumes that you're doing so for a reason, and you have no reason to bitch if you get bitten in the ass. Your points would be valid if you *had* to use unsafe features to get real code written, but I've seen a lot of well designed code that doesn't use these unsafe features, so that arguement holds no water.

It boils down to this: There is very little (even in the way of safety features) that C++ can't do that Java can. On the other hand, there is a lot of stuff that C++ can do that Java cannot. If you're not going to program according to best practices, then you're screwed no matter what language you use.

Re:Generics

[vague]

The problem isn't that C++ exists, the problem is that in _most_ places where it is used it shouldn't be. Used by people who aren't gurus for projects where a higher level language would serve both them and the project much better. Fewer bugs and a much faster development cycle.

Sometimes I think it goes like this:
Bad programmer creates slow code in HLL, so we tell him to use C(++) instead so that he regain some of it...

C++ is a complex beast of a language where features interact in extremly subtle and often pathological ways. You might not pay for the features you don't use in performance, but you often end up doing so in cognitive load.

Re:Generics

[The Bungi]

Did you actually understand the article you linked to?

Yes, I did. Did you?

Re:Generics

[The Bungi]

"suxx"? ROFL!

Re:Generics

[dubl-u]

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

I can't say for C#, but I'd love them for Java.

Contrast Java's arrays with it collections. Arrays are strongly typed; if you try to put something other than a String into a String array, you'll get an immediate failure. With a List or a Set, though, even if the collection is only supposed to contain Strings, you can put any damned thing you want in.

There are two problems with this. One is that using the collections, your code is littered with casts. In the case where everybody's following the contracts for an object, those casts are useless. And when somebody violates a contract by putting the wrong kind of object in a List, the failure appears later, and possibly much later, making damned hard to find where the bug really is.

That's exactly the sort of mindless but anal bookkeeping that computers do well and humans do poorly. Good languages (which I hope Java might one day be) take burdens like that off of the programmers, leaving them more time to think about the important bits.

Re:Generics

[be-fan]

Are you really using RTTI and exceptions? Most systems guys avoid them out of some sort strange reluctance to spend any cycles in code they didn't write (even when it came with the compiler).
>>>>>>>>>>
Since GCC is open source, I had access to all the RTTI and exception handling code. It's comparatively small, and very efficient. Basically, exceptions have no overhead unless you actually throw one (which is rare), typeid is O(1), and dynamic_cast is O(n) for small n.

Any nontrivially interacting objects are going to have a cycle, with none being freed.
>>>>>>>>>>>>
Not if you use a ref-counting pointer only for managed allocations rather than weak references. Simple weak linkages is why references exist.

As for a copying collector --- it's only an option if you can afford non-deterministic timings for collections to happen. In a kernel, that kills latency. If you're not under latency constraints, you can always use one of the many garbage collectors for C++.

Re:Generics

[EddieSam]

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.

As someone who has fairly recently joined a team that's maintaining a 400KLOC system (Java, incidentally), I'm more interested in protecting myself from previous programmers on the team than protecting myself from myself. I'd like to think that those who follow don't need protection from me, but their opinions may be different. In any case, using a language that doesn't allow any of the previous programmers to shoot me in the foot with a bad pointer is a Good Thing (tm). I dont' want to have to waste time chasing down obscure nasal demons.

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

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

[ausgnome]

After seeing many similar posts to this java and .net are so slow , use C++ for speed I figure that if it was realy about speed they'd use assembler, but mostly i think its just that OO makes the weekend script kiddies on here have to think to much. Java for programmers that are knowledgeable .net for programmers that want MS to do it for them

Good ol days

[ausgnome]

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

Re:Good ol days

[stud9920]

They learnt us stinking Modula 2

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. :)

Mini Ask Slashdot

[MyHair]

I expect Java will continue to survive in some niches (most notably, bloated web services implementations)

I was about to install Java + JBoss + Tomcat + Apache httpd (and maybe Apache Cocoon) and see what I can do with it. I'm not a seasoned developer (just had a few classes a few years ago), so I'm trying to figure out the best way to offer a scalable web platfrom mainly for database entry and reporting without much custom programming. I'm also interested in application services, but that's more into the future.

If not Java, then what?

And what tools are currently available? (Preferably open source of course, but commercial options considered.)

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

Re:Mini Ask Slashdot

[Jetifi]

I don't know about JBoss, but Tomcat 4.1 and upwards are installed using the NullSoft installer. Very easy, no complications.

The 3-series was a right PIA though. Glad to see the back of that.

Re:Mini Ask Slashdot

[73939133]

Well, first of all, saying that Java (J2EE, really) gives you "bloated web services" isn't the same as saying "don't ever use it". Bloated, complex systems sometimes are the best available solution, and they are great for making money as a consultant or programmer.

But, in any case, there are lots of alternatives. I suspect that for most applications, you are probably better off using PHP, mod_perl, mod_python, or maybe Zope.

Re:Mini Ask Slashdot

[Billly Gates]

Install netbeans and or eclipse. They will install Tomcat for you.

Tomcat has improved since the merge of the JServ project. I agree it was a nightmare 2 years ago but the situation has improved.

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.

Re:Mini Ask Slashdot

[primus_sucks]

Sounds difficult, I'd rather just drag/drop to my desktop then just have it run automatically. Maybe have some wizard pop up to configure the thing.

Re:Mini Ask Slashdot

[multi io]

Sounds difficult, I'd rather just drag/drop to my desktop then just have it run automatically. Maybe have some wizard pop up to configure the thing.

An opaque "setup.exe" that just uncontrollably dumps a pile of binary litter into various places of the filesystem, along with "updating" the registry mess in some undocumented ways, has nothing to do with simplicity.

For a sane administrator, simplicity means manageability and controllability, not minimum amount of manual steps to do in order for the installation process to complete.

Re:Mini Ask Slashdot

[primus_sucks]

I know, sorry I was just being an ass. Really though for user applications it ain't such a bad idea. Lots of normal users have trouble with unzipping files and typing in a command.

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.

foreach loops?

[BillsPetMonkey]

What you mean like in C# ?

The tail is wagging the dog here.

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:Dylan

[oodl]

You are missing the bigger picture... Sun introduced a totally new programming language: Java. They were not constrained by backwards compatibility, and they had a chance to do it right. It is true they suceeded rather admirally in the marketing aspect, but if you ask me, they failed in the technical aspects of the language. They ignored the language research in academia that had gone on in that period and before, and spat out a rather intellectually-unsatisfying language.

The basic premise of Java was to introduce a more simple object-oriented language. But it is growing tremendously complicated because it's internal lack of consistency.

I'm sorry, but is this important?

[Anonymous Coward]

Java changes every couple of months. No one can decide on a "standard," even though Java is supposed to be a STANDARD. An advancement in Java in one camp means nothing anywhere else, but in that camp. True, an advancement in Java is news, but for who? That camp?

Yah, mod me down as a troll. That doesn't mean what I say isn't true.

Re:I'm sorry, but is this important?

[afidel]

If by every couple of months you mean the fact that J2SE 1.4 has been the standard since Q4 2001 then sure it changes every couple of months =) Seriously this is the first big move in the language in a year and a half, with all the other inane stuff Slashdot covers I think it deserves a headline.

Re:I'm sorry, but is this important?

[iapetus]

No. It's the lack of truth in what you say that means what you say isn't true. Perhaps you could clear up the details of these mythical 'Java camps' as well - as far as I know there's Sun's Java and... well, nothing else. Unless you want to include Microsoft's deliberate attempt to fragment the language.

Re:I'm sorry, but is this important?

[dubl-u]

Java changes every couple of months

Sorry, but what are you talking about?

I do a big chunk of my development in Java, and as far as I'm concerned, the pace of improvement in the language is glacial. If I recall correctly, Java 1.3 came out in Q1 2000; Java 1.4 came out in Q1 2002. 1.5 isn't due out until the the first half of 2004.

At JavaOne 2000, there was a session on the Collections classes that was overflowing, and it seemed obvious then that generics were needed, and that it couldn't be done well without changes in core Java. I find it mainly disappointing that it takes 4+ years to go from "obviously needed" to "available".

About the only thing I've seen in the Java world that changes quickly is the open-source projects that provide useful stuff. My favorite example is Hibernate, a good object/relational mapping layer.

Re:Interested in learning more about these generic

[ausgnome]

J2EE is the best chance against .net , as long as .net stays on the desktop and out of the enterprise its fine with me. While java and c# look similar its when you go to the distributed environment the main differences occur.

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

[spongman]

I don't think it really has anything to do with what the language "needs". It has more to do with what the programmers want. I mean, if we didn't want these features that made programming easier, we'd all be coding in rule 110.

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.

Loops and iterators.

[Dan-DAFC]

Every Java programmer instantly recognizes the head of an "iterator for-loop". It's an idiom.

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 always use a while loop.

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. ;)

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

Re:Teach the kids Scheme or Smalltalk.

[Tablizer]

Those two languages are far simpler

But since the corporate world tends to reject dynamic/interpreted languages for some reason (a long discussion topic in itself), these probably won't be widely accepted at teaching institutions. It is believed, for good or bad, that it is best to teach something that is being hired for.

For brain-expanding power alone, teach them LISP. It is, or can be, multi-paradigm for one.

Re:Teach the kids Scheme or Smalltalk.

[brlewis]

these probably won't be widely accepted at teaching institutions

Au contraire. Hundreds of high schools and universities have decided to teach Scheme. It's being taught at MIT right now!

Re:Teach the kids Scheme or Smalltalk.

[zerofunk]

Scheme is used at Georgia Tech for the CS intro class, which most undergrads are required to take (except a few majors). Squeak is used in a later CS course (Objects and Design). I think most pretty much all non-CS people hate Scheme and some CS people do as well. From what I've heard I don't think anyone likes Squeak, mainly because of the environment you're force into working in (I'm taking the class this fall, so I don't know much firsthand about it).

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

[myster0n]

Firstly, as someone else already pointed out, javascript has nothing to do with java.
Secondly, if you want a (as you say) "powerful multi-purpose high-level [scripting] language like Python" in java, why not use Jython? (note : I don't know python, I don't know jython, just making a suggestion)

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:The problem: Improving programmer productivity

[krumms]

BeanShell is brilliant because, essentially, it's dynamically typed Java. Further, to my knowledge, you don't need to write integration code like you do in other languages (think exporting C functions to Lua - BeanShell only requires an 'import' statement to import any Java package or class in the classpath). It's very cool :) I've been using it for user interface prototyping, such that I can change my user interface without a recompile. Which is, y'know, nice :)

Re:The problem: Improving programmer productivity

[MochaMan]

Modding This Comment Will Not Alter Its Accuracy Nor Its Insightfulness

Or its sig's grammar, for that matter... that should be an "or" not a "nor", unless you switch the "not" to a "neither".

Still... I'm no Grammar Nazi.

Re:The problem: Improving programmer productivity

[tshak]

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.


I've been looking over some old Perl of mine, and I'm not convinced that a C# equivilant would be anywhere near "5-10" times larger... or noticeably larger at all.

Also, less code does not always mean less maintenance. After coding in dynamically typed languages professionally for over 4 years (Perl, Cold Fusion, PHP, ASP/VBScript), I'm very relieved to be working on applications in a statically typed, compiled environment (scripts always have their place, of course). Compiling is so stupid-easy and quick in Java and C# that it really doesn't add any measurable time to the development process (it takes 10 sec to compile 25Klines of code on minimal hardware in VS.NET). Plus, compiling can help you find bugs before you test in runtime, so for larger applications it actually saves you time. Static typing add a small (very small) amount of work on the dev's side (casting, parsing, and type checking), but it makes the code much easier to read because you understand what's going on, and helps prevent bugs due to unknown datatypes. Remember, code is read much more than it is written. That's also why Apple, MS, and others opt for rediculously long type names in their API's (eg: FormsAuthentication.RedirectFromLoginPage). When you read it, you know exactly what it does, and because it's strongly typed, the IDE can tell you what to pass in, and what it returns. No questions asked.

Personally, I would've never written SlashCode in Perl. I think it's a mess (yes, I have looked at SlashCode before), and it would be much more elegant if written in Java or C#. Again, I also highly doubt that Perl would be more productive, and result in less code than it's Java or C# equivilent. But hey, that's why we have choice - you use your language, I'll use mine!

Re:The problem: Improving programmer productivity

[fmclain]

"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). "

There is a kick-ass scripting language for Java, it's just not produced by Sun. Check out BeanShell. It makes a wonderful embedded scripting language as well as a standalone toy. I've used it in comercial applications and to play with adding new features on the fly. You can download BeanShell here.

Re:The problem: Improving programmer productivity

[MSTCrow5429]

Both seem to work. I'm not sure why, guessing it has something to do with modding being a verb. I ran both through a grammar checker, comes out fine.

Re:The problem: Improving programmer productivity

[p2sam]

No, you are wrong.

Quoting from the OP:
"Why doesn't Sun take a hint and phase JavaScript out in favor of a powerful multi-purpose high-level language like Python [python.org] or Ruby [ruby-lang.org]? That'll put them miles ahead of Microsoft in terms of increasing programmers' productivity... and programmers' quality of life."

The OP clearly suggested that Sun was officially endoring JavaScript, and thinks that Sun should endorse Python instead. The OP is clearly mistaken, as JavaScript has very little to do with Java, and even less to do with Sun.

If the OP knew anything about Java or Python, he should have mentioned Jython (www.jython.org). In fact, one of Jython's primary goal is to be embedded inside Java applications, and has became the de-facto standard for scripting on the Java platform.

Problems with templates

[rauhest]

If you write a template method, you don't know what kinds of objects you are really working with. It is not always bad, but one of the problems with that is that IDEs will not be able to assist you with code completion and misc. refactorings.

The other problem with templates is that (at least with the C++ implementation) to use them without getting Cobol fingers, one has to write lots of typedefs, and those typedefs do hide what's underneath.

The main advantage of templates is the additional compile-time type checking, which arguably is not really needed, if you write tests for the code.

(C++ also has operator overloading, which lets use templates (conveniently) to implement lamda expressions. But Java doesn't have operator overloading, so this bonus doesn't apply here.)

Re:Problems with templates

[CableModemSniper]

!!! Lambda expressions are the coolest thing I've ever seen in my life. Well no not really. But, whoa. Urge to learn some functional language rising...

Re:Problems with templates

[top_down]

The other problem with templates is that (at least with the C++ implementation) to use them without getting Cobol fingers.

Are you really suggesting that code that makes heavy use of templates is verbose? Have you ever programmed using generic libraries? FYI they tend to be very powerfull (little code == lots of action). C is for fast typers, (modern!) C++ is not, Java is somewhere in between.

The main advantage of templates is the additional compile-time type checking, which arguably is not really needed, if you write tests for the code.

No, they are mostly about speed and reuse of code.

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

[KingRamsis]

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

Fork?

[bj8rn]

Maybe it's time for some free software JVM to take the 'reformed' (protestant?), less bloated path, while remaining compliant with Sun's Java (with all the bells, whistles and shiny bits)?

(Click 'Reply to This' to comment about no/no open standards etc)

---

Re:Fork?

[Jan Venema]

staying compiant misses the point. A language is spoken en read. Soon you may have to read stuff like this:
public static <T> void fill(List<-T> list, T o) { ... }
public static <T> void copy(List<-T> dest, List<+T> src) { ... }
That you run a different JVM does not help you at all.

Re:Fork?

[Ed Avis]

AFAIK all the changes in Java 1.5 are in the compiler - the bytecode has the same format as before. (At least this is the impression I get from the Slashdot comments.) So it's not a question of whether to change the JVM.

What's interesting is that many of the new features were already available in other languages that compile down to JVM bytecode, such as Generic Java and Nice. But people seem reluctant to use new features until they're in an officially blessed Sun release, even if the generated code is 100% Java-compatible.

Re:Fork?

[bj8rn]

I was still dizzy in the morning when I posted, so what I posted wasn't exactly what I meant. What I was thinking was, what if there were two branches of Java - one the blessed (catholic) Sun release, the other a reformed back-to-the-roots-where-all-was-simple-and-no-bloa t variant; both of them compliant to a standard (the weakest link in the chain, I guess), so that 'reformed' code would compile with a 'catholic' compiler (and run on a catholic VM). The "use an older version" argument doesn't apply, as the older versions of Java are quite light in weight, too, but they have many things that are deprecated or gone in newer versions.

What I also had in mind was an analogy from history: Catholic Christianity was a spin-off of Judaism, supposed to be a cleaner version. All the Protestant churches sprung from the idea of cleaning up the Catholic church. The same scheme applied to modern world could be C++ -> Java -> ?. Plus the religious wars...

---

Re:Fork?

[Ed Avis]

I think that in practice it is going the other way - the various free languages which compile to Java bytecode are _more_ featureful than Sun's efforts, not less.

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

[Lennie]

So does python

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

The irony of your sig

[Trinition]

"Progress doesn't come from early risers - progress is made by lazy men looking for easier ways to do things.(R.Heinlein)"

A lot of the features added to 1.5 are syntactic sugar for laziness. I guess that means this is true progress, according to your signature.

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.

Shared-VM conspiracy

[Trinition]

While reading some Java discussion forums, I came across a thread with someone reporting a new comment on the shared VM bug in bug parade. The comment indicated that Sun wasn ot going to plan on having shared-VM in the 1.5 release of Java.

This immediately sparked a campaign of, well... complaining. But it seems to have worked. In a matter of hours, the comment had disappeared.

Now, I still have no positive evidence that Sun WILL put shared-VM into 1.5, but at least subtle, but solid evidence that they definitely would NOT has been retacted.

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

[Jugalator]

haha, sure, you've got a point there :-)

But I still think one should carefully evaluate what kind of "programmer need" should be supported in the core language.

Sure, it is definitely more useful to program in an object-oriented language than to program a Universal Cellular Automaton, and that's a reason to why object-oriented languages exists. But is it really necessary to add stuff like foreach loops to the language? Or is that just a keyword most of the Java programmers out there could've been without?

I'm not saying that programming languages shouldn't have evolved from the previous millenium, but that it might not be such a good idea to add unnecessary complexity to the language.

Re:Interested in learning more about these generic

[Trinition]

"...Java has finally caught up with where C++ was better than a decade ago."

Being interested in the generics from my C++ days, I've been readsing discussion forums covering this topic in detail. One of the prevalent themes is that Java 1.5 generics ARE NOT C++ templates. Can someone confirm the differences?

Even when I did C++, I rarely had to use templates. In fact, when I did use them it was just for fun (implementing simple collections that were already available in STL). Still, I don't remember syntax for handlign covariance, contravariance, invariance, etc. Was it there and I didn't see it, or are Java 1.5's generics truly different form C++ templates.

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:Java Vs .net

[73939133]

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.

It is far from clear that Microsoft has any control over who implements .NET. Furthermore, the Mono project is only in part about implementing .NET; right now, it looks like Mono is going to produce lots of Linux-native APIs for C#.

And you are assuming that Sun is any better. But Sun has patents on many aspects of Java, including key parts of the byte code.

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.

That is, until Sun's business starts falling apart and they become as litigious as SCO. In fact, Sun already has pulled an SCO and threatened companies and employees over their involvement in open source Java projects after having looked at Sun's source code.

I honestly don't know what legal stupidity Microsoft is going to commit. But I don't have to guess about Sun: Sun has already proven that they are going to break promises, that they are going to keep Java proprietary through patents, and that they are going to interfere with open source efforts when it looks like that they may cut into their businesses (look at the recent JBoss tiff).

So, if you are really worried about lawsuits and all that, stay away from either C# or Java. But between the two, legally, C# seems less risky than Java.

Re:Java Vs .net

[73939133]

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

Even if Mono was found to infringe on Microsoft's rights, all that would do is affect the Mono implementation (and it would be easy to work around). It wouldn't affect anything else on the Linux machine.

Of course, Sun at this point looks far more likely to "pull an SCO" than Microsoft: unlike Microsoft, Sun is in financial troubles, they have lots of patents on Java, they have already threatened programmers over having looked at Sun's source code and then participating in other projects, and Sun has pulled out of any effort that would create an open, unencumbered Java standard.

Mono may not be completely legally risk free, but if you are worried about anybody "pulling an SCO", be worried about Sun first.

Re:Java Vs .net

[ausgnome]

So, if you are really worried about lawsuits and all that, stay away from either C# or Java. But between the two, legally, C# seems less risky than Java.
The major difference is that A lot of major players have backed java. If sun went the sco way how long do you think it would take before IBM,HP,Oracle etc got together and bought out sun. M# on the otherhand has no playmates they can do what they want when they want

Re:Java Vs .net

[JanusFury]

First off, I use both Java and .NET regularly for application development.

Anyway, all these evil things you say that MS is going to do with .NET... how exactly is Sun unable to do the same things with Java? Both platforms are owned by their creators (Java/Sun, .NET/MS)... In many ways, .NET is actually more open because MS decided to make parts of it standards. How could MS possibly hope to 'relegate mono to the sidewalk' when it's already a usable multiplatform environment for building applications, built on existing standards? Even if MS somehow makes all other .NET implementations useless for MS's .NET software, Mono will still be useful on its own.

Please, keep telling me how I've 'sold my sole to the devil'. Would you also mind telling me how you got modded up to +5?

Re:Java Vs .net

[f00zbll]

Both platforms are owned by their creators (Java/Sun, .NET/MS)

You're absolutely right. Both platforms are owned by its creator. neither is perfect or horribly broken. On the other hand, there are major differences in each companies approach. Sun has been accused of moving too slow and MS has been accused of moving too fast. both keep repeating the same mistakes, not because of the programmers. It's because of the business guys, who can't make up their minds.

.NET definitely has an edge in client apps for windows, but not in the server world. People should just open their eyes and see the answer to all this is to have real public standards and encourage all companies to use public standards. this way, you can write a client in C# for windows and your server app in C++/Java/C. This way the chances of things integrating nicely is higher than if either company makes all the decisions. When ever one company makes all the decisions, they tend to do what they want and not what users want. the wisdom that having one company control everything insures everything works correctly isn't true in practice.

take AWT for example. when it first came out, it was slow, but now it's much faster and works well. Not blazing or faster than C++. on the .NET side, take IIS for example. IIS is a nice webserver that allows you to build dynamic pages easily, but it scales very poorly for heavy weight web apps. If you need to do anything complex or make sync database calls, it becomes a huge pain to scale. In the past, I was given the task of building a real-time monitoring tool for IIS and it was a total pain. building the equivalent real-time monitor tool in a java container like JBoss is several orders of magnitude easier. I know, the comparison is unfair (apples to oranges), but that's the thing. Stupid CTO's and execs say "IIS only" without understanding the full depth of the problem. Or an exec will say "all EJB" for a simple dynamic website.

the true evil is business people not listening and despising the IT department. Rather than see the IT staff as equals and a vital part of the company, many execs think of it as "IT is something I have to put up with." Programmers typically aren't great at soft skills, so guys in marketing are seen as more important because they can smooze. In reality, they are all equal parts and have to cooperate with each other. <rant/>

Re:Java Vs .net

[sheldon]

"To be quite honest, I dont care at all if .net is better than Java. The point is that .net is controlled by Microsoft,"

I prefer making decisions based on technical advantage, not religious fanatacism.

Re:Sun deserves all that will happen

[Billly Gates]

Look here. Sun is certainly not setting still and will release a vb like rad ide to generate macro code to Java very soon.

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:Sounds like what C# has that makes it better...

[cookd]

Whoops -- forgot to mention structs. Yeah, again, they provide additional stuff that isn't strictly needed. And it can confuse people who don't know when to use a class and when to use a struct. But there really is a clear line between appropriate uses of class (stored on heap) and struct (stored on stack unless boxed). For those who understand the difference, it is really nice to have both.

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.

Re:More Wrong Choices

[Bodrius]

About that crying need:

Does anyone know exactly why on heaven and earth Java overloads the '+' sign for a String and NOT for any of the number wrappers?

Was there a particular reason, did someone get really drunk and lose a bet, or was it just because?

Re:More Wrong Choices

[dubl-u]

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?

I'd guess because Java is focused on the business software market. That's not to knock scientific apps, but Sun's a for-profit company, and it looks like they've decided that enterprise software is the market for Java, and so everybody else takes a back seat.

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

[Lennie]

I'm not talking about JIT, I'm talking about the standard Python package, it caches the compiled bytecode.

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

[the eric conspiracy]

another run-time-environemnt, each of which is subtly incompatible with the rest.

End result was a switch back to C++

This is hilarious. No two C++ compilers handle the language the same way, and you are complaining about subtle differences in JVMs? Give me a break.

The fact of the matter is that C++ is THE abomination of all languages in wide use - tries to pretend that it's OOP, yet is almost but not quite compatable with legacy C. It is so badly designed that many people now believe that it is NOT POSSIBLE to write a compiler that is 100% compliant with the specification.

C++ ? Gag. Vomit.

C++ is the LAST language I would recommend to anyone. A nightmare of design. Compilers that just do not work. A standard that PROVES the maxim that a camel is what you get when you ask a committee to design a horse.

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:Why a Large Bank Junked Java

[mgkimsal2]

There's probably some C and VB and other technologies being used there too. Just because it's being used there doesn't mean it's necessarily a good fit. Microsoft uses that line - "look at all the places VB is being used!" - but you constantly hear about delays, bugs, incompatibilities about VB. So they're using Java at the US State Department. Big deal. Was it the best choice? Was it even a good choice? Will they stick with it? If so, is it because it's a good choice, or just because switching to something else is too hard? Honestly, we'll never know all the factors there, and pointing to someone using it without more info on 'why' it's used and 'how well' it works is not very helpful.

Re:Why a Large Bank Junked Java

[anonymous cupboard]

The main execution environment was AIX and Solaris. The compilers were Xlc and gpp respectively.They were using STL and a little Rogue Wave, otherwise most of the classes were home built.

The thing is that they tried Java, and they were dissappointed, even with top-level help, it didn't perform. They went back to C++. The high-performance front-ends, they also coded in C++ and they were users of QT.

Re:Why a Large Bank Junked Java

[anonymous cupboard]

Here we are talking about apps with a high transaction load and the risk of severely upset customers when it can't hack it and the loss of $$$$.

Java works, but my feeling is they should stop playing with the language and try t consolidate it. C++ sufferred a long time because of its rapid growth in the early nineties, but eventually it settled down. There are things that Java is good at, but getting the last ounce of performance isn't one of them. I am also sick of the deployment issues of apps requiring individually tweeked VMs. That is one issue which really needs sorting.

Re:Why a Large Bank Junked Java

[paulfwilliams]

Amen. Do you think applications that require high performance can not be written in Java? Think again. Alibre Design is a CAD application written in Java, and it's plenty fast.

The only performance problem you have with a Java application is a longer time required to do something the first time-- the JIT. Any other bottlenecks are somewhere in application code.

Re:Why a Large Bank Junked Java

[f00zbll]

I don't doubt the reasons for the switch back were for good, but since when has high performance multi-processor applications been easy to build? Performing sync across processors isn't something to do lightly and really should be written to meet the specific needs of the project. In this regard, I would doubt that C# can do any better, since it is built on COM+ components. If anything, MS has considerably less experience building high performance applications for multi-processor systems. Most of the Unix vendors have 5-20 years more experience with multi-processor hardware that is specifically designed for enterprise apps.

Researchers argue over the best way to tackle these problems and there doesn't seem to be a clear set of rules about how these kinds of systems should be built and maintained. It's going to take another 20-30 years before the industry as a whole (programmers, manufacturers, software companies) gets a solid grasp of building high performance parallel and distributed applications. that's not to say we don't know how, but that it is still very complicated and requires a ton of expertise. I'm no expert on multi-processor applications and hardware, but performing a sync on symmetric multi-processor hardware vs AIX is totally different. High end unix boxes use switch fabric architecture to share physical memory, where as the typical multi-cpu PC uses shared bus and must take turns accessing the memory.

Let's face the facts, C++ is more mature and has had the benefit of years of hardcore development. Java is still a young language and C# is still an infant. Each language has it's strengths and weaknesses. More things change, more they stay the same. Programmers should just realize the constant cycle of new languages is all a marketing ploy and isn't really about making software development easier or more stable. If anything, it makes it less stable because it forces people to learn whole new sets of problems and repeat the same mistakes in a different language. Using the right tool to solve the right problem should be the goal of projects, but trying to convince execs is nearly impossible

Re:Why a Large Bank Junked Java

[anonymous cupboard]

An interpreter will always have problems competing with native code. Also the machine model used by the VM tends to be somewhat simplistic compared to the real hardware model. Your mention of COM+ is not so relevant as it is just one of many ways of breaking up and combing apps.

Researchers argue over the best way to tackle these problems and there doesn't seem to be a clear set of rules about how these kinds of systems should be built and maintained.

However, the manufacturers have been shipping multiple processors for a long time now, and they can work quite nicely -- suprisingly enough even together with older languages.

C++ is more mature and has had the benefit of years of hardcore development. Java is still a young language and C# is still an infant.

When Java was created, wasn't it supposed to be a tool for easing the deployment of front-end applications? Why is so much effort now being spent on running it on the backend, which is typically much more resource bound? However, running Java on a backend is a good way of selling more expensive hardware. It uses a lot of resources on the front-end too, but generally, the resources there are cheaper.

Re:Why a Large Bank Junked Java

[f00zbll]

However, the manufacturers have been shipping multiple processors for a long time now, and they can work quite nicely -- suprisingly enough even together with older languages.

absolutely true! but trying to port an application from VMS to AIX isn't quite that easy right :) There's always room for improvement and standardization of how certain classes of common problems are handled in software and hardware.

Re:Why a Large Bank Junked Java

[anonymous cupboard]

Actually VMS to AIX works because AIX supports asynch I/O and threads quite well. I have done a lot of VMS to AIX work and VMS has been fully Posix compliant for some time (if you wanted it to be). Motif apps went very easily between the two systems as Motif scheduled its own I/O and threads anyway.

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?!

Re:ENUMs, yay!

[NoOneInParticular]

What am I going to bitch about now?!

Maybe complain about the fact that even if you actually got off your ass instead of complaining all the time, there's no way you can do anything about how Java evolves other than complain about it.

Re:ENUMs, yay!

[mekkab]

Hey! I can do that!

But seriously, I [heart] enums, they make for some very readable code (especially when representing 'states' of a state machine), and the only way you could do them before was to use static global int definitions.

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:Java is pragmatism over principals

[drunkenbatman]

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. Ah, well I write for java on the mac... which means due to Apple's timelines for java releases I won't have to worry about looking into 1.5 until 2006 at the earliest... and that'll probably be a developer preview.

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 ;)

A bit of experience

[mindriot]

We used the Pizza generic Java extension about three years ago, in my second-semester CompSci class (The Professor was somehow affiliated to the Pizza project). I must say that it's really something Java was lacking, and their spec is very clean and statically typesafe (important feature of Java imo). Besides, compared to C++, it's free of unnecessary clutter (C++ templates are just a bit too complex and powerful). But using Vector instead of a Vector of Objects is a pretty neat feature that I could get used to. Back then we were told that the Generic extension was on track for Java 1.3. I really wonder what kept them -- it should've been there back then, and it would've ended up to be more of a success, I suppose.

Re:A bit of experience

[mindriot]

Oh, and actually that old CompSci course web page is still up, amazing :-) Down at the bottom of the page, you'll find a link to the GJ API Documentation (from back then). The GJ people had the Stack, Vector, Hashtable, and Dictionary classes rewritten with generics.

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

[Avumede]

Bad memory design? Wrong. Java's memory management is much better than C's, because Java can move objects in memory around at will, but heap data in C is fixed because of pointers.

Also wrong is the statement that Python and Perl are faster. Every metric I've ever seen shows that Python and Perl are significantly slower than Java. Python especially. If you have proof of your statements, though, I'd love to hear it.

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.

no mention of gcc?

[denny_d]

Does anyone know if the new java will be using a higher v. of gcc? Right now, if I'm not mistaken, sun is using gcc 2.95. For the moz folks out there it means that java applets and moz don't get along (moz is using gcc3.2x). And what of the talk a year ago? two years ago? That sun would Open source java? Nothing came of that has it?

Shouldn't they make 1.4 work first?

[Lawrence_Bird]

Please understand, this is from the perspective of a *user* of java based applications. In my setup, (dual AthlonMP,Ti4600) I can't use 1.4 because the primary application slows down to the point of being unusable. This does not happen with 1.3, and it runs best under the IBM version (who have yet to release a 1.4 for windoze). Lest you say it is just me, this same problem exists for a number of other users of the same applications running different hardware/OS configurations. Upon reverting back to 1.3, all is well. As a user, not developer, I find this unacceptable - I shouldn't have to worry about performance degredation when upgrading java. I seems the rush to add features before optimizing (and fixing) prior code is SOP for the software industry these day.

Re:Shouldn't they make 1.4 work first?

[Golthar]

It should come as no suprise that bugs of these kind are being fixed and that you should consider using a newer version.
For example if you use 1.4, 1.4.1 is compatible but includes a lot of bugfixes.

Good chance that yours might be fixed.
Also, talk to the person who produced the software first.

Yes, I know downloading a new VM is a lot of bandwidth, but soon (from 1.4.2 and upwards) the VM will be easier to upgrade

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:Sun's Hotspot JVM is written in C++

[jonabbey]

Sure, if you're writing an operating system or a low-level code execution framework tied to a specific piece of hardware and operating system, use C or C++. If you're wanting to produce high-level code and you're not interested in spending ten times the effort to do it, use Java, or Python, or Perl, or whatever.

Not all languages are equally appropriate tools for every purpose. Java certainly isn't appropriate for everything, but people who believe that C or C++ are appropriate for everything are likewise fooling themselves.

Re:Sun's Hotspot JVM is written in C++

[be-fan]

I really don't see Java's place here. In the hands of a good programmer, Java isn't any more productive than C++. Python is an order of magnitude more productive than either, and IMO should replace both for application-level programming. But Java? I just don't see the benifet, aside from a smaller learning curve.

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

[VAXGeek]

That "faster than C sometimes" statement is pure Sun marketer drivel. Think about it this way, if Java can be faster, why does when anyone want a highly optimized Java VM they write it in C?

bloat

[stile]

Let's just hope they don't get too carried away and bloat the language. :-/

Uh... you're talking about Java...

oh come on.... look at the links at least first...

[BlackStar]

Might just be me, but I don't see any prototype implementation on those links, except the generics prototype that has been available there for about 2-3 years since 1.3 came out. The other links only point to the JSR working group.

Another wonderful example of headline trolling. The generics implementation is very old news to the java developer community. It's just been under a lot of scrutiny before getting put into the language.

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) { ... }

Re:iteration

[GrayArea]

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

Re:Sun's Hotspot JVM is written in C++

[jonabbey]

Well, I've written around 250,000 lines of Java code, and I can count on one hand the number of times I found it necessary to use a debugger. I can't conceive of anyone saying that about C++ with a straight face.

I mean, maybe you have a god-like impression of a good C++ programmer, but having Java's enforced encapsulation, top-to-bottom integrated exception mechanisms (i.e., even for a null pointer), powerful, consistent set of thread-safe libraries..

Why do Trolls Love LA?

[jefu]

OK. I'll go you one further and say that Java (and c# for that matter) have done lots of non-innovation and are still nowhere near as good as Sather was a decade ago.

Sather had a mechanism to use constrained genericity to handle the problems that templates are used for - and it worked well.

Everything was an object and a member of a class - though there were two kinds of objects and that did introduce a bit of complexity.

Sather also had preconditions/postconditions/class invariants that did the "by contract" thing well and that I'll bet cut my debugging time by 75% or more - at the cost of a bit more up front thought time ("Just what is the class invariant here?")

Sather had a very, very, very nice iteration mechanism. A class could define multiple iterators (syntacticly they had to end in "!"). Since these were defined in the class they had access to class variables without any "friend" or "public"/"private" jiggery pokery. As an example, since an array was an object, it defined an iterator elts!. So if "a" represents an array the following does exactly what you'd expect :

sum := 0 ;
loop sum := sum + a.elts! ; end ;

would do the Right Thing.

Sather also had operator overloading (rather limited and pythonesque "a + b" translated to "a.plus(b)"), ways to skip variable declarations in some cases, a very simple inheritance structure and some odd syntax.

Because there are so many bridges.

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.

Lisp is not slow

[Anonymous Coward]

Lisp is certainly not slow, even when compared with C++. It can even do certain things faster than C++ with most tasks in a very acceptable range, including being much faster than java and having a much better and more stable garbage collector.

http://www.norvig.com/Lisp-retro.html

Also Java sucks when compared to Smalltalk in terms of productivity and ease of use. Smalltalk should be a mandatory first OO languages in universities especially for concepts. Java is more popular than Smalltalk and has a lot more libraries, standardization and available programmers, but it still sucks, albeit less than C++.

Everyone tries to defend languages that they're fond of and used to without getting out of their comfort zone and trying something that might be better. If someone claims that Java is better than Smalltalk or Lisp, then they have not worked with Smalltalk or Lisp.

There are a lot of good languages out there with useful features, nice libraries and support for different paradigms which are better. Take Objective Caml for instance, which is very fast, strongly typed, dialect of ML and is certainly a better language than many, but it is doomed to live in academia, because people from the industry (pointy haired bosses) are too dumb and scared to even know about these things.

However, I see these new additions to Java as a welcome change. Hopefully someday people would not have to use some other language in the JVM just to implement closures and hopefully Java will catch up with languages like Lisp and Smalltalk and Python and Ruby and Haskell and Perl and Scheme and Dylan after it finishes catching up with Objective C.

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.

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

[mentin]

And the most funny part is Static Imports: it is one of the Microsoft additions to Java back in time when there was no C#, and Microsoft shipped Visual J++. That time Sun sued Microsoft for adding Static Imports to J++ (among other enchancements). Now they are adding Static Imports themselves. They should sue themselves now.

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

[mentin]

I just realized some time in the future that Visual J++ might become standard-compilant language (without any change, the only change will be in Jave specs). They are planning to add metadata (think attributes) to 1.6, so the only thing left is delegates.

Re:Sounds Promising

[bigfleet]

The best example of an expansion is when instantiating a type variable in a method's return signature.

For example, when using the visitor pattern, you have have a signature that looks like this.

public <RetType> RetType accept( FooVisitor<RetType> visitor ) { ... }

This allows you to write one hook for visitors which could return several different kinds of objects, as well as being able to depend on getting the correct one out in whichever method invokes the accept(...) method.

You can also use generics in your own ways in your classes. There are several other powerful uses.

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

[jeremyp]

Hey, why bother with a for loop. Isn't that just compiler bloat? As Kernighan and Ritchie pointed out:
for (i = 0 ; i < SOME_VALUE ; ++i)
{
/* do something */
}
is completely equivalent to
i = 0 ;
while (i < SOME_VALUE)
{
/* do something */
++i ;
}
In fact everything beyond if (...) goto ... is theoretically unnecessary.

Why Use Java?

[Mooncaller]

Why would a developer use Java which is "owned" and not supported by an open standard when languages like Python exist? As far as I can tell, Python can do everything Java can without Sun entangelments. This is not a troll, though I am trolling for information. It is a serious question. The only Java person I know, bases his buisness on providing Java solutions so his opinion is a bit biased.

A number of my former-coworkers and myself are starting a little buisness. I am goining to be the primary software architect. We are still selecting tools. I tend to be an agressive persuader, able to defend my position even if I'm wrong. I am pushing for using Python. Another developer likes Java, but I have effectivly convinced him to go with Python. Because of my agressive nature, I must be carfull to gather as much data a posible. Then I need to insure that I base my decisions on an unbiased evaluation of the data. I hate making decisions and cramming them down everyones throught only to find out a year later that the decisions were flawed. BTW, my Java friend uses the same techniques as me in achieving team concensis!

Re:Why Use Java?

[Hezaurus]

If I had to switch to other language from java I'd probably switch to python too! Have you checked psyco? It's a JIT compiler for python which brings the performance close to the level of java. But these are the things that are 'keeping' me with java:

• huge developer base
• almost all universities teach it
• It works equally good (if not better) on linux and OS X
• JDBC - works equally well on all databases
• JBoss Hey it's free, and it's good.
• IntelliJ IDEA not free, but worth every euro!
• Jakarta community is unrivalled.
• ANT simply the best build tool.
• Options, options, options. No single vendor lock in.

BTW: I just run Scimark benchmark with 1.4.2b and the results are 2x compared to 1.4.1! The new experimental SSE optimisations in JIT are really showing off ;-) (Score ~260 on a 1,6GHz laptop)

Re:Why Use Java?

[dunham]

I too like Python a lot, but:

• Java has JIT (including method inlining and other optimizations), which seems to give a performance advantage.
• Java has garbage collection, and more recently, decent garbage collection. This is important for long-running and/or large applications. (When I last checked, Python didn't have garbage collection. It used reference counting, which usually is slower, and leaks data.)
• I'm not sure if Python has any object/relational layers. (There are a few choices on Java.) It should be easily implemented though, given Python's dynamicism and reflection capabilities.

So, I'd use Java over Python for projects where these factors are important. Language-wise I like Python a lot. I prefer Common Lisp for speed, features, and syntax, but Python has the libraries.

IMHO, dynamic languages seem to be the way to go for a lot of tasks. But staticly typed languages are usable when type inference is added, as in ML family languages. (c.f. OCaml for a fast, usable example.)

Re:A nitpick..

[transient]

What's with the copy? Just curious.

Re: Paul Graham

[Wesley Felter]

Sure autoboxing is optional. If you write 1.4-style code there won't be any autoboxing.

Re:A nitpick..

[larry bagina]

look carefully, he created an NSMutableDictionary, not an NSDictionary (which can't have data added after initialization).

Hey, let's start an argument on static v dynamic

[PylonHead]

Hey, let's start an argument on statically typed vs dynamically typed langagues. That's never been done before.

You don't need a dynamically typed language to be expressive. Have you looked at ML code, or especially Haskell code?

When you have type inference, your code looks dynamically typed, but retains the protection of the type checker. (Of course you have to live within the type checker's rules, which may not be appropriate for all projects).

Linux + Java: the distant future

[ThreeFarthingStone]

Java really needs a good collections interface (introduced in 1.2) and generics (to come in 1.5), but it may be years if Java 1.5 is ever available for my platform (notice my selfishness).

I've never heard of JBoss before, but it seems it will turn almost any J2SE into a J2EE. But where do I get my J2SE (a Java 2 Standard Edition, runtime environment, libraries, and compiler) so that it works correctly?

Right now, on my GNU/Linux system with a PowerPC CPU (a Macintosh), I'm running Blackdown Java (J2SE) 1.3.

Anonymous Coward wrote: It is real, effective, efficient and fit my need ;) In my case

1. Java is sometimes not real. Programs using the GUI (JFC/Swing) are not working. I can't get the latest version of Java 1.4, because its not ported to PowerPC.
2. Java is sometimes not effective. Java is my preferred programming language, and usually effective. It would help if I could use collections with generics, but once Java 1.5 is out providing this, it probably won't be ported to my platform.
3. Java is sometimes not efficient. Interpreted Java bytecodes are fast enough for me, but my platform does not provide JIT or HotSpot acceleration.

I am watching potential sources of ports (Blackdown, GNU Classpath, GCJ, and Jikes RVM) for emerging Java 1.4 or 1.5 that actually works. Until then I won't have working Java.

Anonymous Coward wrote: What MS fears the most is Linux + Java. Because it is a more powerfull that they can even provide. However in my case, working Java is an incentive for me to switch to an x86 computer with Microsoft Windows, in order to run Windows + Java.

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

[BlackStar]

I stand corrected. Sun appears to have stealthed the change on this one. Good find. I had the generic download a long time ago. This is an update of some sort. Thanks for the pointer!

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.

no FUD, facts

[73939133]

I'm not talking about "fear, uncertainty, and doubt". What I'm complaining about with Java is not uncertain at all:

• Sun pulled out of standardization efforts despite their promises to make Java an open standard.
  
• Sun has failed to deliver shared VMs.
  
• Sun has failed to deliver the numerical enhancements they promised for Java.
  
• All implementations that may call themselves "Java" are derived from Sun's source code (otherwise, show me a third party implementation of Swing).
  

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.

You are "linked to a provider": Sun. You are linked to Sun as much as Windows programmers are linked to Microsoft.

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

Quite to the contrary. When I started out using Java in 1996, it had the promise of becoming a full cross-platform, general-purpose, open programming language. But Sun failed to follow on so many promises that today it is a niche programming language. Java is mostly used for certain server-side applications.

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

Maybe it fits your needs, it doesn't fit my needs: its awful toolkit, poor numerical support, proprietary runtime, flaky cross-platform behavior, and lack of third party implementations alone make it a poor choice for me.

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.

Open source users use open source software. Java isn't open source. It's free-as-in-beer, and that isn't good enough. All efforts to produce a complete, conforming open source Java implementation for Linux have failed, mostly because Sun, like Microsoft, keeps adding APIs faster than people can re-implement them, and because Sun's APIs are not very well suited to implementation on Linux.

Linux may need some improvements on the desktop/client side (but, then, so does Windows), but Java isn't providing them. In fact, even Sun is using Gnome/Gtk+/C++, not Swing/Java, as the desktop for their workstations.

Re:ohh, yea

[wigle]

I was trying to be funny :o)~~

Re:Java has lost the lead on managed lang. evoluti

[multi io]

This is firm proof that Java has lost the lead on the evolution of managed languages. .Net / CLI has surged ahead, both in terms of the expressiveness of its intermediate language (MSIL can express ALL of the C++ semantics, including all unsafe operations), and in terms of the usability and expressiveness of its primary managed language -- C#.

What are "managed languages"? P-code interpreters/JITers and languages that target them have been available for decades. Neither Java nor C# "leading" in those areas.

Could it be that you're just inventing a new buzzword here? "C# is taking over the lead on byte-compiled languages" would make C# look less unique and suggest too many similarities to Lisp, Ocaml etc., so it has to be "managed languages", uh huh.

Btw, any turing-complete machine can express all C++ semantics.

Re:I doubt that MS FUD will succeed.

[73939133]

Oh your argument is that the system libraries are inadequate. In what way do you feel they are less in capability than .Net?

C# lets me call system libraries directly, and it lets me access native data structures directly and efficiently. For Java, I have to write cumbersome and slow JNI wrappers to native libraries.

Furthermore, people are developing Linux-specific libraries for Mono at a rapid pace, while Java program on Linux mostly use Sun's WORA libraries, which aren't very good.

macro preprocessor

[multi io]

Java 1.5 apparently introduces a bunch of festures like foreach, enums, autoboxing etc. which are just syntactic sugar and trivially map to to equivalent constructs in "traditional" Java. For example,

for ( <type> <id> : <expr>) {
<body>
}

gets mapped to something like

for ( Iterator it = <expr>.iterator(); it.hasNext(); ) {
<id> = (<type>)it.next();
<body>
}

Couldn't they just introduce a standardized macro processor/preprocessor and introduce such minor additions as part of a standard macro library (or let users write them themselves), instead of having everybody wait for new language versions?

Re:Interested in learning more about these generic

[gafter]

> Still, I don't remember syntax for handlign
> covariance, contravariance, invariance, etc.
> Was it there and I didn't see it, or are Java
> 1.5's generics truly different form C++
> templates.

Java generics are fundamentally quite different
from C++ templates. There is nothing like
covariance etc in C++ templates.

closures

[cakoose]

If Java supported closures, the 'foreach' construct wouldn't have to be a special case. I think C# is going to have something that looks a lot like closures but for some reason, they are going to avoid providing general-purpose closure support (it's sad, really).

On the other hand, it looks like the value/class distinction in C# is going to help make its generics more efficient than Java's. It'll be like C++ except with runtime specialization when needed, so the disk image wont be bloated, just the memory image.

Re:closures

[cakoose]

Actually, my mistake. Technically, C# does have closures. But the lack of Ruby-like syntax makes them seem clunky (though slightly less clunky then Java's anonymous inner classes.

Re:closures

[multi io]

Technically, C# does have closures.

With lexical scoping? That's news to me.

Re:closures

[cakoose]

Whoops. In my original post, I linked to a document that described features that were being considered for addition into the language. Don't know what the current official state of C# is.

Re:Sun's Hotspot JVM is written in C++

[be-fan]

Why would any C++ programmer bother to do manual memory management? Try writing STL style code sometime. I managed to write an entire simulation once in C++ without using a single new/delete call. Between the STL's value semantics, the resource acquisition is initialization mechanism, and smart pointers (which implement reference-counted GC) C++ memory management is a whole lot more powerful and flexible than Java memory management. And if you want, you can always use a garbage collector, and many C++ applications use it to great effect. Now, you can get around all of these mechanisms in C++, while in Java, you can't. I consider this a strength, not a weakness. If I want to allow the saftey nets to work, I just write straight forward, safe code. If I don't want the saftey nets to work, I have to conciously work around it, at which point it becomes my responsibility to make sure n othing breaks.

There are lots of applications that don't require sandboxing, including most application development. And lack of static typing is a feature, not a bug. Python uses strong dynamic typing, like Smalltalk and Lisp. Meanwhile, Java, C++, ML, Haskell, and others use strong static typing. They are simply two different paradigms, and each has its attended benifets and limitations.

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.

PowerPC Linux port?

[SHEENmaster]

As I constantly bitch on my programming site, J2DK/RE 1.4 still hasn't been released for Linux on PowerPC. I love my iBook and plan to buy an iMac; if the two are left further behind for Java I just might abandon it. "Write once run anywhere." is meaningless if most platforms don't have new features for years.

I recently switched to C for a few projects; the speed is surreal by comparison

Re:PowerPC Linux port?

[Jord]

most platforms don't have new features for years

Most platforms? You are referring to one OS running on one piece of hardware. Linux on Intel runs 1.4, OS X runs 1.4, Windows, et al. If Java 1.4 is that important to you, run OS X like I and quite a few others do. Java runs fantastic under OS X. And with Virtual PC I am able to run Linux and Windows under OS X at an acceptable speed for development.

It may be just me but complaining about Sun NOT supporting Linux on PPC is a minor complaint. If I recall there are open source JVMs out there that you can compile for Linux on the PPC and get what you are looking for.

So...

[jefu]

So, I could define a function that returns a object in a class that implements SimpleIterator :
RandomArrayIterator(int a[])
with an iterator named iterator and then do something like :
for (int i : RandomArrayIterator(a) ) { ... }

But the spec (yes, I did read it) implies that the result of RandomArrayIterator must be an object that defines iterator. so this is really shorthand for :
for (SimpleIterator sit = RandomArrayIterator(a).iterator() ; sit.hasNext() ; )
{ int i = (int) sit.next() ; ... }

I think two things about this make me uncomfortable. First is the fact that I need a class with the right type to return from "RandomArrayIterator" which defines "iterator()", (at least, this is the implication of section III "Semantics") then I need a class for the result of the "iterator()". (Yes, I do realize that these can indeed be the same class.) The second is the "specialness" of the defaults (which is actually the second call there "iterator()").

Re:So...

[GrayArea]

I guess the idea is to use the explicit form if you need to fumble with the iterators themselves. You might want to use the filtering iterators in Commons Collections or actually remove items, then you need the iterator itself.

"iterator()" is actually less special than Object.toString(), which is called in string concatanation. At least it's defined in an interface. Now, you could call the use of "Iterable" interface a special default too, but again it would be no more special then the way "TypeName.class" syntax is used to get a "Class" object. In a general sense, it's syntax directly hardwired to a special class, which Java has a lot of examples for. Unless we can define our own syntax in our programs (like Mathematica patterns, Lisp macros?) these things will continue to be pushed as "features", no way around it...

Got a better way?

[jefu]

I currently have a procedure that iterates over every element of a two dimensional array (call it xy) and for each such element it iterates over every element of another array (call it g), and for each such element it iterates over every element in another array (call it c). n^4

There's another way to structure the code that rearranges this to iterate over all the elements of g and then over every element in the associated c array. And then iterates in a double nested loop that didn't appear above.

There are a couple other ways to do it too, but they require substantially more code complexity and its not worth it here - there are a number of other things that currently dominate the runtime. So I'm using the simplest one to hand. If its a problem and this ends up the bottleneck I'll worry about it then.

"Premature optimization is the root of all evil."

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

[Jord]

Your forgetting that J++ had all of the COM underpinnings and did not support RMI (if I recall correctly, have not touched that trash in half a decade).

I doubt that the MS JVM will ever become compliant. There was way too much MS proprietary stuff in there.

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

[pnatural]

I have little doubt the "metrics you've seen" are in fact very unrepresentative of real world apps. You should be looking at papers like this:

http://www.ipd.uka.de/~prechelt/Biblio/jccpprtTR.p df

Now, the interesting thing about your post is that it sounds like (notice I say "sounds", not "is") you're a Java person, and you're more than a little threatened by Python. Sure, Python is faster for most things, requires less code to accomplish the same task, and is much easier to maintain, but Java still has it's place. You're safe.

Thanks!

[Mooncaller]

I'm repying to my post instead of all the /.er who responded to me. I appreciate the feedback. I am also glad that I did'nt get flamed. There was some common points. One being alternatives such as OCaml and Common Lisp. I had seriosely (sp?, I've got 6 dictionaries and I can't find one!) concidered OCaml, but decided on using Ada for tthe low level and Python(?) for the high level. I feel that Ada and Python make a good match.

The main reason that I did not go with OCaml is the size of the project. It has the potential of being rather big and might eventualy involve a diverse development community. I don't know how good OCaml is for large projects, or how easy OCaml code is to maintain. On the other hand, OCaml targets the problem space I am working in ( which I have'nt mentioned). At some point I will be writing a toy OOP OS in OCaml, Oh my.

I also like Common Lisp. I have never used it but I plan to. Unfortunatly, my plate is kinda full right now. Honestly, I never concidered using it for my current project. BTW, I do plan on writing an experimental 3D desktop in Lisp. Ok, so I'm sick.

Another poster mentioned Jython. Jython was one of the factors that helped me decide to use Python. Yet another mentioned Ant. Ant realy needs to leave the Java anthole. Why it has not gained more acceptance is beyond me. Ant can be more then "that build system for Java". Build, packaging, and distribution/installation issues are one of my specialities. I know more about "make" then is healthy. I have developed techniques to get around almost all the limitations of make ( without relying on ksh!). The problem is the obnoxious syntax that results. Even with the greatest care taken to maximize maintainibility, the resulting Makefiles are often downright Byzintine. For huge projects ( which are also the ones that require the most attention to maintainibility), make just falls apart. One point to make, both Ada and Python take care of a lot of the configuration managment taskes normaly delegated to make.

It also appears that using Java does not result in a potentaly abusive relationship with Sun. The fact that Sun owns Java still makes me a bit nervouse.

A final note, after 20 years, I am pretty fed up with fixing bad C code and I find C++ obnoxious. I do not plan on using either for any of my non-job-related projects, though I might make a acception for C in some very special circumstances.

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

[Hognoxious]

Whichever Java feature you remove, it could be reimplemented by a couple of lines of code at every place you'd have used the removed feature...

In languages that have goto, you could use them to reimplement all control structures. Whether you should is a different matter.

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.

Re:The problem: Improving programmer producti [OT]

[MochaMan]

Introductions are in order: Good day sig guy, I'm whiny grammar guy. I teach English as a second language (part time now, full time in 2001-2002).

Believe me, the sig is wrong. It has nothing to do with "modding" being a verb. And as for grammar checkers, they're pretty awful, and make mistakes on even simple grammatical constructs. Run your sig through an English major and see if they come out as unscathed... Two possible correct versions are:

Modding This Comment Will Not Alter Its Accuracy or Its Insightfulness

or:

Modding This Comment Will Neither Alter Its Accuracy Nor Its Insightfulness

Honestly. If you don't believe me, drop by an English teacher at your local college/university and get a second opinion. Of course, if I'm gonna get picky the capitals should really go too... :)

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

[ClosedSource]

Here we go again with this disguising argument. Name one vendor who implemented their application using J++ and then discovered after its release that it wouldn't run on anything but Windows. Most programmers who really cared about cross-platform development probably didn't use J++. Most of those who did use it were targeting Windows.

Re:Sun's Hotspot JVM is written in C++

[NoOneInParticular]

Well, I've written around 250,000 lines of Java code, and I can count on one hand the number of times I found it necessary to use a debugger.

Doesn't this have a tiny bit to do with Java always running inside some minimal debugger? Imagine rigging C++ in such a way that it will always run through gdb and on error will provide you with a stacktrace. The stacktrace gives enough info for the majority of the bugs, but would you then with a straight face claim that you can program C++ without ever using a debugger?

Your code

[NoOneInParticular]

Excellent example for the use of operator overloading. Most languages out here support the:

b = a + 1

idiom for vectors and (multidimensional) matrices. The fact that this is impossible for Java really constitutes a problem for library builders (mere application developers should indeed be forbidden to do operator overloading, but for a library it is often a *must*).

Re:Sun's Hotspot JVM is written in C++

[jonabbey]

Doesn't this have a tiny bit to do with Java always running inside some minimal debugger? Imagine rigging C++ in such a way that it will always run through gdb and on error will provide you with a stacktrace. The stacktrace gives enough info for the majority of the bugs, but would you then with a straight face claim that you can program C++ without ever using a debugger?

Well, could we also arrange it that C++ can run multithreaded in such a way that if any thread throws an exception (on an attempt to dereference a null pointer, say) the other threads can continue to function? And can we arrange things such that it is impossible for any piece of code to scribble over random pieces of memory? Can we also add on a wholly-integrated memory management system, supported by all C++ libraries?

I do claim that I can program Java without ever using a debugger, because Java's rules are stringent enough that silent corruption and delayed effects don't occur, and because the Java Runtime provides enough support in many cases to be able to diagnose things whenever an exception (_not_ a core dump) is thrown.

My whole argument is that Java really and truly is a significant increase in programmer productivity over C++. If you have this hypothetical super-C++ development environment to go along with your hypothetical super-C++ programmer, perhaps this wouldn't be true for your case.

Re:Sun's Hotspot JVM is written in C++

[jonabbey]

You're claiming that reference counting is a whole lot more powerful and flexible than Java memory management?

Surely you're not claiming that there exists a garbage collector for C++ that can work with arbitrary C++ code? I'd hate to have to reimplement all the libraries I wished to use in order to make them work with a given garbage collector.

Re:Sun's Hotspot JVM is written in C++

[be-fan]

I'm claiming that C++'s memory management overall is more powerful and flexible, because you can tailor your memory management scheme to the task at hand, rather than being forced to work with the garbage collector. Right now, I'm using C++ in an OS kernel. Reference-counting smart pointers work very well in that environment, while a GC would cause latency unpredictibility.

C++ garbage collectors can work with almost arbitrary code. The basic requirement is that your code doesn't obfuscate pointers. Some C-style libraries do this, but you can hardly blame C++ for leftovers from a time before modern C++ design existed. More importantly, lots of C++ libraries are available that *don't* do screwy pointer tricks, so you have no excuse to complain if you use one that does. That said, garbage collection is not the optimal method to use for C++ code. C++ is explicitly designed to make garbage collection mostly unnecessary. A quote from Alexander Stepanov, designer of the STL:

"STL data structures will eliminate the majority of the needs for using new. Most people should not allocate arrays because STL does an effective job in doing so. I never need to use new in my code, and I pay great attention to efficiency. The code tends to be more efficient than if I were to use new. With the acceptance of STL, new will sort of fade away. STL also solves the problem of deleting because, for example, in the case of a vector, the destructor will destroy it on the exit from the block. You don't need to worry about releasing the storage as you do when you use new. STL can dramatically minimize the demand for garbage collection. Disciplined use of containers allows you to do whatever you need to do without automatic memory management. The STL constructors and destructors do allocation properly. "

He has a very good point. The first time I used the STL was on a scientific simulation. I did not know a whole lot about "proper STL design" or about modern C++ design in general. I wrote the code in a way that came naturally when using the STL. It was only after the fact that I realized that I had zero calls to new/delete in the entire codebase.

Re:Sun's Hotspot JVM is written in C++

[jonabbey]

Interesting, thanks.

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

[BenTels0]

Ehrm. I have to tell you, I for one am not very happy with that paper. It is a comparison in certain aspects (by some metrics which you may or may not believe are the right ones) of several languages which are not all really geared to the same purposes. As a clear example of this, you might consider the start of the book "Learning Python" from the O'Reilly series where Python's place in the spectrum is indicated. This includes the question "how does it compare to Java" and the answer is flatly "It doesn't; Java and Python are meant for different things and complement eachother rather than compete". You can also see this in the abbreviated "problem statement" in that paper:

On the other hand, the problem should be much easier to do in a scripting language compared to Java/C/C++, so you can expect much less effort than indicated above.

That's on page 8 -- and indicates that the "ease of use" metric will always be skewed since the problem is geared towards scripting languages more than system-level languages.

All that aside, it seems to me you are on very thin ice at best by referring to this paper for leads on what is "better" or "faster". The paper is some 3.5 years old -- that is a very long time with a lot of changes in between.

and you're more than a little threatened by Python

Don't see why he would be. They aren't aimed at the same problems. Hell, they are in such a level of non-competition that there is even a Python for the JVM (JPython) with integration into Java.

Python is faster for most things

For whatever that means. When it comes to perceptual speed, it happens often enough that I cannot tell the difference anymore. Like I said, times change.

and is much easier to maintain

Now that I will outrightly contest.

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

[BenTels0]

You have to remember where the "faster than" comes from (and understand why it's sometimes): it's based on runtime optimisations to the program that a VM (any VM, not just Java) can do and a pur sang compiled system cannot (i.e. using the advantage of being able to rewrite code on the fly to optimise for the specific situation).

How often this occurs is anybodies guess. Whether it would be of any use in the JVM itself, I don't know. That trying to write a JVM in Java is inviting the chicken and the egg problem however, is obvious.

Re:Sun's Hotspot JVM is written in C++

[ron_ivi]

jonabbey wrote:

"Surely you're not claiming that there exists a garbage collector for C++ that can work with arbitrary C++ code?"

Of course there is.

The Boehm-Demers-Weiser conservative garbage collector works very well.

On multi-threaded systmes, it can outperform malloc/free based allocation because less locking of the heap is required.

Swing

[SHEENmaster]

With MoL, I can run OS X in realtime. It's a decent operating system, but Debian's package manager makes it a better choice for me.

Porting it from Linux/x86 or Linux/UltraSparc should be as simple as crosscompiling; nothing as complicated as the OS X port.

I use Kaffe, GCJ, and Blackdown's 1.3.1 java port on my PowerPC boxes. Wonka works well on my Zaurus. Sun's java seems to have a monopoly on Swing. IBM's seems interesting, but I haven't had the time to look into it yet.

If MoL has been ported to OS X, it would be a much faster alternative to VPC.

Re:Swing

[Jord]

Have you tried just pulling over the class files? Specifically the rt.jar file? I have not compared 1.3 to the 1.4 release but it seems to be that you would be able to gain everything that is above the byte-code (new classes, code fixes in the classes, etc.) without having to worry about having a 1.4 compiler.

I have done this in the past with other releases (I have even back ported code to an older release) with success.

May be an acceptable alternative for you.

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

[HuguesT]

Ah, "the JIT knows better" argument.

In fact, in a C/C++ environment you can optimize a particular program knowing exactly which paths and variables it is going to use, this is called `profile-based optimization'. You can try this with the Intel C/C++ compiler or with a recent gcc.

Now you need a test sample of the data your application is going to work on, but then the optimizer will make use that data exactly as a JIT compiler would do.

If you try this with a realistic application (not a toy 10 liner) you will find that with few exceptions that super-duper optimization strategy does not do significantly better than normal optimization (it does get a few percent faster). What I mean is if you try this method on an already somewhat big, mature and tested application you will get few benefits.

This is because in a realistic application, things get optimized by the interaction between programmers and testers already. Often inefficient code will have been removed already, and what is left is there for a reason so there is not much to work on. Try it for yourself sometimes.

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

[HuguesT]

Sorry I should have made it clearer, that wasn't my point. Even if you run your path-optimized executable on the *test* data, which is basically the most advantageous figure case, you don't get that much of a speedup over a normally optimized executable, if the test case is sufficiently complex to represent reality (if it's a toy test case, then sure you do get some speedup, but who cares?).