Have a Nice Steaming Cup of Java 5

wap writes "The language/VM/religion that everyone loves to hate is now serving another cup: Java 1.5 is ready for download. The new features of 1.5 have been discussed here before. I, for one, welcome our new virtual machine overlord. I have been using the release candidate, and startup times are noticeably faster, as is overall performance, and the new features like typesafe collections and static imports are great to have. Let the Java flames begin!"

Comments

Thanks to our supporters

[NoInfo]

"This release was made possible by our world-wide development community.

Oh, yeah, and ridiculously large settlement payments by Microsoft."

Re:Thanks to our supporters

[Anonymous Coward]

I hate to say this, but:
your cut is the fact you can use it for free!

A. Coward

Re:Thanks to our supporters

[Anonymous Coward]

You forgot to add "Netcraft confirms it - Java is dying" onto the end. But not a bad effort for a beginner troll.

Re:Thanks to our supporters

[coopaq]

"This release was made possible by our world-wide development community. Oh, yeah, and ridiculously large settlement payments by Microsoft."

I hate to say this, but: your cut is the fact you can use it for free!

I hate to say THIS but that money DID come from me over the course ten years of PC systems with buggy operating systems on them.

Maybe I should just get a linux PC next time and install Windows if I need it.

Comment removed

[account_deleted]

Comment removed based on user account deletion

I wait!

[orangeguru]

I wait for the first bug reports ... and version 1.5.1 ...

Re:I wait!

[Surt]

whew! shift-f6 that was hard.

Re:I wait!

[markfive]

> perl -pi -e "s/enum/myEnum/g" *.java

Re:I wait!

[DChristensen]

> perl -pi -e "s/\\benum\\b/myEnum/g" *.java

Don't forget the \b for word breaks, or you might end up with something a little different than you intended.

Finally!

[arhar]

I've been waiting for this for a long time! Now waiting for Eclipse to release a working plugin (well, there's this ,but it's not that great.

Java is to C as ...

[SamSeaborn]

Java is as far above C as C is above Assembly.

Microsoft was right to be afraid, developing in Java is a delight.

Sam

Re:Java is to C as ...

[NightWhistler]

Depends on what you define as paradise really... around here we "lovingly" refer to the VS.NET Gui builder as "The Blob Generator". All you anti-patterns folks, you know what I mean.

Re:Java is to C as ...

[JUSTONEMORELATTE]

Java is as far above C as C is above Assembly.
I was about to mod this as Funny, but then I realized that you weren't making a joke.

Back in the day, the tagline was "C -- all the speed of assembly, with all the programming ease of assembly."

--
Free gmail invites

Re:Java is to C as ...

[MarkGriz]

"If Java is a cup of coffee, C#/VS is a cup of sweet sweet chocolate."

Too bad you can only drink "sweet sweet chocolate" in a dark, virus infested alley, while coffee can be enjoyed by everyone, everywhere.

Re:Java is to C as ...

[rishistar]

I'm English dammit! I want a cup of tea!!!!

Re:Java is to C as ...

[sbrown123]

Object orientation is a terribly inefficient way to program.

OOP advantage is best seen in large projects. Particullary collaborations. I've worked on large codebase non-OO projects before and know the headaches.

Also, what about compile times and the fact that Java actually doesn't work on all interfaces?

Dunno. What interfaces are you talking about?

Compile times? Java's pretty speedy compiling. Than again, I dont have a 286. Will say this though: Make is a hell of a lot quicker than Ant. Ofcourse you could always use Make for building java though.

(And as a side note, I don't like the fact that you have to type four lines of code to do what C++ could do with a simple cin >> var;

in Java would be:

System.in.read(var);

Re:Java is to C as ...

[E_elven]

The Tea Programming language.

Re:Java is to C as ...

[Coward the Anonymous]

" Yeah, because device drivers and operating systems are being written in Java"

http://jnode.sourceforge.net/portal/
"The goal is to get an simple to use and install Java operating system..." ;-)

How long will the MacOS X release take?

[Offwhite98]

After they took all that time to rewrite it with the latest API they claim they can closely track Sun releases. This will be the first big thing since then, so it will be a test of Apple to get it out quickly.

Re:How long will the MacOS X release take?

[Anonymous Coward]

Well there's been a Developer Preview available since June.

Re:How long will the MacOS X release take?

[adavies42]

I don't know when it will be out, but I can tell you what the Apple headline will be: "Tiger on Tiger".

Re:How long will the MacOS X release take?

[Sanity]

Apparently it is planned for release with Tiger, the next major release of OSX. I don't know whether it will be available prior to the release of Tiger, if not, it is likely to prevent most developers from coding in it (what is the point in coding in Java if it won't work on the #2 desktop OS?).

Re:How long will the MacOS X release take?

[koehn]

I downloaded the beta (from where I can't say :-), but it only installs on Tiger (OS X 10.4). Since I don't really want to run a pre-release OS, I took a pass. But JDK 1.5 is coming, it's just several months off.

But by your post, you had probably already guessed that. At least it's probably less than four years, like it was before Mac folks got JDK 1.2...

Re:How long will the MacOS X release take?

[angel'o'sphere]

... it is likely to prevent most developers from coding in it
Not really. CodeGuide, www.omnicore.com, thats an IDE, has a MAc release since years. That allows using Java 1.5 features in coding. And as you can create byte code compatible with JDK 1.4 released software will run on a Mac as well. Tehre are minor issues however e.g. new methods in java.lang.String wich work fine in the IDE (becase the classpath is different) but not in standalone mode. Nevertheless, I'm coding on a Mac, not necessaryly for a Mac, thats why I use java with generics and the later Java 1.5 betas since over 2 years now. (And since about 14 month on a Mac).

I would expect that Eclispe and other major IDE vendors have a Mac version bundled with JDK 1.5 runtime libraries as well.

angel'o'sphere

Re:How long will the MacOS X release take?

[Cederic]

>> what is the point in coding in Java if it won't work on the #2 desktop OS?

Perhaps because it will work on the #1..n server OSes?

Re:How long will the MacOS X release take?

[Anonymous Coward]

So I had the opportunity to talk to some Sun employees a few weeks ago.

And I asked them, "do you know, will Java 1.5 be in Tiger?"

And they just looked at me really funny and were like "well, obviously."

Later I found out apparently "Tiger" is also Sun's codename for their version of the Java 1.5 release.

Oops.

Re:How long will the MacOS X release take?

[BorgCopyeditor]

Shouldn't that be: "Hot Tiger-on-Tiger Action"? The spokesmen will of course be Siegfried and Roy.

Passe...

[gowen]

Don't you know, we don't hate Java anymore. These days we all love Java due to its major new feature -- its not C#

Re:Passe...

[spellraiser]

Yes, it's not C#, but it is getting closer and closer to being C/C++ (or something very very close). For instance, Java 5 borrows features heavily from C. Just take a look at some of the new features:

- Generic Types (AKA templates)
- Enumerated Types
- Static Import (usage of this looks quite similar to the #define method)
- Formatted Output / Input (printf/scanf style)
- Varargs

I like this trend. These, among other changes in version 5, are all steps towards reducing the awkwardness in the Java syntax that many people complain about. Java is a young, evolving language that still has a lot of potential.

It is a bit funny, though, that this evolution takes the form of borrowing stuff from an ancient language. Maybe C just got things right in the first place, huh?

/me puts on a flameproof suit

Re:Passe...

[gh]

Yes, heavy influence from C/C++, but funny thing is that the Java camp has avoided introducing these features until C# made a lot of them popular again.

New Features in Java 5:
- Generics (C# 2.0)
- Enumerated types (C# 1.0)
- Static import (not available in C#)
- Formatted output / input (C# 1.0)
- Varargs (C# 1.0)
- for loop changes (C# 1.0, equiv foreach)
- autoboxing (C# 1.0)
- metadata (C# 1.0)

In C# 2.0, it will have features that Java 5 does not support:

- iterators
- anonymous methods (includes support for closures)
- nullable types
- partial classes (good for code generators)

Not saying C# is the be all end all... in fact, I'm more partial to languages like Ruby. ;)

Re:Passe...

[mmusson]

I was actually looking forward to templates in Java but was disappointed once I saw the implementation of generics.

Every cast operation in Java is expensive because the VM invokes security code to verify that the cast is legal. Java generics don't allow you to avoid the implicit cast so you still get the performance hit. Generics only make the code look cleaner.

Template meta-programming is also a very important part of the modern C++ libraries and is also something that generics cannot do.

Re:Passe...

[Jon Pryor]

My apologies for the horrible look of the code samples. Slashdot won't let me use nice, short lines, as it results in lines which are too short. Gah! Apparently I need ~40 characters per line (average) to get past the @#$% filter... This has to be the most annoying filter I've ever come across; I've spent more time getting past the filter than responding to your question!

Iterators are similar to java.util.Iterator. C# iterators are compiler support for implementing the System.Collections.IEnumerator interface. For example, in Java you'd write:

public class MyIterator implements Iterator {
private String[] hw = {"hello", "world"};
private int pos = 0;
public boolean hasNext () {
if (pos >= 0 && pos < hw.length) return true;
return false;
}
public Object next () {return hw[pos++];}
public void remove () {throw new UnsupportedOperationException ();}
}

public void UseIterator ()
{ Iterator e = new MyIterator ();
while (e.hasNext())
System.out.println (e.next().toString());}

C# iterators make this much easier:

public IEnumerable SayHello ()
{ yield return "hello";
yield return "world";}

public void UseIterator ()
{ foreach (string s in SayHello())
Console.WriteLine (s);}

C# iterators are particularly useful when implementing your own collection objects. Google for them; they're very powerful.

Anonymous Methods are methods without a name, just like Java anonymous classes are classes without a name. Same basic idea, fewer braces. They also act as full closures; while Java requires that all stack variables referenced from an anonymous class be final, C# doesn't require this.

int n = 42;
EventHandler h = delegate {Console.WriteLine ("something happened:" + n);};
h ();

The above example is bad, but you can let your imagination run wild. This is very useful for event handlers.

Partial Types

allow you to split a single class definition across multiple files. This is useful to prevent > 50 KB source files (yech!), and makes it easier to have part of a class machine generated (by a GUI builder) and part hand-written. Some people hate it, others are ambivalent, but it can be handy:

// File a1.cs
partial class Foo {public int a;}

// File a2.cs
partial class Foo {public int b;}

Nullable types are primarily useful for database support in the .NET type system. DB types can be "nullable" -- not present. For reference types, this is easy -- use null. For .NET value types, this isn't possible, as value types can't be null. The solution is to introduce a generic class System.Nullable<T>, which can wrap value types such as int.

The C# compiler adds syntactic sugar to this, to simplify usage:

int? nullable_int = GetMyNullableInt ();
if (nullable_int.HasValue) /* use nullable_int */

Nullable types are more special purpose, but are useful for those who need them.

Ignore the rest of this: it's just garbage to get past Slashdot's wonderful "too few characters per line" problem: lk jfjdlkajdsfl;kja sdfl;kja fjklsafjd l;kj lasjd lkjds fl;kja sdflkajsd lkj afs lk jfjdlkajdsfl;kja sdfl;kja fjklsafjd l;kj lasjd lkjds fl;kja sdflkajsd lkj afs lk jfjdlkajdsfl;kja sdfl;kja the quick brown fox jumps over the lazy dog l;kajdsfl;kj;lkj l;kjasdilfj l;kjoiewqruq[op 0-9314u75 lkfjx ;lkajdsfmopiac un0p3u5n1-0329u kl 0a9u 3214o5ilj hello out there in tv land! q 09

Re:Passe...

[iabervon]

Actually, C/C++ had a lot of good ideas, but it took a while for Java to get them right. The new Generic Types add compile-time typechecking and remove a lot of typecasting without adding a huge amount of complexity to the language like C++ templates do, and without causing multiple copies of the code to be generated. Enums in Java are full-fledged classes of actual objects with methods, unlike in C where they are just markers (they are object constants instead of integer constants; no difference in efficiency for comparison). Static include is actually more like Python's "import", where you can skip the class name for some class statics. Formatted output is much the same, and was just waiting for other features. Varargs has strong checking in Java, unlike C; the called function can limit the type of the extra arguments, can find out at runtime how many it got, and can't run off the end of the set, because it gets them as a Java array.

Java, unlike C++, has a policy of putting features off to become future extensions any time the language team can't specify them right at the time. C++ is constantly finding that changes they need to make break things that they've been recommending. Java's main mistake so far has been that they didn't have arrays use generic types, so the two don't play quite right together. Of course, that was a matter of historical necessity, because Java wouldn't have gotten to the point where generic types were worked out correctly without supporting arrays.

Re:Passe...

[BorgCopyeditor]

Very effective productivity tool. Though he tended to use CAT 5 cable.

Ah, yes. The old "CAT-5-o'-nine-tails."

Re:Passe...

[Baki]

In Java5 you would write the C# iterator just about the same.

For example

for (Shape tShape : pList) {
System.out.println("X is " + tShape.getX());
}

Re:Passe...

[rreyelts]

Every cast operation in Java is expensive

I have my own fair share of criticisms to level against Java Generics (no support for primitives, no type reification which leads to bastardisms like Class<T> and limitations like no new T[], etc...), but the cost of a cast has to be the worst criticism I've heard yet to date. A cast is implemented as a single VM instruction (checkcast) which generally takes nanoseconds to execute.

Re:Passe...

[rreyelts]

No, autoboxing suffers an entirely new set of problems. For example, let's take a container, which is the most commom usage case of generics.

1. You will be forced to box and unbox upon every single access to that container. Boxing can be quite expensive, compared to simple operations, because it will usually involve a memory allocation - which can suffer even more under multiprocessor boxes due to heap contention.
2. Your container will use a much larger amount of memory compared to an array of primitives. Compare an int[] to a List<Integer>. The int[] will cost you 4*N bytes. The List<Integer> will cost you 16*N bytes - 4*N for the Object[], 8*N for the two-word object header for each Integer, and 4*N for the actual int value stored in each Integer.

For systems like mine, that store 100 million objects in memory, a 4X memory increase is hugely unacceptable, and the access penalty is also unacceptable. My situation is not uncommon, and it is the reason why libraries like fastutil exist and are so popular.

I think .NET is mostly a rip-off of the JVM with very little innovation, but they seem to have a much better approach to primitives, with JIT type-specialization

J2EE --> 1.3.1 still

[tezza]

If you develop apps targeted at Websphere 4, say, they're still 1.3.1 spec.

I look longingly at typed collections to save yet another ClassCastException on anonymous iterators. *sigh* oh well, maybe 6 years from now...

Fuel for th e flame war

[OhHellWithIt]

Scott McNealy got my dander up in the quotes in this Government Computer News article.

Well for us Apple elitist bastards

[antifoidulus]

we still gotta wait....come on Steve, get out of the hospital and give us our static imports and generics!

I just got my copy...

[melted keyboard]

Now let the slashdotting commence!

Stability/memory leaks

[B5_geek]

I have found that most (2 of the 3) Java Apps that I used have horrible memory leak issues. I can't let the computer run for more then 3 days or all kinds of funkyness begins (winxp).

I have been using Sun's JVM. I realise that the memory leaks are very likely the fault of the apps themselves, but it seems that the whole JMV is kinda flakey too.

Hopefully this new release works better.

Re:Stability/memory leaks

[Tojo-Mojo]

Java's garbage collection sort of creates a general laziness among some coders who don't clean up because they don't have to. Without effective clean up routines, like destructors, you commonly end up with a chain that can hold a lot of memory out that is being unused. All it takes is one pointer *ahem* reference to some object that contanis a reference to another, that contains an array... If you've got a few hashes and arrays in the way, it may be difficult to tell exactly where memory is being used, thus memory leaks.

Also, I don't know for sure, but would what happen if two objects referenced each other but nothing else referenced them. Would gc know to follow the links between the two and see that nothing in the main app is using them?

Re:Stability/memory leaks

[MemoryDragon]

Actually no, it is an app problem. Sun has introduced weak references way back in 1.3 to cope with that problem. And I have to admit, I never had any of these problems since 1.3
But it also could be that your program simply needs a tad more ram.
Following, check out the -Xmx and -Xms parameters of your application startup file and add more ram (java fetches 32MB in without any params and fills it up before it starts the GC for the first time) That might help.
But never count memory leaks out, they are very rare, but can happen if somebody has tangling references, pretty much the only case where the Garbage Collector can do basically nothing.
The VM itself is not flakey, I have a few servers running here, with an uptime of a year already.

Re:Stability/memory leaks

[joib]

Java should never have memory leaks...
All the memory managment should be done by the VM as far as I know...
unless there is some advanced stuff i'm just not aware of?


Not memory leaks as such, but "memory leaks" for all practical purposes. How? Well, if you forget to nullify references to objects you no longer use, the garbage collector obviously cannot reclaim that memory..

Re:Stability/memory leaks

[NoOneInParticular]

Also, I don't know for sure, but would what happen if two objects referenced each other but nothing else referenced them. Would gc know to follow the links between the two and see that nothing in the main app is using them?

Yes, Java's GC would notice that nothing is referring to them and remove the objects. This unlike a simple reference counting gc such as python's which would not notice this. Java's GC can even relocate memory on the fly to minimize page misses and avoid memory fragmentation.

Re:Stability/memory leaks

[XbainX]

Actually, under certain circumstances the JVM will reclaim non-null references eventually. But you will still experience memory leak type symptoms until either you run out of available memory or the non-null references are cleaned up...

Java supports various types of references, check here: http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ ref/Reference.html

Re:Stability/memory leaks

[smallpaul]

Yes, Java's GC would notice that nothing is referring to them and remove the objects. This unlike a simple reference counting gc such as python's which would not notice this.

Your information about Python is about four years out of date.

Re:Stability/memory leaks

[angel'o'sphere]

Java's garbage collection sort of creates a general laziness among some coders who don't clean up because they don't have to.

This is a missconception of yours. In Java, you CAN'T clean up. In C++ you say

delete x; x = null;

, in Java you just say

x = null;

Probably I should correct my sentence above: freeing memory IS CLEANING UP, nothing else, so all Java programmers clean up automatically.


All it takes is one pointer *ahem* reference to some object that contanis a reference to another, that contains an array... If you've got a few hashes and arrays in the way, it may be difficult to tell exactly where memory is being used, thus memory leaks.

Well, for a GC that is not difficult to tell at all. Not harder as for a human :D
In C++ somewhere somehow one had called delete. So at the point where in Java a hughe amount of memeory is referenced, and probably never used again, you have a dangling pointer in C++.

but would what happen if two objects referenced each other but nothing else referenced them. Would gc know to follow the links between the two and see that nothing in the main app is using them?

Of course, thats the point about garbage collection :-D

If you have a memory leak in java then it comes from things like that:

ArrayList vector = new ArrayList();
while (someObscureEndlessLoopCondition) {

vector.add(new SomeObject());

}

If you do somewhere something like this you will run into an OutOfMemoryException sooner or later .... but that problem is the same in all languages.

It is really no difference if one "forgetts" a delete in C++ somewhere or one forgets a x = null; in Java somewhere, but the Java program won't crash indeterministic, thats a difference.

angel'o'sphere

Re:Stability/memory leaks

[Brian Quinlan]

Yes, Java's GC would notice that nothing is referring to them and remove the objects. This unlike a simple reference counting gc such as python's which would not notice this. Java's GC can even relocate memory on the fly to minimize page misses and avoid memory fragmentation.

Python actually uses a generational garbage collection system that can break cycles to reclaim unused objects. It also performs certain optimizations to avoid unnecessary memory allocations and deallocations.

In Python, reference counting is a combination of a historical artifact and a performance optimization.

Re:Stability/memory leaks

[Dewin Cymraeg]

Not memory leaks as such, but "memory leaks" for all practical purposes. How? Well, if you forget to nullify references to objects you no longer use, the garbage collector obviously cannot reclaim that memory..

Have you guys never heard of scope?!

Re:Stability/memory leaks

[figa]

I ran into a fabulous memory leak just last week thanks to Sun. I wrote a client that was accepting messages and persisting them using ObjectOutputStream. I persisted about 40,000 HashMaps, and next thing, my client was using 200M. I wasn't building any lists of the messages, so I was stumped, and I broke out the profiler.

I was surprised to find that the ObjectOutputStream has a static HandleTable inside it that creates an entry for each HashMap that I put through, and it keeps a reference to each HashMap. I searched around, and this is a common problem that is not mentioned at all in the javadocs. You're supposed to reset the ObjectOutputStream periodically to free up the HandleTable. I had assumed that reset was like InputStream's reset and never would have guessed that it had to do with Object caching in the stream.

Re:Stability/memory leaks

[recursiv]

5 insightful?

As far as I'm aware, I don't think your entire app is supposed to be in main(). I normally don't ever nullify references, but my code is modular enough, (i.e. not all in main()) that objects go out of scope when they are no longer needed. This is one of the most ridiculous examples of a straw man argument I have seen.

Re:Stability/memory leaks

[StormReaver]

"...if you forget to nullify references to objects you no longer use, the garbage collector obviously cannot reclaim that memory.."

That's the whole point of the garbage collector:

a = new Class1();
a = new Class2();

The Class1() object will be picked up by the garbage collector and deleted (assuming the garbage collector is not broken).

a = new Class1();
a = null;
a = new Class2();

This defeats the purpose of having a garbage collector.

Re:Stability/memory leaks

[LadyLucky]

Wow, such flameage.

However, you are quite correct. It can be quite difficult at times to ensure that all objects are correctly cleaned up after usage. As soon as you introduce items such as HashMaps, etc, you run into potential for these problems.

We once had this issue when we embedded the mozilla javascript interpreter in our app. The problem was that you have to create a scope object, with all sorts of predefined classes and functions and so forth. This was expensive, so we pooled them. Unfortunately this left a memory leak, as objects declared in scope by the javascript itself would not tidy up at the end of processing.

Indeed it turns out the library has parent scopes, so we could create a new child scope cheaply each time, but the point remains.

Re:Stability/memory leaks

[joib]

a = new Class1();
a = new Class2();

The Class1() object will be picked up by the garbage collector and deleted (assuming the garbage collector is not broken).


Oh good grief. Isn't that blindingly obvious? Apparently not...

Perhaps I should have clarified my original comment by saying something like "nullifying references to reachable objects you no longer use", considering that my comment got, uh, about 10 responses which all totally missed the point. *sigh*

Yes, in most cases nullifying references is not needed since the application is usually designed so that objects go out of scope when they're no longer used. However, in certain circumstances that approach might not be enough.

Consider a situation like, say:

a = new SomeHugeClass(); // some very big object
b = a.doSomething();
a = null;
if (doSomethingElse(b)) {
a = new SomeHugeClass("foo");
} else {
a = new SomeHugeClass("bar");
}

Now, if doSomethingElse() takes a long time to finish (say, doing i/o or a heavy calculation etc.), or requires lots of memory, it might not be a bad idea to first nullify a, as in the example above.

Re:Stability/memory leaks

[fupeg]

The whole point was not "how does Java solve this super tough problem". The point was that it's not a hard problem and that anybody who knew anything about how garbage collection works would not make such a comment. Of course Slashdot is all about not knowing anything about a subject but making claims about it anyways. Mark and sweep is not the actual algorithm used by JVMs, it is just a simple algorithm that any programmer (and I use that term loosely) should know about from a data structures course. There are actually numerous gc algorithms used by JVMs, in fact you can specify different types of algorithms for the JVM to use based on the type of application and the type of hardware running the application. But do yourself a favor and try to learn the basics first.

Re:Stability/memory leaks

[Estanislao Mart�nez]

Presto, each object in the list references the next, therefore none have a 0 ref count and will be ignored by the garbage collector.

One algorithm to do GC is to go through every reference in your call stack, follow each of them, mark the object you reach as used, do the same for each reference in those objects, and so on (taking care to check for already-marked objects, so as not to fall into cycles). Then, you go through all the heap, and free all the objects you didn't mark.

This algorithm will successfully collect the circular list. I don't think Java uses this one algorithm, but the algorithms it does use will collect the cyclic structures just as well.

Release notes

[BlurredOne]

If any one is interested in reading the release notes, they can be found at http://java.sun.com/j2se/1.5.0/docs/relnotes/featu res.html

Stealing my tongue

[mukund]

I, for one, welcome our new virtual machine overlord.

Dude you know you are not supposed to say these things in the story itself.

Comment removed

[account_deleted]

Comment removed based on user account deletion

useful or bloat?

[N3wsByt3]

Well, some may call the 1.5 as being increasingly bloatware, but, why in some aspects this may be true, I think all by all there are considerable improvements over the former releases, especially 1.4.2.

JVM 1.4.2 (at least some sub-versions) were riddled with bugs, which, for instance, become apparent when people use systems that rely on it in a special way, as with Freenet. It comes as no surprise, that there were numerous reports of some errors on OSX and BSD, as well as on linux, when running JVM 1.4.2. For some time, we had to say "If you experience any difficulties, please try/revert to JVM 1.4.1 or 1.5.x and see if that solves the problem."

It is crazy to recommend reverting, but the main devls of java were unwilling to remedy the bugs in 1.4.2, claiming it was a Freenet-problem, while our devls said it was a JVM problem. Though it must be said some within freenet claim their is little to no problem with it (probably windows-users, or maybe some sub-versions that worked on specific linux-distributions). Anyway, my advice has always been, and will be (certainly in the light of the stable 1.5 release), to NOT use the 1.4.2, especially when using OSX or another 'nix based OS.

And also; be sure to get the JRE, and not the full SDK, unless you plan to develop Java software.

Re:J2EE -- 1.3.1 still

[tmasssey]

I've been disappointed with IBM's response to Java lately. The last version easily downloaded for Windows is 1.3. The only way I was able to get Java 1.4 for Windows was to download the MQ Series client (like 200MB big!) and pull the JDK out of that...

I wonder if IBM will have a 1.5 JDK? For a company that is putting a lot of juice behind Java, it seems odd that they don't make the JDK available to others...

The new for loop and type safe collections rock

[ShatteredDream]

The new For loop may seem to be just syntactic sugar, but it isn't. It really does make the code look a lot cleaner when you are iterating over a collection or an array. The type safe collections are also very handy--no more class cast exceptions and stuff like that.

It would be nice though if Sun would make Groovy or Jython a standard part of their java distribution. That would definitely make it competitive with .NET

Re:The new for loop and type safe collections rock

[DevCybiko]

The new For loop may seem to be just syntactic sugar, but it isn't. It really does make the code look a lot cleaner isn't that the definition of syntactic sugar?

Re:The new for loop and type safe collections rock

[julesh]

Carrying on down this path much farther, you become able to argue that C is just syntactic sugar for assembly language, and therefore assembly language is just as good.

Face it. Syntax matters.

Re:The new for loop and type safe collections rock

[cbiffle]

I both do and do not agree with this.

The new for loop most certainly is syntactic sugar. It's taking something we could do before and shortening it into a new construct.

However, a lot of folks use 'syntactic sugar' as a derisive term. It's not. It saves programmer time. Generally the times that it's bad are when it's (a) hiding what's really happening to a degree that introduces bugs, or (b) misguided, like SQL's attempts at being English-like.

It's out there!

[aug24]

Check out gcj, part of gcc (Translation: check out the gnu compiler for java, part of the gnu compiler collection).

I gave it a whirl about a year ago and it was fine, fine for the relatively simple stuff I experimented with.

J.

Re:J2EE -- 1.3.1 still

[robbyjo]

Are you sure? J2EE is 1.4 already.

The language wars never ceases to amaze me

[nhnfreespirit]

In typical /. style, as soon as Java is as much as mentioned, everybody expects the flame wars to erupt, and they always do...

I try to stay pragmatic about the programming languages that I use. For some jobs, Java would be my last choice, and for some it seems a natural fit. When writing hardware near code, or platform dependant stuff on driver level, nobody in their right mind would attempt to use Java. For high level rapid prototyping, Java is a often a quick and easy way of getting things done.

Re:The language wars never ceases to amaze me

[BigGerman]

The biggest problem with Slashdot Java flaming is that people do not realize what Java is.
If you compare language to language, say Java to C, C# or even Ruby and Python, it is easy to see why Java is "slow" and "bloated". But Java is to be compared to something like .NET and not just a language.

Java is a platform. Java provides on-the-fly class loading and verification including digital signing of the code, very fine-grained security model (you can create your own sandbox with whatever security rules you want), first-class GUI (fast and responsive if you know what you are doing), tons of class libraries, enterprise APIs (which, minus ill-fated EJBs, are very popular), crypto and much more.
So the only "other" platform of similar mugnitude is .NET and this is what you need to measure Java against.

Re:Nice language... bad interface

[smari]

No.. say I want to port Perl to my ToasterOS. I download Perl, compile it on ToasterOS (Presuming ToasterOS has all the prerequisites), and voila.

Java is not open source, hence I do not go around compiling it anywhere.. I just wait and hope that Mr. Star gives a yellow light on the project.

Re:Still no operators...

[timbloid]

> ok, it got faster, but still not as fast as C++ too.
> I guess this will finally come but when ?

Errr...

Java 1.4 was comparable in speed to C++ (except obviously for Trig which got a huge overhaul in 1.4 and slowed down some)

It really depends how you write you code... Sloppy C++ code can be slow too.. ;-)

hmm. but how does this compare with Mono

[ancice]

Nice that Java VM is now faster; it's one of the major drawbacks of java on the desktop. But how does this compare with the new and shiny Mono? Mono with its distributed system, and if it still beats Java, then java is in for a tough fight.

Write once, run anywhere

[Anonymous Writer]

Java had all this hype about it when it was promoted nearly a decade ago, but it never got anywhere close to the point where you could walk into your local computer store and buy a major software package that could be run on any platform. I recall that Corel was going to attempt to release a WordPerfect that ran using Java, but that's the most I heard of it being adopted by mainsteam software developers. Does anyone think it will ever take?

Re:Write once, run anywhere

[Cederic]

Rather than mod you troll, here's a simple answer.

>> Does anyone think it will ever take?

What makes you think it hasn't? A single example: What percentage of Apache Foundation products are written in and/or for Java. Note that Apache Foundation products are used extensively in Enterprise software development, deployment and systems.

~cederic

Re:Write once, run anywhere

[qodfathr]

Well, what about something like Oracle JDeveloper? Here's a very complete and modern GUI IDE, written in Java, which runs unaltered on many operating systems.

Maybe you can't find it on the shelf at a retail computer store, but it is a for-purchase product. (Free to download and play with, of course.)

Re:Write once, run anywhere

[DevolvingSpud]

How about Borland JBuilder? That's a big, powerful IDE, and I'd consider it a successful commercial product. Also, from the games side, Puzzle Pirates is a Java game, and good chunks of Chrome are Java. Oh yeah, plus about a billion cellphone applications.

Re:Write once, run anywhere

[Anonymous Writer]

Rather than mod you troll, here's a simple answer.

I honestly wasn't trying to troll. If you walk into a computer store and look at all the off-the shelf consumer-level software products, they're all for Windows. I was hoping that Java would have changed this so that you can buy one of these off-the shelf products and run it on any platform. I know that it has gained acceptance at the enterprise level, I was actually referring to the consumer level.

Bytecode Compatibility

[Brian Blessed]

I thought that the compiled Java would remain compatible with the bytecode format used by previous versions. However, this seems not be the case and I get this message:

java.lang.UnsupportedClassVersionError: HelloWorld (Unsupported major.minor version 49.0)

Whilst code that uses the new language features must obviously be compiled with the v1.5 JSDK, this means that it must also be run on the v1.5 JRE.

This may inhibit the use of Java 5 by projects that want their programs to run on a v1.4 JRE.

- Brian.

Re:Bytecode Compatibility

[Z-MaxX]

You need to use the "-target 1.4" option to javac to tell it to produce the older version of class files.

Re:Bytecode Compatibility

[Cederic]

I would hope that 1.2, 1.3 and 1.4 bytecode would run in the 1.5 JRE. I think it's ambitious to expect 1.5 bytecode to run in a pre-1.5 JRE - the language has new features that such JREs don't know about or support.

While you could obviously write code that interprets 1.5 bytecode so that it will run on a 1.4 JRE, and make it possible to automagically create that code at compile-time, including it by default in the compiled 1.5 code would be wasteful as it's not required to run in a 1.5 environment.

So yes, it will inhibit the use of Java 5 by projects that wish to run on JRE1.4. And trust me, I'm extremely distressed that my company is still stuck on Weblogic 6.1 as that only works with JRE1.3, so I haven't even been able to make use of J2SE 1.4 capabilities in code, but life goes on.

~Cederic

Re:Bytecode Compatibility

[angel'o'sphere]

(i.e. you can't have "-target 1.4 -source 1.5") . Yes, you can have it!
But what about your classpath, does it reference the 1.5 JRE? E.g. if the 1.5 java.lang.String gets loaded by an old JVM you might get that errro as well.
angel'o'sphere

Re:Bytecode Compatibility

[julesh]

I thought that the compiled Java would remain compatible with the bytecode format used by previous versions.

The bytecode format is still identical. The version number on the file was incremented because classes that depend on assertions could break badly if used on a JVM that doesn't implement them (which is actually a feature of a few classes in java.lang, not a bytecode interpreter feature). Use the '-target' commands recommended by the other posters whenever producing code that doesn't rely on one of the new features.

Re:Bytecode Compatibility

[rreyelts]

It has been known for a long time (over a year), that Java programs compiled for 1.5 will not run on a 1.4 VM. However, you can use tools like Retroweaver to get 1.4 compatibility. It rewrites the bytecode of your version 1.5 class files into the 1.4 VM format.

mod parent down

[hruntrung]

That's not interesting, that's cliche. People have been saying that for years. Let's be honest: virtual machines are where business code is going, and business code (enterprise applications, server side stuff, etc) is the primary focus of Java these days. .NET is a clear indication that this trend is a real one, and that that's where the industry is heading.

No, I don't think you should write ls or grep in Java. However, I'd say that you also shouldn't be writing an invoice processing system in C or C ++.

Man, that's not really fair

[mcc]

Considering that nearly 100% of the justification I've heard from people who like C# is along the lines of "It's not Java".

...

Come to think of it, this entire situation is sort of starting to sound like, um, something else...

Re:Man, that's not really fair

[$RANDOMLUSER]

Right. Those Java checked exceptions are so "confusing".

Re:5 or 1.5?

[Cederic]

Fairies have wings, not tails.

I agree though, the naming of Java is consistently confusing. Should I upgrade from Java 2.. err.. J2SE.. err.. Java 1.3.1_08 to Java 5 or to Java 1.5 or indeed Java 1.5.0. Oh, and is J2EE 1.4 compatible with this new one?

It could be much simpler..

~Cederic

Re:Still no operators...

[timbloid]

> Its' not the case in Java where it sounds like there's only 1 way to do each thing

I take it from this comment that you haven't actually tried java. You can "explorate" to your hearts content, and there are many ways of doing the same thing (some obviously better than others)

> mostly because of the plethora of APIs (WebLogic, etc.) that corporations force you to use over it...

Now this comment just has me bamboozled... You mean that Weblogic holds sway over you and force you to code in one way over another? Surely weblogic is just an appserver? Which runs code designed to the standard J2EE API spec? The same as using Tomcat , JBoss or Geronimo or even Hibernate? (All of which are free and opensource, and follow the same J2EE spec that Weblogic does -- they just solve separate parts of it, and can be combined to do it all if you require)... I fail to see how this is a corporation forcing you to use one method of coding?

Sure, if you are only going to look at one way of achieving your goals, then there is only one way to go...

Dear Sun

[mindaktiviti]

Please make your Windows (XP) Java run time environment download available on the FRONT PAGE or at the most 1 click away. Your latest website is very tricky to navigate and very annoying and what's the point of taking a Java class (which I'm currently doing) when the majority of Windows XP users don't even have the fucking run time installed by default (damn Microsoft!). I mean look at this mess. It's 5 clicks to the .exe file! Who is Joe Schmoe going to know what the hell a "run time environment" is when they're NOT EVEN interested in Java, except in the software they want to install! (i.e. Azureus bittorrent client). Please add a image button (so people see it, make it big and pink or red if you will) that says something like "Windows XP users DOWNLOAD to run your favourite Java applications!" Thank you. Yours Truly, Typical-Family's-Free-College-Long-distance-Tech-S upport.

Re:Dear Sun

[shaka]

Go to the consumer-branded website: http://java.com

Um... I've been a Java developer for about 5 years, and I've never seen that website. Now, can someone please tell me why Sun has put fscking RINGTONES on their Java site!?

Re:Dear Sun

[iso]

Why don't you try this?

1) go to java.com
2) click the big "get it now" button
3) download the EXE

Now quit trolling.

Re:hmm. but how does this compare with Mono

[MemoryDragon]

Sorry, Dude, but the Java VM still is faster than .Net and Mono is significantly slower than .Net (since it is just a basic VM with a basic jit and no runtime optimization)

Despite the having a slower VM, the .Net programs sometimes can be faster than java programs because they are heavily integrated into windows wheras java has to add abstraction layers for not losing portability.

But back to Mono it will probably never be able to catchup speedwise with .Net unless they move to another VM which is maintained by a dedicated team (parrot comes to mind) but then they will lose compatibility on binary level to .Net (which is not really there anyway since Microsoft plays cat and mouse with them on a classlibrary level)

Is it C# yet?

[LibertineR]

Metadata attributes? Generics support?

In Java you will not see any performance improvement; the reason is well explained by Anders Hejlsberg (lead C# architect) in http://www.artima.com/intv/generics2.html :
"For example, with Java generics, you don't actually get any of the execution efficiency that I talked about, because when you compile a generic class in Java, the compiler takes away the type parameter and substitutes Object everywhere. So the compiled image for List<T> is like a List where you use the type Object everywhere. Of course, if you now try to make a List<int>, you get boxing of all the ints. So there's a bunch of overhead there. Furthermore, to keep the VM happy, the compiler actually has to insert all of the type casts you didn't write. If it's a List of Object and you're trying to treat those Objects as Customers, at some point the Objects must be cast to Customers to keep the verifier happy. And really all they're doing in their implementation is automatically inserting those type casts for you. So you get the syntactic sugar, or some of it at least, but you don't get any of the execution efficiency. So that's issue number one I have with Java's solution."

You can argue with Anders, but then, you would be wrong.

Re:Is it C# yet?

[MemoryDragon]

No Hjelfsberg is totally right. The extensions are syntactic sugar. But still they are useful, because, you gain coding efficiency that way. Autoboxing, foreach, generics are all implemented in a way not to break the byte format, but you still need less code for doing jobs like iterating lists fetching elements from data structures and so on. Day to day stuff which you used every 10th line or os.

Priority #1 for Sun was not to break the bytecode format. Priority #2 was to ease the life of programmers

The only thing which really will make a difference on code generation level will be the meta data, this one will make life easier for the implementors and for the users of servers. Soap instantly comes to my mind with the C# like @webmethod metadata. No more post and precompilers for doing that stuff, yiehaa.

Hjelfsberg is a smart guy, although I dont share his views on unmanaged exceptions, he is dead right with his comment on this.

Re:Is it C# yet?

[jonabbey]

A C# fan accusing Java of copying?

Excellent. Go Sun, Go!

Re:J2EE -- 1.3.1 still

[koehn]

First off, Websphere 4.0 is J2EE 1.2 only. You need Websphere 5.0 to get to J2EE 1.3.1. In Websphere 5.1, you at least get JDK 1.4, and a few J2EE 1.4 tidbits (JSTL 1.1, for example).

However, your ClassCastExceptions will only get bumped to compile time in JDK 1.5, true. But I must admit that in eight years of Java programming, I've never had this particular problem where it didn't take more than a few seconds to find the source of the bug.

I really just want the metadata stuff (which was obviously ripped off from C#, but it's a great idea). That, and EJB 3.0, which gets rid of the stupid deployment descriptors.

Metadata is the coolest new feature in 5.0

[jg21]

In an interview given just last night, the spec lead for 5.0 is asked what in his view the coolest new feature of the language is. Calvin Austin replies: If I just restrict myself to the language it would be metadata (JSR 175). We've only scratched the surface of its potential. For the platform, it's a bytecode insertion for profiling (JSR 163).

Swing on OpenGL

[tesmako]

One of the new features of Java 1.5 that has not been mentioned much yet is the OpenGL acceleration of Java2D (which underlies Swing and AWT). Adding the flag

-Dsun.java2d.opengl=true

(or by setting the system property in the program) makes pretty much all Java2D calls go directly into OpenGL.

This does indeed work too, I have played around with it and graphically intensive Swing applications really fly with OpenGL activated (given that your graphics card and drivers are sufficiently bug-free and modern). Read about it here

And yes, it does work under Linux, and Windows and Solaris (and most likely will under OS X, though that is up to Apple to implement).

Even without OpenGL acceleration the Swing responsiveness improvements are very impressive, coupled with the much better both default theme and theme mimicking in 1.5 I'd say it is time to retire the Swing troll.

Re:Swing on OpenGL

[Anonymous Coward]

This didn't work for me with beta2 or RC on windows or linux on two different machines both with NVIDIA cards and binary drivers. The OpenGL pipeline was enabled (see output with -Dsun.java2d.opengl=True, note capital T), but it ran very very slow and with corrupted images.

Just tested -- doesn't work on the release version of 1.5 either.

Re:Swing on OpenGL

[LDoggg_]

The openGL feature is really cool.
Any idea if there's a way to turn this on or off programatically?

Having this on the command line is ok, but if someone is using Mesa3d(software openGL on Linux) instead of hardware acceleration, it will be slower than the default rendering path of X11.

Here's a screenshot of my JTurtle application running on accelerated openGL with jdk1.5 and using the new look and feel.

Re:Well, since you people ask this....

[pottymouth]

Here's why:

http://www.joelonsoftware.com/articles/APIWar.ht ml

If you like C#, VB and .NET that's fine. Unfortunately MS's revenue stream requires that they change your environment on a regular basis. In my opinion that's the worst thing in the world for professional developers. Proficiency comes with experience and if you shift the syntax and grammer around on me every couple of years it's pretty hard to get really good at anything. At least Java is, pretty much, the same now as it's always been for nearly 10 years. Can you say that about VB?

I love the hate

[Featureless]

You can't hate any language as much as some people hate Java until it's really reached critical mass.

There are two things that make any really big language a target: 1) people start using it for everything, including things its not suited for. 2) junior folks without a lot of compiler or cross-language experiences will cut their teeth on Java, and at that point in one's career it is sometimes considered cool to blame a bad application's flaws on the language it's written in.

Java has plenty of problems. There are brilliant essays written on it; some of them by Sun engineers. But the complaint linked to in story was so bad by comparison, however, I doin't feel offtopic in addressing some points it raised:

there are a thousand "super-efficient" .jar libraries required by a "Hello World" app

No.

it takes 12 objects instantiated in 4 containers to flip a bit in a byte

Oh, I see. You're flipping bytes.

there is the substitution of native performance of compiled code to code compiled "Just Too Late" combined with exceptional memory usage that entails

The VM is more work. Strangely, you will have trouble finding benchmarks that make other comparable high-level languages look way faster than Java on the same _non-user-facing_ application.

As always, code in C, assembler, or another specialized language if you really need to.

The speed thing is well-addressed elsewhere. Enough said for now.

we get the garbage collector which is scientifically fine-tuned to run just when user is expected to interact with the application in most time sensitive manner

People love to bitch about client-side Java. It's as if all the flaws they're used to from other client side systems are fine, because they're used to them, and every foible of Java is worth agonizing over as if it were the worst thing in the world.

I dunno what else to say, but I wrote an enormous graphic-intensive video game in it and it runs fine. And what I did is nothing; somebody cloned the QIII engine to the point where it plays actual Q3A maps (with multiplayer) at respectable framerates.

Once again, someone shows me a shitty client app written by a team of 30 22 year olds in Thailand and claim it's proof that Java sucks. Congratulations.

multiple, insideously incompatible with each other, versions of the so-called "universal" VM

Yes, leaving aside the fact that Microsoft deliberately broke VM compatibility. Not just in one or two big ways. In a lot of little ways. As in on purpose. Great example. Very honest.

There is a giant test suite. Gets better all the time. Reputable VM's pass it. Most of all, though, I just don't run into the cross-VM problem in the first place unless I'm doing 1.1 development for browsers, see above...

We actually abandoned DB2 8.x release because noone could deal with the havoc the DB2 admin tools were causing with various other retarded banking related Java apps.

There we go. The truth outs. You overpaid for a shitty product. Congratulations. You can do that in C or Fortran, too.

Blame the language, though. Don't blame yourselves for picking a bad app.

Oh well, time to have me shot on sight.

Have a nice day.

Re:I love the hate

[renoX]

> You can't hate any language as much as some people hate Java until it's really reached critical mass.

Untrue, there is no need to wait to hate Java, I tried Java in 98-99 and hated it, its libraries were full of bugs (Swing, the GC was leaky on 1.1.8) and you spent your time working around the bugs.

Re:I love the hate

[moonbender]

IIRC the Q3 port was the topic of a Slashdot story some weeks ago. ...

Here it is.

Re:I love the hate

[IgnoramusMaximus]

First a disclaimer, I wrote the original post you seem to quote. I do not write Java apps and although I was mostly facetous, here is why I said those things:

there are a thousand "super-efficient" .jar libraries required by a "Hello World" app

No.

Well it certainly feels that way when you try to load those apps. They all have excruciating startup times. Perheaps I am wrong and instead they check the integrity of my bank account or weather in China for my convenience. I dont really care, but 5-6 seconds of startup for a few boxes of interactive input is not really acceptable.

it takes 12 objects instantiated in 4 containers to flip a bit in a byte

Oh, I see. You're flipping bytes.

I do not write Jave apps but I am quite familiar with OOP and also with the great zeal Java disciples apply it to everything. Like every other paradigm, one-size-fits-all applied to extremes allways results in the effects I described. My comment was to illustrate that if you go nuts and have hundreds of objetcs, events and containers all over the place, you are bound to end up with huge overhead. This is not restricted to Java by any means and many a C++ library suffers from the same issues. Java from what my (cursory I admit) glance at the language/libraries takes this to just such extremes.

there is the substitution of native performance of compiled code to code compiled "Just Too Late" combined with exceptional memory usage that entails

The "Just Too Late" was just a pun on the hype JIT is endowed with. The memory requirement (if you had read the thread where the original post was made) was confirmed by just about anybody including those who advocate Java. As I explained in there, if you have a 10-15 meg per JRE + 10-50 (memory managment seems to suck badly for the apps we use) per instance of an application (no way an OS can share DLLs or .so's here) in a multi-user environment, and this caused by 4 lines of input, ridiculous e-commerce apps, one has problems. Remember, I am not a Java theorist. Merely a user of apps written in your favourite cure-all language.

multiple, insideously incompatible with each other, versions of the so-called "universal" VM

Yes, leaving aside the fact that Microsoft deliberately broke VM compatibility. Not just in one or two big ways. In a lot of little ways. As in on purpose. Great example. Very honest

I dont care who broke whose toys. As far as I (the user) am concerned, the whole Java thing is an umanagable, deployment and maintenance-wise, mess. If I am forced to let people download and install JRE's du-jeur for each e-commerce craplet out there, this is far worse then any other "client side" app. Also as I indicated in my posts, all of these Java apps fail miserably because their purpose can be accomplished by much simplier and more reliable means: plain HTML with smart server-side processing. That would mean no client-side pandemonium for anyone. Java was hyped as a soultion to deployent of seamless, headache-less OS independent client side apps, and in my user experience it turned out to utterly fail in this area.

We actually abandoned DB2 8.x release because noone could deal with the havoc the DB2 admin tools were causing with various other retarded banking related Java apps.

There we go. The truth outs. You overpaid for a shitty product. Congratulations. You can do that in C or Fortran, too.

Besides rather flippant attidude, your thinking is simply wrong. Not only I have this problem with DB2, others have with Sun (Java's maker) admin tools and Oracle DB tools. But all of this is besides the point because the main place we use Jave in is also crap. Crap in many smelly varieties from many sources. While you might be a guru capable of writing 3D games and Self-conscious AI systems in Java, this is not what Java was advertised to us poor business sods for, and that which it was advertised for noone seems to be able to make work. And that is all I care about. Unfortunately for you, as I mentioned in another post, we the users will have the final word on this, not you in your Java 3D castle Mr.Java Wanker. Trust me on this one.

Re:I love the hate

[greg_barton]

it takes 12 objects instantiated in 4 containers to flip a bit in a byte

I'd love to see a code example for that.

Here's mine:

byte aByte = <some value>;
int indexToFlip = <some value>;
aByte = aByte ^ (1 << indexToFlip);

Leave the declarations out and it's one line. Regardless, there are no objects or containers involved.

Are the rest of your assertions so flimsy?

Re:I love the hate

[Featureless]

I wrote the original post you seem to quote

Well, I left you a message to tell you I quoted it, so hopefully it's not a surprise.

5-6 seconds of startup for a few boxes of interactive input is not really acceptable.

Thus, using Java for a few boxes of interactive input is also unacceptable.

The startup times are slow. That's one of the real problems I was talking about - one, in fact, lamented from within Sun. For VMs that have this problem, this limits their usefulness a bit.

Hasn't stopped the language's implacable advance, though. Let's see, do you know why? "Because 90% of the time, nobody gives a shit."

I did not miss your attempt at humor. I am saying saying it was a bad attempt - misleading, not really illustrative.

one-size-fits-all applied to extremes allways results in the effects I described. ... Merely a user of apps written in your favourite cure-all language.

Did you read what I wrote? I will repeat it, with emphasis:

"...things that make any really big language a target: 1) people start using it for everything, including things its not suited for..."

Do you really need to continue to manufacture the straw man that someone thinks Java is the right language for everything, in order to have a point?

if you go nuts and have hundreds of objetcs, events and containers all over the place, you are bound to end up with huge overhead.

Congratulations, sir. You are a computer science genius.

Java from what my (cursory I admit) glance at the language/libraries takes this to just such extremes.

You have just saved me the trouble of pointing out that you are apparently ignorant about the system. The balance of abstraction and efficiency in the java architecture is actually surprisingly good, and I would say better than most other comprable systems.

But of course, you seem to like writing Gameboy games, or device drivers, or something. Yes, keep jamming the square peg in the round hole. Damn that naughty peg. It never fits. It's the peg's fault.

The "Just Too Late" was just a pun on the hype JIT is endowed with. The memory requirement (if you had read the thread where the original post was made) was confirmed by just about anybody including those who advocate Java.

You segue from JIT to memory too quickly for someone really familiar with VM or OS internals. Something tells me you're not the kind of guy who looks at how big the resident set is when he checks memory usage.

The JIT works very well. The garbage collector works very well. For overall memory usage, Java has room to improve.

Yet strangely, the language is so popular. Why? "Because 90% of the time, nobody gives a shit." We've already GOT RAM. what we needed was a clean, well-organized high-level language, and the trade was just what the market wanted.

Better yet, this is not necessarily a problem with Java as much as with VM implementation, as the wide usage of Java in consumer and embedded devices conveniently underscores, it is not necessary to have high memory overhead; this is the result of the major VM vendors trading memory for speed in products aimed at the workstation/server market. As time goes by the RAM overhead can be improved (by Sun or by the market picking up the slack), if the market wants it.

a 10-15 meg per JRE + 10-50 (memory managment seems to suck badly for the apps we use) per instance of an application

So, how many simulatneous VM instances do you typically run at once, comrade?

I dont care who broke whose toys.

When selecting a platform, language, or implementation strategy, I can see how you would consequently run into some trouble.

If I am forced to let people download and install JRE's du-jeur for each e-commerce craplet out there, this is far worse then any other "client side" app.

Golly,

Re:I love the hate

[Featureless]

In other words, it's possible to write shitty code in either Java or another Object Oriented language, so it's off to the firing squad for everybody!

Stand and salute the logic!

Re:I love the hate

[IgnoramusMaximus]

In other words, it's possible to write shitty code in either Java or another Object Oriented language

Quite true although it is not humanly possible to have more hype, hot air and hubris in any other language other then Java, C# being second close contender. Why if one were to listen to what we are being told, one cant possibly write bad code in Java for the language is divine and one's hand is guided with certainty by the fairies of object-oriented-pointerless-bliss.

Re:I love the hate

[IgnoramusMaximus]

30 shitty applications. That's the sample you've built this thesis on? That's it?

I will keep repeating ad nauseum that those are the only applications that count to me and many businesses that use them. That is a 100% of a sample of a Java apps that are shitty. Either all of those were written by poeple have no clue what they are doing (unlike all of those wonderful mythical apps always deployed somewhere else and written by enlightened geniuses) or the Java snake oil is just that.

and I am starting to wonder how much experience you have in general, because what I'm conspicuously not hearing is X and Y and Z systems are way better for A and B and C. Just vague generalities about HTML forms and (I think?) coding in C? Or do you perhaps favor VBScript?

Since you are getting more incredibly fanatical and blind by the minute, let me spell it out for you as clear as I can:

For e-commerce, OS/browser agnostic plain HTML on the browser is the only sane way to do anything because it does not rely on any client capablities other then ability to render HTML. No deployment issues, no maintanance costs. Java (and ActiveX and C# and similarly retarded ideas) is a way to create deployment issues and thus support costs and thus employment for countless Java tweaker monkeys. Something dear to your heart no doubt.

For applications that must run on thick-clients (I sure hope due to CPU usage because any other reason in a corporation is plain retarded) one can use native code just fine because: vast majority if C or C++ or any other language programs need only to support very few platforms in their entire life span and the effort to optimize that program for these platforms is well paid for by removal of integration and thus support issues. But such need is extremely rare because vast majority never leave a single platform. A Windows Java app will never run as well as a native Windows app neither will unix Java app run as well as a native unix app. This is not even up for discussion. The most convoluted of JITs and what nots are still overhead over native code and I will not even entertain any moronic discussion on that topic no more that I will entertain discussions of how you can make 2 and 2 equal 7.

I regret to inform you that you are full of shit.

I regret to inform you that you are just a priest of yet another silly language who has no clue who pays his bills. VB apps are everywhere in business, far more so then Java ones. These numbers are representing current jobs, corresponding to a peak in a cycle of a fad, VB waning hard (previous fad), Java peaking (current fad) and C# just coming up. I am fully expecting to have this very same retarded conversation with a C# priest, in, oh about 4 years time.

You sound confused. Are you saying it's easier or cheaper to write native applications? That natives are more secure? Are you happy with all your current native applications?

No it is you who is utterly confused, something about a theory whereby the Earth is flat and supported by Java beans. To spell it out for you again (I will resist an urge to use large letters): Native apps are easier to write (many decades of experience and tools), run better (many decades of OS design and integration of apps with the OS), cheaper to write and support because they use proven framework and tools, they integrate well with the user environment, have better performance (even the not so well written ones) and the so called "write once, deploy everywhere" is not only unnecessary but is more accurately described as "write once, debug and crash everywhere". Are they more secure? Depends what kind. The "no client side, java-less, HTML only e-commerce"? Most certainly. The locally deployed, locally networking native apps? They are not any more vulnerable then the OS itself. Are we clear now, Your Beanness?

nobody sees the world ending but you, all those students and professors, all those magazines and newswpapers and Fortune 500 compan

Eclipse 3.1 betas

[trajano]

The Eclipse 3.1 betas support 1.5 constructs. I normally use the integration builds.

Re:Eclipse 3.1 betas

[Mechanik]

Now we just need to be able to build Eclipse itself using Java 1.5. I really really want to use 1.5 in my Eclipse plugins. I want real container classes dammit! :-P

Currently you probably could build Eclipse using 1.5, but the Eclipse release engineering folks are still building using 1.4 (or at least, they were as of a month or so ago, and I haven't seen any mailing list traffic to the contrary). There won't be any official builds of Eclipse done with 1.5 for a while yet I think.


Mechanik

Ad seen on Monster today

[phyruxus]

Java Developer needed. Must have 3+ years experience with Java 1.5, to start immediately.

Re:Still no operators...

[fatphil]

Your link points to this obvious nonsense:

"""
Consider what happens when you do a new/malloc: a) the allocator wanders through some lists looking for a slot of the right size, then returns you a pointer. b) This pointer is pointing to some pretty random place.

With GC, a) the allocator doesn't need to look for memory, it knows where it is, b) the memory it returns is adjacent to the last bit of memory you requested. The wandering around part happens not all the time but only at garbage collection. And then (depending on the GC algorithm) things get moved of course as well.
"""

The guy knows nothing about _either_ efficient dynamic memory allocators, nor garbage collectors, he has no right to pass comment on them.

FP.

Okay, I'll Bite (a.k.a. "A Java Flame")

[mattdm]

I work on a minor, highly targetted Linux distribution. I'd love to include Java, and I actually get a lot of requests for it. But, here's an excerpt from the license agreement you'll find if you look to download the software:

B. License to Distribute Software. Subject to the terms and conditions of this Agreement and restrictions and exceptions set forth in the Software README file, including, but not limited to the Java Technology Restrictions of these Supplemental Terms, Sun grants you a non-exclusive, non-transferable, limited license without fees to reproduce and distribute the Software, provided that (i) you distribute the Software complete and unmodified and only bundled as part of, and for the sole purpose of running, your Programs, (ii) the Programs add significant and primary functionality to the Software, (iii) you do not distribute additional software intended to replace any component(s) of the Software, (iv) you do not remove or alter any proprietary legends or notices contained in the Software, (v) you only distribute the Software subject to a license agreement that protects Sun's interests consistent with the terms contained in this Agreement, and (vi) you agree to defend and indemnify Sun and its licensors from and

(Yes, it really does just end abruptly without finishing the sentence. That trailing "and" there doesn't lead into the next section; it's just not done. Obviously I'm the only one who bothers to read these things -- *including* the people at Sun. Anyway....)

My wish to give the software to my users fails almost every test....

i: I don't want to distribute it for the "sole purpose of running [my] Programs". I want to distribute it so people can run other people's programs, including possibly their own.

ii: uh, well, actually, my "Programs" don't add any functionality to Java, let alone "significant and primary".

iii: oops, I include gcc, which has a Java compiler. And I'm definitely not going to drop that.

iv: ahh, now this one I can agree with -- fine keep your copyright notices, etc.

v: my distribution as a whole is under the GPL. I'd have to run this by our lawyers, but this looks like it'd conflict by requring additional restrictions (even if I could get special dispensation to deal with the other issues).

vi: I don't really have the resources to defend and indemnify Sun "from and", even if I wanted to, thanks.

And frankly, that's why I wish people would stop writing things in Java. It's a pain to deal with. I want to make everything as slick, integrated, and as easy as possible for my end users. Sun makes that impossible for Java applications. If you want your code to be easily integrated and made available to users like mine -- and really, that's users of any Linux distro targetted more broadly than the super-geek sector -- please don't use Java. If you must, at least design it to work with gcj instead of Sun's virtual machine.

Unless Sun changes the license terms, their Java can never fill the "write once, run anywhere" goal -- but cleanly written source in an open language can.

No you can't run it anywhere you like!

[aug24]

You can only run it on a machine with a perl interpreter on board. Now tell me exactly how that is materially different to Java?

Justin.

Re:J2EE -- 1.3.1 still

[badmonkey]

IBM no longer ships standalone JDKs- according to the license with SUN, they only ship JDK included in a product. IBM will definately have a 1.5 JDK, just don't hold your breath.

Rapid learning

[GeekDork]

As much as I might hate Java, I repeatedly have to throw this one thing into the fray: I had exactly zero former experience with network programming, and still, I was able to produce a basic telnet-like application in under 30 minutes, using only the Java API doc and some logical thinking. And I only had a very brief introduction into the language. Transferring this to C (although the basic structure is exactly the same with BSD and Java sockets) took me about a week, with all those damn low-level error conditions.

Re:Rapid learning

[tdrury]

Sir, I regret to inform you that you've demonstrated "critical thinking" within a hostile forum. You are no longer allowed to read Slasdot. Move along.

Joking aside, it kills me to see the amount of research and due-diligence that goes into debunking a Microsoft-sponsored benchmark, but when it comes to Java most everyone starts spouting nonsense. People will remember their experiences from 8 years ago, or a bad app, etc. and immediately conclude that Java must suck for every conceivable application.

Java is a tool - no more, no less. Use it where you think it is useful and leave on the shelf if you don't think it will help solve your current problem. Most mature developers know when and where a tool should be applied.

Re:J2EE -- 1.3.1 still

[Cederic]

Help me out here. Are you after a specifically IBM implementation of the Java VM for Windows, or is there another reason why you can't go to http://java.sun.com/j2se/1.5.0/download.jsp and download the Windows version from there?

No intent here to flame, just curious about your reasoning..

~Cederic

Performance improved? Not in my experience...

[znerd]

I did some tests to compare Java 1.4.2_05 with JDK 1.5.0 and I found that 1.4.2_05 is considerably faster when building a project. This mainly involved XSLT processing and Java compilation.

Test I did: Run 'ant -lib lib checkstyle java' on XINS 0.207)

Preparation command:

rm -rf build

Timed command:

time ant -lib lib checkstyle java

I did 3 tests in a row for each Java version. I added the 'user' and 'sys' times and the averaged then. Results on my Gentoo Linux system with 2.6 kernel:
Java 1.4.2_05 34.5s Java 1.5.0-rc: 42.9s Java 1.5.0: 41.6s

Just adjust the GMT offset in your resume

[Anonymous Coward]

for the dates of experience with Java 1.5. It should be something like

Start: Sept 1999 -2628000
End: ... ...

If they ask who your employer was at the time, just tell them you haven't yet notified that employer that you intend to resign yet. It'd be all true. No need to lie. Oh and if they ask what that -2628000 is, tell them it's just a MS Word revisionist code.

They fucked up Java

[vegetasaiyajin]

Java was a good, simple language. You may not have liked it, but you couldn't deny it was a simple language with an elegant C-style syntax.
Now they added a lot of features that are nothing but crappy compiler sugar. Most of them badly implemented.

1. Generics: They couldn't make it worse here. You cannot use reflection effectively because the type parameter information is not stored in the compiled class file. There are many ways to circumvent the type "safety" provided by the templates, especially if you are mixing code from older versions. This is one of the worse implementations of generics I have seen. I hate Microsoft with a vengeance, but they are implementing generics in a sensible way in the next version of C#. See this for an interesting discussion comparing Java, C# and C++ generics.
   
   With java generics you can compile this:

   class MyClass<T> {
   T[] anArrayOfT()
   {
   Object[] arr = new Object[10];
   //add whatever you want to arr.
   return (T[]) arr;
   }
   }

   Of course, you cannot assign the return value to a T[] because it is really an Object[], so, where is the type safety? All this is without mentioning that Java generics don't provide any performance benefit (which you would naively expect because you believe that you do not have to cast anymore).
   Java generics are just compiler sugar for automatically generating casts.
2. Autoboxing: this feature removes clarity from the language. You do not know what is really going on. And you never know when you are going to be surprised.
3. Enums: They coud have made a very good typesafe implementation using internal integer values orsomething simple like that. Instead they make them as clases. At first they look like they work fine, but if you start workking in contexts where several classloaders are used (e.g. application servers) then the enum is going to be loaded in both classloaders and comparison of apparently equal values will fail.
4. Annotations: I really don't see the point of this. It's just more complexity. It seems it is only useful to help some complicated and probably not very well desinged tools.
5. New for: This simply makes the code harder to read. The original, C like "for" construct was very clear and was very understandable both for arrays and collections. Now in order to use a fundamental construct (a "for") your code has to implement some new interfaces. This is pure crap.
6. Static imports and variable length parameter lists: I think these are well done. I have nothing against these.
7. It looks like they wanted to add novelty features, but in order to avoid make the appropriate JVM specification changes, they implemented everything as compiler sugar. It just doesn't work.
8. 
   
   Maybe the fact that Java is now managed by a comittee instead of a few people who do know about language/compiler design has something to do with this.
   
   Maybe they are just trying to make it "easier"for those who don't know how to program. Again, it doesn't work.
   
   Something more or less like this happened when C++ was standarized. They came up with an overly complicated monster language, but at least the specification was not a broken one, just complex.
   
   They could have added pass of parameters by reference (at least for primitives), which would have been very useful in real world situations. But instead they decided to add a ton of crap.
   
   Java is doomed now. Too bad it was my favorite language. Now I have to look for another language. Maybe D?

Re:They fucked up Java

[Cederic]

>> Java generics don't provide any performance benefit

On the contrary, they provide the ability to write code faster, to understand code faster and to maintain code more easily, leading to fewer bugs, and thus less testing, and thus faster deployment.

That's a hell of a cost saving - more than enough to buy a slightly faster CPU, if you're really concerned about runtime performance.

>> Autoboxing: this feature removes clarity from the language.

I must have misunderstood this one. I thought it was simple auto-translation from primitives to their object equivalents (e.g. Integer to int and vice versa). Personally I have no clarity issues with

List listOfNumbers = new List();
listOfNumbers.add(5);
System.out.println ("Number added = " + listOfNumbers.get(0));

Sure, that's a shite example, but it's late at night. There's autoboxing going on in that add(5) call; I don't think it's hurt clarity at all.

>> Enums

That's certainly a potential issue when dealing with object references using an Enum pattern; I haven't tried that scenario in 1.5 so not whether that'll be a problem. Of course, if you rely on .equals() instead of == (as you generally should for all class types) then I'd expect Enums loaded from different class loaders to still be .equals() equal and thus your problem wont arise. Good spot though, I'll have a play and experiment with that one.

>> Annotations: I really don't see the point of this.

It's an exceedingly powerful addition to the language, albeit one I'm far from certain I'm happy about.

See the Apache Beehive project for an indication of what can be achieved with these things. (e.g. a one line annotation to turn a class into a web service - that's a lot of code you didn't have to write).

Personally I think they add a lot of complexity to the language, and that does (as your post's main thrust seems to suggest) make the language weaker - not because it's less capable, but because it's harder to understand and to write. Note that I'm not lazy, I'm not looking for a language that does everything for me and doesn't make me think; I'm looking for a language that lets me think about the logic I'm writing, rather than the language mechanics being used to express that logic.

>> New for: This simply makes the code harder to read.

I'm going to challenge that. Yes, maybe harder for read the first time(s) you come across it, but after that, every bit as simple as the current 'for'. If anything, potentially simpler..

>> Static imports and variable length parameter lists: I think these are well done.

At risk of sounding argumentative, I'm even going to disagree with your only positive comment on the changes.

Static imports add no value that I can perceive. They are there purely to entice users of other languages. I like having use of statically declared values qualified by a classname, it makes the code more readable and adds a little context.

So some of the changes I welcome, others I am more uncertain about, and a couple I'll dissuade people from using (to prevent misuse and aid code readability - where I am, maintainable code counts for a lot). I wouldn't however agree that "They fucked up Java".

~Cederic

Re:They fucked up Java

[vegetasaiyajin]

As far as experience tells me, short code is almost always more readable than long code (except for abusive use of regexps and such stuff). Java 1.5 new features are great because they make your code shorter, hence more clear.

Dismissing something as syntactic sugar is just silly. Java generics may be not perfect, but they make code shorter, therefore clearer.

it is not that they are not perfect. They are completely broken. I am not against adding generics to Java. But, I prefer Java without generics than with the crappy implementation they came up with.
If they had implemented generics properly I would not be complaining. I would be very happy instead.
First of all, they should have supported primitives in generics. This could have eliminated the need for autoboxing.
They instead went for a crappy implementation of generics and then another crappy workaround (autoboxing) for not having made a good generics implementation.
And you are wrong saying that language constructs that are shorter are automatically clearer.
By that logic, Perl would be one of the clearest languages of all.


Maybe you enjoy having to manually cast each time you use a container like ArrayList, or to manually write your own class ListOfT each time you want to use a list of elements of T type. I dont. Generics make my life easier, Im glad they included them.

You belive they make your life easier.
When you have to deal with the errors of the implementation you are going to see how easier it is.


I fail to see how autoboxing can make your code any significally harder to read. Its like saying method overloading should be banned because it makes code harder to read as it makes it impossible to determine what a method does only by its name.

I am not a big fan of method overloading, but I certainly would have prefered method overloading instead of the pile of broken crap they came up with.
As to how clear Autoboxing is, please explain the clarity of this:

Integer a = 2;
Integer b = 2;
boolean flag;
flag = a>=b; //true
flag = a<=b; //true
flag = a==b; //false

I fail to see how that is clear. Why is it clear that == should not be used for comparing objects, but >= and
In general, no one is forcing you to use any of this new features. If you find people using them, it is probably because they are USEFUL.

If I find people using them it will be because:
a) they are ignorant and don't understand how broken Java generics and autoboxing is.
b) They have no choice because they have invested a lot in Java and now the standard library is rewritten using templates as will several other tools too (probably for one of the two reasons).


I hate the fact that some people refuse to accept something can makes code clear if it doesnt stick to their own dogmas on programming styles.

I hate the fact that some ignorant people just fail to see how broken something is and criticize knowledgable people (and I am not talking about me, but many experts whose opinion I share) because they point out the flaws of something they believe is good.

Re:hmm. but how does this compare with Mono

[Jason Hood]

Over 50% of the .Net libraries have not been ported to Mono and may never be. Mono is pretty cool but until it is fully ported it will remain years behind Java and .Net. You cant compare them like you cant compare java to perl. Java and .Net are very much competitors and will continue to dominate the industry in their niche. Companies need security (as in a future) for their multimillion projects. It took Java ~6 years to self promote. If Mono severely ramps up their efforts, they MIGHT reach the plateau. Java was first to the punch, which is a huge advantage. I would wager my hunting dog that Mono will not overtake java in the next ten years. If MS is lucky and throws enough money at .Net, it has a decent chance.

You dont see companies developing 5k class projects in Mono, but thousands (if not more) do with Java and .Net. Dont believe me? Go count job postings for programming at Monster in a city near you.

My city last month?
60% Java
15% Perl
10% C/C++
5% .Net
5% COBOL
5% other

I cant hire Java and Perl programmers fast enough.

Exactly

[Trejkaz]

And not only was it faster to write in the first place, but the chances are your app will run on Windows out of the box without having to add arbitrary WinSock calls around the place. And it will run on BSD without adding extra network headers and libraries to the makefile after discovering half of them are missing from the default. And it will run on OSX without any knowledge of that platform at all. WORA is indeed real until people try to break it with specifically crafted examples. :-)

Re:I wait! -- you mean...

[scovetta]

You mean 1.5.1_03.1

Re:Generics

[Tomba]

Java's way of using type erasure is just a compiler "trick", a List is still a list of objects like it was before. A List in CLR is really a list of integers, not objects. There's no boxing involved, nor the extra memory overhead from boxing. Of course this only applies to the basic datatypes. Real objects are stored similarly in both ways, but even then there's one typecheck less in CLR when fetching data from the list.

SLOW

[Surt]

Bah, each new release I try hoping they'll do something about the speed since I like the language better than c/c++.

Since 1.0 there have been three major speed holdbacks preventing me and many others from adopting java:

1) array access too slow due to boundary checking (no, their optimizer doesn't work for my cases, and this is a problem a lot of scientists/performance hungry people have).

#1 has some good solutions on 64-bit platforms developed at the university of georgia, but sun won't include them, nor will they enable a flag on the jvm to turn of bounds checks. GCJ lets you do it, but can't compile everything I need yet.

2) casting raw memory to objects requires a copy. Java needs a structured object without a header to overcome this, such as the struct proposal, which is in the top 25 rfe's yet has no comment from sun.

#2 has a well understood solution that sun is apparently too lazy to even consider implementing.

3) No way to do fast 2d/3d rendered graphics. Too many call overheads & copies.

Sun needs to ditch AWT/Swing, and probably needs to open source java to overcome this. They've proven their inability to keep up a reasonable mapping to modern featuresets.

I'm probably going to have to give up and learn c# since I'd like a more modern language with good tools, but java just doesn't have the speed.

Re:STUPID MODS

[ElGuapoGolf]

Are you aware that the vast majority of games you play on any phone (except Verizon phones) are written in Java?

Thought not.

Sugar != Bad

[alacqua]

Carrying on down this path much farther, you become able to argue that C is just syntactic sugar for assembly language, and therefore assembly language is just as good.

Actually, except for the standard assumption that sytactic sugar be an extension of a core language (and not a completely separate language), it's pretty much true that C is syntactic sugar for assembly language. But syntactic sugar is neither good nor bad in-and-of-itself. If a given instance makes programming easier to do and easier to understand then I'd say it's good.

Netbeans 4.0 Beta 2

[fforw]

Netbeans 4.0 Beta 2 was also released today, giving people who want to try to ride the tiger a matching IDE with full language support:

Netbeans 4.0 Beta 2.

J2SE 5.0 bundled with Netbeans.

Generics != C++ templates

[Kenneth Stephen]

Generics in Java have a smaller scope, when compared to C++ templates. The objective in Java is to provide a type-safety mechanism for containers. In C++, it is much more than that. Unfortunately, it is this extra ability in C++ that makes for some really complex code. Not sure if this has already been mentioned in this story, but it has been theorized that C++ templates are themselves turing complete (though I havent seen a proof to that effect).

I'm a bit puzzled by all the generics nay-sayers. I have tried out the feature, and they augment the language. I have yet to see a downside to this feature in Java (unless one counts the inability of the compiler to fully utilize the additional type-safety in compiler error messages). What is all the flap about?

Not really.

[BayBlade]

I've opted to reply to this rather than mod.
While I think "write-once, run-anywhere" is a bit of a misnomer, it does actually live up to the hype, imho.

You can't really appreciate it however, until you've spent weeks porting C code between platforms, and a few hours porting similar Java code.

I've had headaches porting perl too (though I must admit its much better now). Things these days are much better for people *trying* to develop cross-platform applications in Java and a number of other languages and APIs, but when it gets sprung on you as a requirement late in the game (latter revisions, new customers, etc) porting a Java app is a godsend.

There's alot of valid reasons to hate any language (I've studied 22 languages and in their own way, I think they all suck), but that particular reason doesn't apply to Java.

Re:STUPID MODS

[pediddle]

So are the vast majority of internet games. I don't go a day without seeing somebody play poker, pool, or fantasy football online.

Re:hmm. but how does this compare with Mono

[miguel]

Mono is slower than .NET in certain areas, but in
some others it is a lot faster. The areas that
get the most testing and use from the team are
likely to be more tuned than the Microsoft
counterparts (this is a nice benefit of using
Mono to develop itself: we actually use it to
maintain our own compilers, editors, and day-to
day tools).

You are mistaken about the JIT nature of Mono,
Mono has an optimizing JIT engine with pluggable
optimizations. You can control the level of
optimizations using the -O flag to the runtime,
and we support Ahead-of-Time compilation as well
which means that you can turn on all the obscene
optimizations (those who might be too expensive
to do at JIT time, and that historically JITs
had to implement by doing dynamic recompilation).
In our case, we turn on all the expensive
optimizations, and run the code natively, without
a dynamic translation (like a JIT would do).

Anyways, Mono has a dedicated staff to support
and maintain it (16 developers reporting to me,
plus other contributors from Novell in other
areas of the VM) in addition to the 250 accounts
for external contributors that continue to
improve Mono.

We are not in a quest to compete with Java, we
bring something different to the table (and in
fact, we even support Java in Mono ;-), but your
statements are incorrect.

Miguel.

Remembering experience

[zabuldyga]

I used to work for a company that made a UML modeling tool. The earlier versions of it had been written in C++ and just about 8 years ago a Java version was launched. The decision that was made a year later was rather risky: to discontinue C++ version and switch to Java completely. This allowed to concentrate the development on just one product, which finally brought the success.

Was Java one of the main reasons for the big success of the product and the company? Quite possibly so.

Would the company have succeeded had not Java been chosen? Perhaps, with a bit of luck.

If Java was such a crap as it's often depicted, would this be possible at all? I very much doubt it.