[java] Not a troll!

Java will probably be a commonly used language for some time however development of the java language is pretty slow right now. I still use java for some thing but I mostly switched to C# becouse of java's poorly tacked on generics and enumeration support.

EDIT:
Also the main reason for switching to C# is that it is almost a clone of java with a updated feature set, half the classes in the java api have a equivalently in the .net library. Beyond compatibility with existing systems and code library's the only real advantage java still has is near perfect cross compatibility, .net has mono buts it still has a lot of problems.

People don't switch to .NET for "no good reason". That isn't the sort of thing that large organizations take lightly.

People use .NET because of the top-of-the-line development tools (absolutely unsurpassed) and the very broad range of capabilities... it can do everything java can, but it is also very well designed to be a powerful tool for development for the desktop as well. You can now write a windows desktop app that seamlessly integrates with web stuff using one language across the board.

Quote:

Original post by HugosHoH Java performance is JIT as in C# CLR...so they are both are interpreted whether we like it or not, they are... ????????????

No, neither Java nor C# is an interpreted language. That's the whole point of JIT.

C# is actually quite good for windows and xbox 360 games, so you might want to take a look at C# and XNA.

However, Java is certainly not dead. Java is the sleeping giant of game software and with fine engines like jMonkeyEngine, it is starting to wake up. Also, the growth in the MMORPG market means that games are moving towards the place that Java really shines, which is on the server side.

As for C# being a better language, I personally believe that there are aspects of C# that should be incorporated into Java, such as properties and proper generics.

JIT:
The CLR uses JIT. However, the JVM doesn't. Java bytecode is purely interpreted at first, then as the program continues to run, the JVM identifies the most frequently executed parts (hotspots) and compiles them to native code. So it may take a few seconds or more for a Java program to warm up. However if we're talking about games that perform a lot of native calls (such as jME games), chances are the real hotspots are already native.

Quote:

Original post by SteveTaylor C# is actually quite good for windows and xbox 360 games, so you might want to take a look at C# and XNA. However, Java is certainly not dead. Java is the sleeping giant of game software and with fine engines like jMonkeyEngine, it is starting to wake up. Also, the growth in the MMORPG market means that games are moving towards the place that Java really shines, which is on the server side. As for C# being a better language, I personally believe that there are aspects of C# that should be incorporated into Java, such as properties and proper generics.

Programming languages are means to ends, not ends in themselves. Not all games are MMORPGs and both C# and Java have their uses, as do many, many other languages.

A good programmer is always studying and mastering new tools for his trade. Programming languages are just tools. The more you have in your toolbox of skills, the more employable you are, and the better you will be at programming generally as you master entirely new approaches.

To a spanner, everything looks like a nut. Don't be a spanner.

Nice rhetoric there stimarco, even if it's not based on reality. It comes down to where these platforms (we're comparing platforms, not languages) have established themselves and how much library support exists in those established areas.

Quote:

Original post by SteveTaylor JIT: The CLR uses JIT. However, the JVM doesn't. Java bytecode is purely interpreted at first, then as the program continues to run, the JVM identifies the most frequently executed parts (hotspots) and compiles them to native code.

That's not quite true. Sun's HotSpot JVM has two versions: Client and Server. The latter performs more optimizations at startup, at the expense of longer startup time. Even the Client compiles some classes at startup. And in any case JIT is pretty much used synonymously with on-line compilation.

Quote:

Original post by SteveTaylor Nice rhetoric there stimarco, even if it's not based on reality. It comes down to where these platforms (we're comparing platforms, not languages) have established themselves and how much library support exists in those established areas.

All programming languages are platforms. You can't program in Python or C without a suitable suite of tools -- compiler / interpreter, debugger, decent editor, etc. Coupled with the necessary libraries and middleware you need to get any non-trivial job done and it's just not sensible to view each language as a separate, lonely tool.

Perhaps a better metaphor is that the language is like a custom toolbox. When you're a beginner, that toolbox is nearly empty: you have to add the necessary support tools -- compiler / interpreter, JVM, whatever -- and there are also spaces for the more generic tools such as a decent IDE and debugger. Once you start adding in the middleware, libraries and community support, you finally end up with a nicely stuffed box of tools and can get down to some serious work.

Some languages are more reliant on specific tools than others. The JVM and .NET's CLR are essentially very similar in concept; the .NET route merely makes the specific choice of language irrelevant. In effect, .NET itself is the toolbox, relegating your chosen language to a mere tool inside that box. JVM relies pretty much exclusively on Java, so the two are closely tied, but there are, in fact, plenty of alternatives.

Ultimately, the market you are developing for will, to a large extent, dictate your choice of toolbox. A developer who has mastered multiple languages and environments will have shelves and shelves of such toolboxes to choose from, giving him a granularity of choice unavailable to his less-knowledgeable competitor. A developer who has only ever used one will only have the one such toolbox on his mental rack shelving unit. Some toolboxes are extremely domain-specific, such as the one labelled "SQL". Others are far more general-purpose. And there are plenty in between.

And my original point still stands: platforms are unimportant. I've been programming since 1981 and have _lost count_ of the number of tools, environments and platforms I've worked on. I've worked in BASIC, Z80, 6502 and 680x0 assembly languages, C, C++, Pascal, Modula-2, COBOL, &#106avascript, C#, VBA and Codd knows what else. If I'd stuck with just the one, I'd be a useless dinosaur. I recently got back into programming again last year and it was surprisingly easy to pick up a new language.<br/><br/>Languages come and go, but programming has not.<br/><br/>Programming has barely evolved over the last 40-odd years. Too much emphasis has been placed on the shape and design of that toolbox, while very little work has been done on the tools it contains.<br/>

Quote:

Original post by stimarco Perhaps a better metaphor is that the language is like a custom toolbox. When you're a beginner, that toolbox is nearly empty: you have to add the necessary support tools -- compiler / interpreter, JVM, whatever -- and there are also spaces for the more generic tools such as a decent IDE and debugger. Once you start adding in the middleware, libraries and community support, you finally end up with a nicely stuffed box of tools and can get down to some serious work.

That's a good metaphor. It also explains why some might be hesitant to change their toolbox: When you have spent many years to gather (learning to use) a toolbox with many tools (libraries etc.) you don't want to start all over with a new empty toolbox. But since the tools of different toolboxes have many similarities, it is quite quick to learn using the new tools after you've used a similar one in the past. There are different kinds of hammers but they all work pretty much in the same way.

Then there are also toolboxes which fit some of the tools from another toolbox. With them the threshold of switching the toolbox is lower, because you can use many of your old tools. In like manner, for example Scala is tempting because it is interoperable with Java, so you can use the old reliable libraries with a new sleek language.

There is quite a lot of business software made in Java. If Cobol still lives because there is a software base in Cobol that companies do not want to let die, I think Java will live long, too.

For me the core question is, if Java will have a lifetime longer than my project, and I very much hope the answer is yes. Even if Java development should stop, tools and runtimes don't vanish, but can be used some more years until changes in hardware and OSes let them become obsolete.

The question of future code reuse after 10 years or more doesn't seem so important, thus I do not base my decision which language I use today, on what language I might use in ten years or more. And for today I think Java is a fairly safe bet. And in 10 years so much has changed that the question became obsolete anyways.

Quote:

Original post by Hajo The Dreamer For me the core question is, if Java will have a lifetime longer than my project, and I very much hope the answer is yes. Even if Java development should stop, tools and runtimes don't vanish, but can be used some more years until changes in hardware and OSes let them become obsolete.

Software is irrelevant. Its function matters.

See DosBox for proof.

If your software has adequate value, people will continue to use it. Many would consider old DOS games laughable in world of trillion polys/sec systems. Yet the DOS game community is going stronger than ever.

Java is here to stay. Sun is changing strategy. Rather than pushing JVM, they are doing a very smart move - they're moving to VM.

Many developers dismiss Java, but fail to realize that the VM that Sun built is surprisingly powerful and well built. And given the fact that it's been open sourced now, if nothing else - any hobbyst can maintain it if need be.

Maybe I was unclear. I've decided for Java because I'm confident it won't vanish soon.

And yes, DosBox is a very nice example that legacy software can live much longer than first expected. Which I consider a good thing.