Quake2 Ported to Java, Play Via the Web

casemon writes "Quake2 fans unite! Thanks to German software developer ByTonic software, you can now play Quake2 via the web with Jake2 a java port of ID Softwares seminal Quake2. ByTonic claims performance is similar to original C version. From the Jake2 website; "Jake2 is a Java 3D game engine. It is a port of the GPL'd Quake2 game engine from idSoftware. To use the Jake2 engine you need either the data files from the original game or from the demo version available for download from ftp://ftp.idsoftware.com." You actually don't need to get the data files, they've set it up to automatically download the 38Mb demo assets using WebStart. Just click the Play Now button and away you go. Most features supported, even multiplayer server!"

Comments

Erm, link:

[medgooroo]

http://www.bytonic.de/html/jake2.html just thought it might be, you know, handy?

Re:Erm, link:

[xtracto]

Too sad that the idSoftware server is slashdotted and I could not download the data from the webstart program =o(

Re:Erm, link:

[bpatinifurtado]

It is awesome what they have did!

I have a real good computer (memory, processor and video card) but I must tell you, the game runs really fast, you dont have the feeling of running a java application with all those 3 dimensional objects flying around you. You cant tell thats a program being interpreted.

Great job folks! The Java community has only to earn with this proof of concepts works :)

I have been there

Re:Erm, link:

[bentcd]

You cant tell thats a program being interpreted.
Java programs don't get interpreted on modern VMs, they get JITed. In some cases, this can result in more effecient code than a precompiled binary such as one created by a C compiler.

Re:Erm, link:

[The Other White Boy]

it has mirrors in the dropdown, i'm getting 120k/s from the german one.

Re:Erm, link:

[CowboyBob500]

La, la, la, I can't hear you...

Bob

Re:Erm, link:

[MartinG]

This is a bullshit argument that generally presumes a substandard optimization by the binary compiler.

No it assumes that the compiler cannot know the most common runtime code paths (which is true). A JIT engine can of course.

Even with compilers that read seperately collected profiler data (such as recent gcc which can take gprof output) can only work on that one profiler measurement. Lots of software is highly dependent on usage patterns and so different paths will be run depending on how the user uses the software. Only runtime optimisation can take this into account.

Re:Erm, link:

[TwistedSquare]

>>In some cases, this can result in more effecient code than a precompiled binary such as one created by a C compiler. This is a bullshit argument that generally presumes a substandard optimization by the binary compiler. I believe the theory is that the compiler can optimise for, say, Athlon XP, but cannot assume that anything above a 386 (or a Pentium, depending on settings) is being used, so it can't use XP-only instructions/tricks. Whereas the JIT compiler can optimise for the exact processor it is running on - it doesn't need to be able to run the programm on any other machines. This is particularly the case in Windows, and for Linux binary packages (obviously gentoo can do what I described when installing packages). Whether this actually makes an appreciable difference is another matter.

Re:Erm, link:

[nick-less]

>>>In some cases, this can result in more effecient code than a precompiled binary such as one created by a C compiler.

>This is a bullshit argument that generally presumes a substandard optimization by the binary compiler.

Like it or not, in 10+ years from now most (if not all) applications will be written in either Java, .NET or a similar Framework/Language. C/C++ will only be used where bit-banging stuff is needed AND NO ONE will care about except a few grumpy old man...

Re:Erm, link:

[CowboyBob500]

Exactly. In real life I found that there are 3 types of people who perpetuate the myth that Java is slow:-

1) .NET developers
2) People who's last experience of Java was rollover applets in 1996 and who have refused to install a JVM since
3) Crusty old Unix hackers with beards and rainbow jumpers for whom Window Managers are eye candy and whose idea of a IDE is vi

Bob

Re:Erm, link:

[MikeWeller]

This has also been done on .NET but as far as I know there is no downloadable version. See this channel 9 video: http://channel9.msdn.com/showpost.aspx?postid=2048 7

Re:Erm, link:

[DylanQuixote]

I'd actually think that there is still a good future for native code.
However, not C or C++. But perhaps something like ocaml, which can compile to bytecode or native code, but has all the niceties of garbage collection and so on. This would be nice, as ocaml is actually type safe (Java's type system has holes in it, but at least it has generics now...)

Re:Erm, link:

[tedgyz]

Right on, brother! The C/C++ bigots just can't accept that a Java program might run as fast as, or (gasp!) faster then a C/C++ program.

I worked in a compiler group for 10+ years. Profiling was definitely the best way to optimize a program. The challenge was that the compile-profile-compile loop was cumbersome and was hard to account for all use cases. JIT profiling deals with YOUR use case. If it's really good, it will even adapt and re-profile as your use pattern changes.

Re:Erm, link:

[CastrTroy]

If your project was Open source, then couldn't you include GCC with the project, as well as the code, and provide a means of JIT'ing the C/C++ code? It might make things run faster, and for things that are really speed sensitive, might provide a way of making things just that little bit more faster. If this was done for all of Linux, The OS and the application suite, could we get some major improvements in terms of performance?

Re:Erm, link:

[LWATCDR]

I have developed code in java for a few years now and you are over simplifying the case.
Where Java has been or still is slow.
1. Start up. It takes a good bit of time to start a java program because it takes a good amount of time to load the JVM. Not an issue on a sever where the JVM is probably in use all the time but a pain on the desktop. It also makes small utilities a pain in java. The latest version of java seems to start quicker.
2. Swing. Swing has been slow. The latest version of java seems much better.
I here all the time how Java can be as fast as c++ but I have to admit I have never seen it. I would put Java in the class of fast enough for most tasks.

I use Java because I like OOP and I really like how Swing is laid out. It fits my mind set a lot better than MFC which I hate with a passion or GTK which while object oriented is not in c++. You can use GTKmm but the number of dependencies is just over the top IMHO. Everyone is different so what I like may not be what someone else likes.

I don't do VB because I will not learn a programing language that only runs on one OS. I also have not bothered with c# yet because I see little benefit over Java unless you are going to stick to just Windows. I have to develop for Windows and Linux so that is not an option.

Re:Erm, link:

[gcauthon]

Java programs don't get interpreted on modern VMs, they get JITed

Question, how does the Java program get "JITed" without getting intepreted first? Does the VM use ESP to read the mind of whoever wrote the program?

This argument is so old and ridiculous. The only benefit of JIT is that it prevents having to reinterpret the same piece of code over and over if it's executing a loop or procedure multiple times. JIT just makes Java an efficient intepreter rather than a crappy one (which it used to be).

Re:Erm, link:

[zootm]

I also have not bothered with c# yet because I see little benefit over Java unless you are going to stick to just Windows. I have to develop for Windows and Linux so that is not an option.

The GTK classes (I know you said you didn't like GTK, but your major criticism is that it wasn't in C++, which isn't relevant here :)) provided by Mono for C# are cross-platform, maybe you should give that a go? I have to say I really like C# as a language — it's extremely similar to Java (of course) but has a few nice constructs that can help out a lot (delegates, in particular, come to mind).

I agree that the problem with Java's "performance" reputation is largely due to the bad performance of Swing in the past though. I myself (while writing Java) always found it slow, until I started playing with things not using a GUI, when I discovered it wasn't actually slow at all.

Re:Erm, link:

[Beek]

Ummm... I think that JIT depends just as much on the VM as it does on the compiler (probably more).

Re:Erm, link:

[laffer1]

Mono is cross platform? Ok.. it runs on linux and windows. it sort of works in mac os x, but not for web development. On a bsd forget it. Name another platform.. plus from my understanding there are lots of issues with porting the garbage collector to various architectures and operating systems. In contrast, java runs on my cell phone, mac, windows, freebsd, linux, etc.

Re:Erm, link:

[andreyw]

... and we will wind up with a whole generation of ``software engineers'' who stumble on stupid concepts like ``endianness'', ``alignment'', ``pointers'', ``memory management'', ''stack'' and other assorted mundaneness.

Yeah, that'll be really swell. For a look at corporate tomorrow, look at college today. The curriculum sucks (aimed at Java hence none of the computer basics are taught, and students come out with NO knowledge of what happens at OS level/ CPU level - and no, ivory tower classes like ``let's design our own datapath'' are pretty worthless here), while the students just don't know any better.

In fact, Microsoft itself (while a proponent of .NET) is lamenting that colleges are basically not teaching students the basics (that would be C, not VMd languages du jour).

Re:Erm, link:

[zootm]

Fair point — it only really runs on BSD, Linux, OSX, and Windows. Swing is better for OSX in particular because it's an abstraction, as opposed to GTK which can't really adapt all that much. I thought that Mono used the (proven cross-platform) Boehm GC though (I have to say, I only have BSD, Linux and Windows to test it on!).

.NET (the Microsoft one) does run on BSD, PDAs, and mobiles (well, those Windows ones, anyway, using the cut-down-but-still-neat Compact Framework). And obviously you choose the tool for the job — I don't think dismissing Mono, .NET, or C# out-of-hand is justified, really.

Re:Erm, link:

[laffer1]

I fit category 1 and 3 above and I still think java runs very fast for server based code. Running a java servlet container is very fast. A few applications like jedit, intellij idea and limewire seem fast on the graphical front. Someone can write a slow .NET, C++, or objective c app too.

Java's benefit is its age and portability. Its fairly mature and very fast when running under the server vm for some time. Quick command line apps are best served with C code. Compile C code with g++ instead of gcc sometime. Not only will your code run slower, but it will be larger as well. Likewise time a Visual C++ app vs a .NET gui app starting up. The advantage of Java and .NET is the massive amount of libraries that are guaranteed to be there. The STL in C++ is not implemented consistently across compilers or platforms. My big complaint with java isn't speed, but organization. I find the namespaces cluttered and confusing compared to .NET. Think about it. They have io and nio. Try to write XML code sometime! Oh god. Java is more portable than .NET though. The price is a consistant namespace layout. Maybe someday if Mono matured to a point it was portable and at least .NET 1.0 compatible we'd see a real shift in software development. I'd use c# in bsd for example. Its great for web development compared to the servlet api.

If your vision of java is applets think again. No one uses java for applets anymore. If you do, you missed DHTML and its recent variants. Client side code is ignorant anyway. Browsers aren't standarized enough for that yet. Java is good for server side code and if written properly, desktop gui applications.

Re:Erm, link:

[Lost Found]

You can keep calling it a myth all day long; unfortunately, that just doesn't take any of the truth out of it.

Re:Erm, link:

[callipygian-showsyst]

Yeah! I'm #1 (on your list).

P.S.: It *is* slow! And every Java app looks like a "SunOS" Application from 1985.

Re:Erm, link:

[Lumpy]

you forgot one.

4 - Users that have to run Java apps.

honestly poorly written Java apps cause this as we llas network latency causing the image of java = slow.

Many java apps that are downloaded and installed on the loca lmachine are nice and fast.

unfortunately most peoples exposure to java is poorly written web apps.

Re:Erm, link:

[Glock27]

Like it or not, in 10+ years from now most (if not all) applications will be written in either Java, .NET or a similar Framework/Language.

Perhaps. It isn't clear to me why one would necessarily want to write a "traditional" application (i.e. desktop style application) in a "managed" language. I've been a big Java fan, mainly from the standpoint of someone who came from C++ and could see that Java was much more productive. I even wanted to write high-performance code (and games) in Java. However, the numbers have never really been in Java's favor. Look at the benchmarks at the Great Computer Language Shootout. They're microbenchmarks, where Java should do quite well if it can really stand up to "traditional" languages in efficiency. The short story is, it doesn't. Further, I don't see the JVM/JIT ever catching up with a highly optimizing ahead-of-time compiler, especially in terms of memory efficiency.

In short, I'm planning on using Java for web-oriented programming, but for 'real' desktop apps it'll either be D or Dylan for me. Both are far more expressive, just as safe, just as productive (if not moreso) and both are significantly faster. Oh, one final point...both are available as FOSS.

C/C++ will only be used where bit-banging stuff is needed AND NO ONE will care about except a few grumpy old man...

Both will be around for a *long* time due to legacy code, but I agree for new development a more modern language is desirable. D and Dylan both fit the bill...Java really doesn't hit the same target. Also, both languages have language constructs like operator overloading that're more suitable for HPC/simulation/game programming, and feature very performant C calling interfaces.

Re:Erm, link:

[lubricated]

>>Like it or not, in 10+ years from now most (if not all) applications will be written in either Java

I heard this same shit something like 10 years ago(or whenever it was java first came out).

Re:Erm, link:

[Bezben]

Yes, it runs the demo as perfect as the accelerated original on my machine. But then my machine now is an AMD 3200 with a GeForce 6800GT, whereas my machine then was a K6 350 with a 3dfx voodoo. I'm willing to bet my current machine can run the original native demo at a fair pace. And this is a game that is what, 10 years old? Now if they wrote a java version of the doom3 demo or the quake 4 demo, then I would agree java performance for games is just as good as in C++.

I'm one of those who haven't dabbled in java in a number of years. I was put off somewhat by the performance, I remember using IDEs written in java for uni, they were awfully slow. I'm sure that has changed a lot, but I've now been using C++ for many years, it's a language I like and enjoy using. But the thing I didn't like about java most was that I couldn't seperate class definition and declaration. I always found that confusing and messy.

Re:Erm, link:

[Bezben]

What will they use to write these languages and frameworks?

Re:Erm, link:

[bpatinifurtado]

But the thing I didn't like about java most was that I couldn't seperate class definition and declaration. I always found that confusing and messy.

With Java you can do it even better than with C++ obligatory header files. In Java you have interfaces, a file with only public operations declarations, that can be really more expressive (clean) and precise than the pure abstract classes (the C++ wanna be interfaces).

Re:Erm, link:

[Elwaryn]

Hahaha. Number 3 describes one of my teachers quite well.

Re:Erm, link:

[Bezben]

I'm not talking in the object design sense, I'm talking purely how the classes are laid out in the files.

Re:Erm, link:

[ionpro]

In my school (Vanderbilt University), we teach both C++ and Java as part of the CS curriculum, and programs have to be written in LISP and ML as well. We have an entire class dedicated to the basics you mention as part of the required curriculum, and almost all the advanced courses have references to those things. We also have a class specifically about what happens on the CPU level (including writting both bytecode and assembly using -- ha! -- iJVM), and a class specifically about what happens on the OS level (both courses have optional follow-ups that go more in-depth). I don't get the impression our CS curriculum is that unusual. (If you care, the exact requirements are in this PDF under "Computer Science.")

Re:Erm, link:

[andreyw]

Sounds like someone needs to transfer. /I hate UIC.

Re:Erm, link:

[KinkoBlast]

cat? You mean you write programs for felines?

if you meant the program, you should have said sed/awk/bash.

Re:Erm, link:

[Keebler71]

Exactly. In real life I found that there are 3 types of people who perpetuate the myth that Java is slow:-

Don't you mean that there are 11 types of people?

Re:Erm, link:

[bpatinifurtado]

Okays, I got it.
But, with all IDEs (Eclipse been one of the best and free) available today you can see the operations of a class in some tree like structure view.
With java you still can make for each class file one interface file, but doing this only to be similar to C++ wouldnt make sense anyway.

Re:Erm, link:

[Bezben]

I know, it would be a stupid hack. It's very much a personal preference, I've just gotten used to being about to see the layout of a class I've written it a certain way. I'm sure it'd be possible to write a plugin or something for an IDE to show a class overview that way in other languages, but why bother, C++ already does things the way I like. These constant arguements over which language is better are pointless. Most of them are designed for different purposes and each is better at different things. Neither C++ or java are going to die anytime soon, people will be using each for a long time to come. Both will continue to mature.

Re:Erm, link:

[aaronl]

Not really true at all. Java still has all the problems it did in 1996, they're just less of a problem on an Athlon64 with 1GB RAM. Startup time is marginally better than old JREs, which is of some concern for applications. Look at OOo, where the most common tip is "turn off Java in the preferences". That should tell you that people *do* think Java is slow, because JRE startup *is* slow.

There are other annoyances, like the default 128MB RAM limit. There is that you still have to load the C libraries for the JRE, then you have to load the JRE, then you have to load the app. That means it consumes quite a lot more memory than if that app just was linked to the C libs.

Java code is also only faster for code paths that gain additional optimization from runtime profiling. For most applications that people use day to day, it will run slower or, occasionally, the same as a native app. This is impossible to avoid with additional layers of abstraction, and runtime translated code.

As for the touted excellent Java apps people like to go on about... Azureus has a horribly slow UI and takes 10s+ to start on high-end hardware. OOo starts in under half the time w/o JRE support enabled. Eclipse really isn't very fun to use just because it is only almost responsive.

My favorite desktop on UNIX has still been FVWM, but I don't find GNOME and KDE to be bad, just a little heavy. I'd use them more if I didn't have to load such a ridiculous amount of backend trash to do anything; there are too many apps that are written to use all the backend from one or the other. It makes choosing between them annoying.

Java will be much more useful when you can have multiple apps share one in-memory copy of the JRE.

Re:Erm, link:

[aaronl]

Some version of Java runs on all those things. However, J2ME is very stripped down, so that you have Java on your cell phone is a bit irrelevant; it can't run any of the Java apps you have on your J2SE installs.

By that token, you can write C code to run on almost anything, you just have to run it with "gcc" instead of "java". (Yes I know it isn't the same thing, etc, etc.)

Anyway, you can run Mono on most places that you would likely run J2SE.

Re:Erm, link:

[tedgyz]

So how do you feel about assembly code in libc, or the kernel?

Re:Erm, link:

[CowboyBob500]

Azureus has a horribly slow UI and takes 10s+ to start on high-end hardware.

Rubbish. It starts in 5 seconds on my Thinkpad with a 1.5Ghz processor. That's not that high end nowadays.

Anyway, who in the hell cares about start up time? What does it matter if OOo starts up slower than Word? It preforms perfectly OK when it's running. Do the people who complain about this sort of thing have some kind of ADD where they forget what their doing if an app isn't in front of them in microseconds?

Bob

Re:Erm, link:

[tedgyz]

I don't know if you are asking too much, but why are you asking?

Why is it important that the JVM be written in Java?

The whole intent of the Java language was to build a platform for applications so that the application writers didn't have to worry so much about the platform underneath. Hence, the JVM's very purpose is to encapsulate the nuances of each platform, while adhering to the multi-platform APIs, etc.

I don't know that any Java application writer really cares what language the JVM is written in.

If your comments are leading to the point that the JVM is non-portable... Well, it wasn't meant to be. The JVM is like an operating system. It just so happens to be layered on top of our traditional concept of operating systems.

Re:Erm, link:

[pomakis]

Question, how does the Java program get "JITed" without getting intepreted first? Does the VM use ESP to read the mind of whoever wrote the program?

This argument is so old and ridiculous. The only benefit of JIT is that it prevents having to reinterpret the same piece of code over and over if it's executing a loop or procedure multiple times. JIT just makes Java an efficient intepreter rather than a crappy one (which it used to be).

It just so happens that the majority of most programs are bits of code that get executed over and over again, often thousands or millions of times. So even if the first few passes over a bit of code are interpreted, once the JIT kicks in and compiles it, all future passes (quite often the vast majority of passes) are executed from compiled code. And since this compiled code was compiled with the precise details of the current architecture and memory, etc., under consideration, it follows that the code in general will run more efficiently than similar code that was statically compiled. In some situations, this increase in performance more than makes up for the initial loss of performance during the first few interpreted passes of the code.

At least this is all true in theory. In practice, well, it isn't so clear yet. But what is clear is that a JIT at least has this potential.

Re:Erm, link:

[bpatinifurtado]

I totally agree :)

Re:Erm, link:

[Alban]

Actually, on embedded platforms where performance is critical (game consoles, for example), you want absolute control of your memory layout in order to avoid fragmentation. I don't know if you've had experience with memory fragmentation, but it will slow execution down to a crawl. As good as a virtual machine may be about properly organizing memory, it cannot be better than a good programmer with intimate knowledge of his app's mem usage.

You also want execution to be completely deterministic and certainly don't want a garbage collector to be scheduled to run right when you expect it the least and completely trash your cache memory. I know that you can have some degree of control on when your GC kicks in and whether it should try to run in long stints or in regular and sporadic stints, but it's still not 100% control.

On a platform with fixed hardware, if you give up some control and your competitor doesn't, he will have the edge on performance.

It is not until I got to work on high performance embedded software that I finally brutally realized how, in specific cases, having 100% control on the underlying platform will make the difference between good and bad performance. It is not until you reach the limits of a platform that you realize how having full control

Having said this, I agree that a Java app can be plenty fast. However, it is hard to say how fast that java port of quake2 is until you run it on the typical hardware we had when quake2 first came out. If you run the native quake2 and java quake 2 on a PC today, they will both be blazing fast. But I would like to see how the java version performs on a PC that would *just* reach 60 fps for a native quake2. That would be interesting.

Re:Erm, link:

[atlasdropperofworlds]

"Like it or not, in 10+ years from now most (if not all) applications will be written in either Java, .NET or a similar Framework/Language. C/C++ will only be used where bit-banging stuff is needed AND NO ONE will care about except a few grumpy old man..."

It's not the language or the interperter that makes application development in Java, C#/.NET/mono, Python, or whatever fast, it's the framework. In 10 years, there will be C/C++ frameworks that will be just as "complete", albeit bloated, as the Java or .NET ones. The language and compiler method if far less relevent to software development than the quality of the framework.

BTW, in 10 years, the whole idea of a VM will be perposterous, as hardware support for secure process space will be commonplace.

Re:Erm, link:

[Pxtl]

While in general JIT does bring a lot to the table, Java drags it back down with a lot of things - the garbage collector, the over-specified floating-point accuracy, array-bounds-checking, and any number of overheads that come from Java's security/stability-before-speed design.

But then, my knowledge of Java is dated. Has there been new ground broken in the environment to let coders rip off the training wheels?

Re:Erm, link:

[tedgyz]

So, your saying favoring security and stability is a bad thing?

I'm sure all the virus/worm/trojan-horse writers out there would agree with you. God knows we don't want to check those array bounds. How else am I supposed to hack into your system with root privs?

Ok, so you might argue something like Quake 4 doesn't need this? What happens when Q4 gets hit with a virus? Would you change your mind then?

The problem is, C and the like has fed our addiction to speed. It's like a race bike. You can scream like a banshee, but watch out for those bridge abuttments.

Finally, with regards to garbage collection, from what I've read, the latest versions are very efficient. I won't compare it to C/C++ for fear of a new flame-thread. All I know is I've been coding for 20+ years and I've never met an engineer who is perfect. Of all the bugs I've chased down, memory errors were the most prevalent and most painful. Sure, you can still make memory mistakes in Java and other GC languages. But, you can make a lot less of them and the mistakes are usually less fatal than the more traditional memory errors in non-GC languages.

You call these things training wheels. I call them features. Good features.

Re:Erm, link:

[strikethree]

CiscoWorks and Spectrum beg to disagree with your cavalier dismissal of "Java is slow".

strike

Re:Erm, link:

[Pxtl]

The computing industry (except for Netscape Navigator) got along fine before garbage collection. Yes, it's a nuisance to do without - but you can implement it yourself if you like. Do any of Id's games have memory leaks to speak of? Besides are other architectures besides the reference-counted-shared-pointer using a lazy sweep-cleanup garbage collector for safe pointers. For example, a "parent/child-only" with weak references creates a resolvable tree that makes for easy cleanup, and weak references can be used for non-parent-child pointers. None of the ambiguity of the garbage collector there.

As for array counting - yes, any data you get from user files should go through a safe array - but what about inner loops? Should my merge-sort algorithm use safe arrays for it's internal copies?

The point is that they _are_ training wheels. Good, solid code can be made without them. Yes, for apps where speed isn't essential, you may as well leave them on - but the problem is that the platform _forces_ you to use them. At least in .NET you can work with Managed C++ or unsafe C# and get nitty-gritty with the pointers and structs if you like. Java has no such facilities that I know of.

JIT is a great feature, but it's speed advantages are overshadowed by the speed barriers in Java, preventing it's use as a high-performance speed-oriented language. I expect that .NET will fare better in that regard.

Re:Erm, link:

[aaronl]

I don't care so much about *my* app taking 10s or 15s to start. Typical users expect it to be done shortly after they click the little pictures, though. It's been the biggest problem in my deployments of OOo, for example. It's hard to get people to believe that a product which takes 15s is better than one that takes 2s, especially if they have nearly duplicate feature sets. Also, it gets really annoying when you open a document, view something, close it, and then go to open another one.

BTW, I run Azureus with default settings and a Synaptic package install of latest Java5 on Ubuntu 5.10 (32bit). The system is an Athlon64 3000+ with 1GB PC3200 CAS2 RAM on a 7200RPM drive with 16MB cache. In addition to the default GNOME environment, Gaim is the only thing running. Azureus takes 10-15s to start after a fresh reboot, and 5-7s to restart from an update. The UI still lags slightly, too. It's perfectly usable, though, since I don't do more than let it sit in the background. I'm running the latest release of Azureus, which still crashes very occasionally.

Re:Erm, link:

[Wolfier]

It is important - naturally, when a new language is constructed, its compiler and runtime has to be written in an existing language.

As the language matures, you can write the compiler in the language so it'll compile itself, or an intrepretor in the language itself.  In fact, it is a major milestone, and a testament to the self-sufficiency and efficiency of the implementation.

Without forgetting about Java application writer's and put the focus on the Java application *users'* point of view for a second, there'll not be much incentive to cut bloats and fix implementation inefficiencies.

It's not that Java's slow, but unfortunately except J2ME everything seems to be resource hogs.

Re:Erm, link:

[tedgyz]

Been there. Done that. Sure, it was really swell to build our compiler (Alsys Ada) on our native platform (Wang VS). Does it prove anything? Maybe. Is it necessary for all languages and all compilers? IMHO - no.

While this has been common practice for most high-level languages, I don't think of it as a requirement.

The only reason it served as a major milestone is because a compiler, linker, etc. were good examples of complex applications. In essence, it was a good test suite.

I recall in the days of working on Alsys Ada, some of the competition (names escape me) bragged about being written in C. Guess why? Performance.

Of course, you could argue about how Ada was just as bloated and useless a language as Java.

The point is, self-compiling a compiler is not a truism in my book.

Re:Erm, link:

[cecom]

LOL. You must be kidding - all the real work is in the OpenGL code, which isn't written in Java. The real test would be running Quake2 with a software renderer written in Java. We can argue whether it will be 10x or 20x slower ...

Re:Erm, link:

[bpatinifurtado]

good point. But I am afraid this is as far as Java can go, OpenGL implementations probably must be tighted to the hardware, Java by definition it is not.

Re:Erm, link:

[cecom]

A SW renderer isn't particularily hardware bound. All it needs is the ability to write to the frame buffer.

Personally I love Java, but it has inherent limitations that make it very unsuitable for some tasks. Since we are talking about 3D rendering, an array of 3D coordinates in Java is at least an order of magnitude slower to access - every array element is a separate object which must dereferenced. The definition of the language itself makes this unoptimisable - no JIT or static compiler can fix that.

Re:Erm, link:

[CowboyBob500]

I see you came in well down the field in the brain race. You may find the site here more suitable for your intellectual level.

Bob

Re:Erm, link:

[the_furman]

You're missing the point. Whenever code is compiled, certain compromises are made as far as speed/resource (memory, whatever) usage goes. This is where the true benefit of JIT comes in - with JIT, the comipation is optimized not only for the given machine but also for this particular point in time. It should be obvious why this approach at least has the potential to beat conventional precompilation.

Re:Erm, link:

[Billly Gates]

It may not be slow but its very bloated.

I know from experience on my athlon with 512 megs of ram. I keep running out of memory when I run frostwire and azaerus. Of course I also use trillian and Firefox which would explain alot I admit.

Worst, swing is not threaded properly by default so the gui locks up when its busy unless the programmer specifically multithreads the code dealing with swing. THis creates the illusion that the java app is slow and unresponsive and people assume its because its written in Java. Most gui java apps do this and the hour glass pops up while the windows become grayed out.

Vs.net apps do not have this problem and you just simple use winforms and when the app is busy then the gui wont become unresonsive. This is why the .net developers don't like java.

Netbeans takes 210 megs of ram and its unreal. Eclipse is worse. Visual studio.net takes 1/4th the amount of ram.

No its not slow and the language is perfect for servlets where the bottleneck is database and network access and not the cpu's speed. But a pig it is for desktop apps since a c++ or c# app takes a much smaller amount of memory to run.

Re:Erm, link:

[matfud]

Sun's java compiler IS written in java.

As for the VM, you don't need one if you hava a native java processor.

Re:Erm, link:

[bpatinifurtado]

every array element is a separate object which must dereferenced

Every array in Java is indeed a object, but even though, that must be a very light weight one.

which must dereferenced

Do you mean, its memory would need to be de-allocated? In C/C++ you would have to do that too, only with more control and responsability.

But I still agree with you that Java being interpreted impose serious limitations (compared with non interpreted languages) when you talk about 3D rendering.

Re:Erm, link:

[tedgyz]

Jikes RVM, which is the descendent of Jalapeno.

Java fails to make a lot of optimizations either statically or at runtime that any decent static optimizing compiler would perform. This is in part because in many cases the time taken to perform the optimizations is acceptable for a static compilation, but completely untenable for runtime compilation. It also doesn't really matter to someone whose execution model doesn't rely upon a virtual machine fetish if assembly is used to implement pieces of a kernel or a standard library.

What compiler did you work on for ten years, btw?

It was always my impression that Sun wanted to give a reference implementation, with the expectation (hope?) that 3rd party vendors would build high-performance JVMs. It is very expensive to build a team of talanted optimization experts. Sun has them, but they prefer that they make SPARC compilers go faster. Things may have changed at Sun. I got out of the system software biz 7 years ago. Now I build webapps. And I run on whatever software or hardware platform I choose. :-)

I worked in a compiler group for 11 years. 4 years at Wang. 7 years at Apollo/HP. I spent the early years on Ada, and the later years on C++, with lots of other languages sprinkled in. I spent all of the years working on Debuggers. I was kind of jack of all trades. For example, I'm not an optimizer guru. Those guys are a "rare breed". I was, however, exposed to their research. I even helped out with generating plots for call graphs. :-)

Re:Erm, link:

[cecom]

Do you mean, its memory would need to be de-allocated? In C/C++ you would have to do that too, only with more control and responsability.

No, not that (although I could talk about memory management too :-). In Java an array of structures is technically an array of pointers to structures. If you know C, think about the difference between "Point3D x[100]" and "Point3D * x[100]".

But I still agree with you that Java being interpreted impose serious limitations (compared with non interpreted languages) when you talk about 3D rendering.

The problem is not that Java is often interpreted, but that the definition of the language makes it impossible to generate efficient code for some things (like the example abpve). There are static Java compilers producing native code (e.g. GCJ: http://gcc.gnu.org/java/), but even that is an order of mangitude slower than the equivalent C code (note: for some things only, not for everything!).

It is also interesting to note that the existing Java JITs (like Sun's or IBM's) have much better performance than static Java compilers.

Re:Erm, link:

[SoulDad570]

Agreed, however, you forgot one category: C++ bigots. I recently worked on a (successful) large Java project. A large group of old crusty C++ "experts" moved onto the project and convinced management that Java was too slow and too large. They further convinced management that they could port the huge application from Java to C++ in 2 months. Yes, that's right 2 months (the original application has been in development for over 3 years). Long story sort, it's been close to a year now, the C++ application is dramatically larger than the Java application (about 4x) and is no faster. It's also full of memory leaks and bugs. As the "fine" article stated, Java is a bit slower than C (60% the speed of), but Java is in general not slower and larger than C++.

Re:Erm, link:

[laffer1]

There is a mono port for BSD but it does not work properly. I'm specifically talking about FreeBSD 5.x. I've filed bug reports, etc. I have not tried it since 6.0 came out, maybe the situation is better. If you tried to run it with a simple app it would run, but actually try to run any real code or the webserver and the garbage collector would crash. It does use the boehm gc but it doesn't like freebsd's newer thread libraries too much. You can only count linux and windows for 100% support of what novell has done. Mac OS X works for gui apps but not webapps yet. Most mac users would want it for web development at this point.

Re:Erm, link:

[Quixadhal]

3) Crusty old Unix hackers with beards and rainbow jumpers for whom Window Managers are eye candy and whose idea of a IDE is vi

I do NOT wear rainbow jumpers.
:wq!

Re:Erm, link:

[g-san]

2) People who's last experience of Java was rollover applets in 1996 and who have refused to install a JVM since

It's not so much the JVM, but the JDE. After all my 1.0 GUIs broke in 1.1, yeah I hit the brakes on Java. Then again, I had just discovered perl with web servers and became a server-side zealot. Screw the plugin of the month, I want this to work in Netscape 1.0 and NCSA Mosaic. That was also the very early days of JIT.

All this talk of performance does pique my curiosity again.

And go easy on the crusty old unix hackers. If it wasn't for them, neither of us would be having this discussion. Think about it.

Re:Erm, link:

[bentcd]

If the computing industry has been getting along fine, then it is only because there has been noone to compare them to but themselves. Software always has had and still has an atrociously low level of quality. While there may be one or two software gems out there, most of it is complete crud. The only reason we can get away with this is that the consumers have become used to it and don't really expect any better.
We need languages and development methodologies that can rectify this, that can enable us to make high-quality software without sinking $billions into painstaking quality control efforts which, as both NASA and ESA have shown us, doesn't really work all that well either.
If garbage collection and assorted training wheels is what it takes for us to be able to produce robust code that actually works, then please bring it on. What little cost this has in CPU cycles is inconsequential to the good it will do to both the industry and society in general.
Of course, if these are _not_ the tools that we need, they will eventually die and we'll come up with something else in stead. I still haven't seen a convincing argument to this effect though.

Re:Erm, link:

[lachlan76]

But you'd need to run that JVM inside another JVM....

Re:Erm, link:

[tedgyz]

Very funny! :-)

Re:Erm, link:

[zootm]

Hmm — Mono worked fine on FreeBSD for me when I was running it, but this was a while ago now. Weird. Hope they sort it out, anyway!

Re:Erm, link:

[destuxor]

Client side code is ignorant until you realise your server code didn't handle error checking perfectly, then you hack together some JavaScript until you can make sense of the servers Perl scripts. Then your manager decides redundant error checking is a Good Thing and the JavaScript stays there forever.

Re:Erm, link:

[laffer1]

There is only one benefit to javascript checking in an application. You can alert the user to an error sooner. Aside from possible HCI benefits, there is absolutely no reason to use javascript in a webpage. Any counter argument would be for eye candy or irritating pop up ads. If you want eye candy, use flash. They you are only alienating anyone using a unix system. (not counting x86 linux)

If your server side code is wrong, fix it immediately. Trying to "fix it" by using javascript is dumb. I can turn off javascript in my browser and then i hit your bad server code. Quite a few users intentionally disable javascript or do indirectly by using a product like norton internet security which disables many javascript features and cookies. If you don't understand perl, use another language. managers often don't know what they are talking about anyway. Use php and tell them its perl. Heck if you can control the webserver map pl to php. They won't know the difference. This is assuming you can use php of course.

Re:Erm, link:

[Thuktun]

The point is that they _are_ training wheels. Good, solid code can be made without them.

...assuming you have good, solid coders to write it. In some (many?) environments, these are outnumbered by the opposite.

Re:Erm, link:

[Vorax]

Your Java knowledge is dated (by years actually)

The point is that they _are_ training wheels. Good, solid code can be made without them. Yes, for apps where speed isn't essential, you may as well leave them on - but the problem is that the platform _forces_ you to use them. At least in .NET you can work with Managed C++ or unsafe C# and get nitty-gritty with the pointers and structs if you like. Java has no such facilities that I know of.

You can get nitty-gritty with the bytes with the NIO packages. For video game development, NIO direct buffers can be setup to point at the video ram for things such a VBO's. You can freak out your video card just as nicely as can be done in C or assembly if you like. You can do the same with the CPU's ram.

How on earth do you guys suppose people are writing to OpenGL using Java? Without direct memory access in the language, the functions of modern video card wouldn't even be acessible - heck, you wouldn't even be able to upload a texture.

Re:Erm, link:

[Explo]

..assuming you have good, solid coders to write it. In some (many?) environments, these are outnumbered by the opposite.

Or even worse, they are trounced by too tight deadlines, which isn't that uncommon. Even good coders will make sloppy code if the time is running out.

Re:Erm, link:

[petermgreen]

i also seem to remember the gcj team saying you couldn't do much optimisation at the compile to bytecode stage because doing so would make the bytecode fail the verifier.

Works pretty well

[Anonymous Coward]

I saw it at swing sightings. I tried it with the original game files and didn't notice any difference in speed with the original binaries.
And this with a not so fast computer: PIII 800, TNT 2, 384 MB RAM.
Anyway if you wanna see benchmarks with older computers look at their web.

Re:Works pretty well

[GMC-jimmy]

I remember buying Quake 2 from the store and at the time the fastest thing I had to play on was a Pentium 233 MHz with 64RAM and a 3Dfx Voodoo 2 video pass-thru card.

Performance wasn't exactly on par with what everyone else was bragging about on the popular review sites at the time, but fair and good enough to play, which for me was around 20-30fps at 640x480.

I think an 800 MHz CPU would've been 2 to 3 times faster than what the game was originally made for.

If I recall, the fastest CPU on the market then at the time was something between 300 and 500. This would've been the summer of 1996 I think. What was the average CPU speed back then during Quake 2's retail days ? I wasn't on the "bleeding edge" with my hardware at the time, but I wasn't far behind.

Re:Works pretty well

[Prophet of Nixon]

That's really odd... I had a Socket 5 board (it used to be a P150) with a P233 via a socket converter (but it was crippled by the 50MHz bus and ran somewhere around 180), 64 MB RAM, and a passthrough Voodoo2, and got well over 60 FPS at 800x600. Anything that actually supported Glide ran great, and a few games would actually do 1024x768, despite 3dFX's claim that SLI was required for that resolution. Games that only supported real OpenGL (not Glide or '3dFX OpenGL') ran a bit slower, but not below 30 FPS. Unreal, Half-Life, SiN (a heavily modified Quake 2 engine), Hexen II, etc all ran very well on that system.

I actually didn't replace that P233 until late 1999. I didn't like Pentium IIs and refused to buy one (for some strong conviction that I can no longer remember), so I waited until the Pentium III to upgrade.

If I was Sun CEO...

[should_be_linear]

... I would give this guy research lab and resources to create java-based DirectX library. For game developers, it would be just great to write once and sell on Windows on Linux on Mac on Playstation (don't know about XBox). Even without Sun's support, it would be great fot 3rd party to sell such engine/framework.

Re:If I was Sun CEO...

[nick-less]

... I would give this guy research lab and resources to create java-based DirectX library. For game developers, it would be just great to write once and sell on Windows on Linux on Mac on Playstation (don't know about XBox). Even without Sun's support, it would be great fot 3rd party to sell such engine/framework.

You'd have to give it away for free to make *anyone* throw away their well-tested-and-working C++ engines for a Java Version. No matter how fast it is, the java=slow paradigm is burned to deep into to many developer heads out there...

Re:If I was Sun CEO...

[Anonymous Coward]

Oh you mean like SDL?
http://sourceforge.net/projects/sdljava/

Re:If I was Sun CEO...

[TheRaven64]

Java already has an OpenGL interface (presumably what this is using). I don't know what this guy is using for sound (although the Java Media Framework might work), or input, but presumably all of the pieces are already there. What Sun really needs to do is market Java better as a game development platform. Add some code for loading models as OpenGL display lists, and a few other convenience methods and start plugging the platform better. Oh, and relax the licensing so I can run Java on my FreeBSD box without jumping through hoops.

Re:If I was Sun CEO...

[realinvalidname]

Java already has an OpenGL interface (presumably what this is using). I don't know what this guy is using for sound (although the Java Media Framework might work), or input, but presumably all of the pieces are already there.

Yes, probably JOGL for the OpenGL. For sound, core Java can handle raw PCM, and JOAL (Java Bindings for OpenAL) can sit on top of that. Java Media Framework is useless and effectively dead. Input can be handled by JInput.

Re:If I was Sun CEO...

[should_be_linear]

Still, there are things that needs to be addressed:
- Multiplayer should allow voice and webcam communication.
- There should be Servers and bandwidth available for Multiplayer games.
- All parts of this library must be able to run on Windows/Linux/Mac/Playstation (including JRE and SPU support on PS3)
- There should be new graphic instructions in Java JRE (based on OpenGL API) that directly maps to OpenGL driver and don't need RMI layer.
- There could be "iTunes for games" service that provides all games and previews on a single place (money generator)

Re:If I was Sun CEO...

[Anonymous Coward]

Their website shows the framerate going up by about a third by switching from jogl to fastjogl.

Re:If I was Sun CEO...

[purple_cobra]

Chrome was written in Java, and playing that would turn most gamers off Java for life: it was slow and buggy, and it didn't help that the game was utter crap. I believe a sequel has been released but I've no idea if that was written in Java too.

Re:If I was Sun CEO...

[samkass]

... I would give this guy research lab and resources to create java-based DirectX library. For game developers, it would be just great to write once and sell on Windows on Linux on Mac on Playstation (don't know about XBox). Even without Sun's support, it would be great fot 3rd party to sell such engine/framework.

Since almost everyone already has a good OpenGL library, including Java, why not just write for that and deploy on everything that supports it, and give people a research lab and resources to maintain XBox and Playstation versions of OpenGL?

Re:If I was Sun CEO...

[Listen Up]

"What Sun really needs to do is market Java better as a game development platform."

Exactly.

Re:If I was Sun CEO...

[Billly Gates]

You mean java3d?

I looked for opengl in java and found no implementations. I admit I only looked casually but I do plan to do some coding in java next semester at school and would like to know.

Yes, but does in run

[Kj0n]

in Firefox?

Re:Yes, but does in run

[timeOday]

I don't konw about firefox, but it doesn't do anything in Mozilla (just asks what to do with the jnlp file). So I put in "java", which just crashed the browser instantly. So after a little web searching apparently there's a "javaws" program? But blackdown-jdk-1.4.1 doesn't have any such thing. Sigh.

Re:Yes, but does in run

[The Mgt]

You can download Java Web Start from here.

works on a mac

[Anonymous Coward]

Runs great on my 1.2 GHz G4 with 640 MB of RAM in OS X 10.4.3. Running the web start version downloads a file which starts up as a separate java program.

This is the coolest use of Java I've ever seen.

Re:works on a mac

[bedouin]

What are you defining as 'great?' It works nicely on my 1.4ghz G4 with 1gb of ram and a GeForce 4 Ti4600 until more than a few enemies are on the screen, at which point it slows down considerably.

Quake 2 seminal?

[Malc]

No, I don't think so. Perhaps if you were born after 1985. Wolf 3D and Doom were the seminal games, or perhaps even Ultima Underworld, although nobody seems to remember that one. There were many games in the genre making it appear tired and unoriginal long before Quake 2 came along with a bit more of the same.

I've played Quake 2 than all the rest put together, but that doesn't make it seminal.

Re:Quake 2 seminal?

[Antonymous Flower]

Quake 2 was the first game designed for and supporting 3d acceleration out of the box. In this way it is certainly seminal. So much so, in fact, that 3d acceleration is no longer a part of the collective consumer consciousness :)

Re:Quake 2 seminal?

[Chrontius]

If you consider Quake2 as the first game to really make it while introducing proper mouselook to the masses, yes it is. Duke3D had it, but it was wonkky enough to make me seasick so it never got used. Quake2 gave you the ability to do much more with it than anything prior, even Quake, where it was not really needed and played by the best gamers I know with pure keyboard.

Re:Quake 2 seminal?

[NardofDoom]

Wolfenstein 3D and Doom aren't seminal. Marathon was seminal. It was the first one that actually had a story and puzzles to figure out. Wolfenstein and Doom aren't even in Marathon's league when it comes to gameplay.

Re:Quake 2 seminal?

[Generic Guy]

Perhaps he meant Quake 2 was seminal towards id's use of more than brown and green in the color palette.

Re:Quake 2 seminal?

[Anonymous Coward]

If you consider Quake2 as the first game to really make it while introducing proper mouselook to the masses, yes it is

s/Quake2/Marathon

T,FTFY

Re:Quake 2 seminal?

[Malc]

I think what you've described, and the features described by others in their replies are just part of the natural evolution of the same concept. I was bored and fed-up with FPS games before Q2 came along. It sucked me back in for many more years. But that didn't make it seminal as a game. It was more of the same, just with better graphics and more refined controls.

The advances made at ID Software in computer graphics are impressive. Unfortunately a lot of games are afflicted by an obsession with the graphics and special effects, often leading to a product that is either unoriginal, or just not a good game. I put hits like Halo or Splinter Cell in to that category - with those my thought processes and actions aren't much different to games I was playing a decade ago. But I digress...

Re:Quake 2 seminal?

[Bezben]

It changed it's name to snickers.

Re:Quake 2 seminal?

[HD Webdev]

Quake2 gave you the ability to do much more with it than anything prior, even Quake, where it was not really needed and played by the best gamers I know with pure keyboard.

Good Quake1 Capture The Flag players did not use "keyboard only" because all of the volume of a map was available for players to use via the grapple.

Those who did not use a mouse couldn't keep up with and track the mouse users. They were left in the dust.

Re:Quake 2 seminal?

[ginbot462]

UW (and UW2 of course) rock. Nothing beats downing mushrooms then throwing some cheese at goblins.

Seriously, most games nowadays lack the depth of Underworld. Example: It allowed you to take notes on the map. This little feature is so useful for playing the game, then coming back months later and not knowing what you were doing. Good God - I wish Diablo had stolen that idea from 1992.

Re:Quake 2 seminal?

[Gord]

> Quake 2 was the first game designed for and supporting 3d acceleration out of the box.

Needlesly picky comment coming up...

One of the first, but not _the_ first. According to GameSpot QuakeII was released 30th Nov 1997.

Shadows of the Empire, which was 3d card only, came out on 31th Aug 1997.

Also Jedi Knight which supported 3d acceleration was released 30th Sept 1997.

I'm sure there are other examples.

Re:Quake 2 seminal?

[The_reformant]

Ultima underworld was great..I remember I didnt find out about mantras until about halfway through and the only two I had were for unarmed combat and jumping. The great thing was the punching was so fast i became a killing machine :)

Re:Quake 2 seminal?

[WWWWolf]

If you consider Quake2 as the first game to really make it while introducing proper mouselook to the masses, yes it is.

Quake 1 had a perfectly working mouselook. (Put "+mlook" in autoexec.cfg.) Every good player used it back in the day, I was "nope, sounds too difficult to me, I think I'll stick to the keyboard" (which is why I stayed a rookie all the time)... Then several years later, after things like Half-Life and Q3A, when I wanted to play Q1 again I was thinking "Hey, where's my mouselook?" =)

Re:Quake 2 seminal?

[Malor]

That's literally true, but Tomb Raider supported 3D acceleration well before Q2 did. You had to download a patch, which does make your statement true, but I think most gamers from the time will point at Tomb Raider as the inflection point, not Quake.

Re:Quake 2 seminal?

[Billly Gates]

Go google glquake?

Quake1 was written in a %100 3d engine. It was software by default since 3d cards were coming out in teh final weeks when it was released.

Glquake is a patch that uses opengl acceleration and windows rather than dos api's. I was impressed since I bought the first vodoo1's and bilinear filtering and smooth colors rather than pixelating walls were SOOO COOL!

Glquake is the only way to run quake on windowsNT based systems. I think there is winquake as well but it does not have any opengl support.

Re:Quake 2 seminal?

[Monkier]

so many memories... there was a version of Descent that came with my mate's Creative 3D-Blaster (s3virge - i think?). that wasn't really any different. i remember quake was the first game I had that didn't 'support' the PC speaker! :)

Re:Quake 2 seminal?

[Billly Gates]

I had the blaster. It sucked!

No real 3d boast in performance over software emulation. But the vodoo 3dfx really was a real 3d card and the games looked soo much better.

Quake1 I know for a fact was the first 3d game in id. Doom was a 2d hack. I wonder if descent is really 3d as well. I knew it had degrees of freedom that interplay's marketing department boasted about.

I miss descent for network play. It was the best right up there with quake3.

Re:Quake 2 seminal?

[leoPetr]

Seminal means "highly influential", not "great". Marathon may be a far better game than Doom, but I would doubt any assertion to the effect that it is more influential than Doom.

dupe

[tduff]

dupe

Re:"...performance is similar to original C versio

[steevc]

Check out the benchmarks. Similar frame rates to the C version on the same hardware.

I've not tried it myself yet. Might get in trouble at work.

Performance myth.

[adolfojp]

Jvm apps can be faster than their compiled counterparts, specially when compared to those made with non specialized compilers like GCC. The "virtual machine = slow" myth is no longer true.

The real issue is startup time and initial memory consumption. Java is not suitable for applets that run in the background because your basic app will require about 20 megs of RAM minimum to start. Another issue is swing. You can disagree with me, but please wake me up when it gets clear type fonts on windows.

Cheers,
Adolfo

Re:Performance myth.

[Listen Up]

Java is exactly as other people say it is, fast and scalable, when written by professional Java programmers in a professional development environment. Judging Java by some no name piece of code is not exactly an intelligent judgement call.

Re:Performance myth.

[Listen Up]

Startup time should not be an issue any more with properly written programs using JDK 1.5 and up thanks to technologies such as Class Data Sharing. Thanks to Apple for pioneering this technology. There are many, many other examples and documentation on Sun's website explaining how to properly code Java programs to optimize their startup execution, but CDS is a technology aimed directly at assisting startup times of Java programs.

Class Data Sharing

Sun

IBM

Apple

Re:Performance myth.

[adolfojp]

I agree wholeheartedly. I use a few Swing JVM apps that when minimized shrink to 2 or 3 megs, but when maximized can expand easilly to a 100MB. (Oracle JDeveloper, Java Studio Creator...) If the system doesn't have enough ram to "not need a swap file" you WILL have an unusable application.

The problem is not the virtual machine but the display libraries. Jake2 is fast because it uses OpenGL. Azureus and RadRails are fast because they use SWT.

Of course, a java zealot will always insist that the slow performance is all in your head even if you are standing in front of him with JDip and a timer ;-) Cheers,
Adolfo

Re:Get ready for some low FPS!

[Anonymous Coward]

Actually, it runs pretty quickly, although not quite as quickly as the original. Something like 85-90%. That's mostly because of the overhead of calling into the OpenGL libraries from Java, and because Quake 2 was written at a time when 3D games were fillrate limited, not CPU limited. Back then, the extra overhead of sending models one vertex at a time was essentially zero, because you were still sending the data faster than the graphics card could render it. With modern graphics cards, Quake 2 becomes CPU limited. The extra overhead of all those unnecessary OpenGL calls is even greater in Java than it is in C, so it ends up running slower.

It'd probably be better if the game were designed as a Java program, rather than a C program. The Java code is a fairly close port of the original C, so it does quite a few things which aren't optimal for a Java program.

Comparisons with the .NET version of Quake2?

[Numen]

Can we get a comparison of the Java and .NET ports of this?

The .NET port can be found at http://www.vertigosoftware.com/Quake2.htm

Re:Comparisons with the .NET version of Quake2?

[sbrown123]

Use of unmanaged C++ code inside the the .NET Quake engine makes a comparison a bit slippery. Sure, you could reason that since thats a feature of .NET, that it should count. But then again, they use it so much (C++) that it can barely be called .NET but rather a mere wrapper around a C++ engine.

Re:Comparisons with the .NET version of Quake2?

[zootm]

There is a managed version as well, apparently, that's probably the one that should be used for fair comparison. The language feature argument should, as you say, be discounted, since JNI is likewise a feature of Java — it doesn't mean it's fair game to just call native code because of this, though.

Re:Comparisons with the .NET version of Quake2?

[TheSlashFrog]

Just do the math:

According to http://www.bytonic.de/html/benchmarks.html, Java version performance is 79% to 106% of original C code.

According to http://www.vertigosoftware.com/Quake2FAQ.htm, Managed C++.NET version performance is about 85% of natice C++, and they are both slower than original C code.

There's a small advantage for Java, but the performance is essencially the same. Not surprising, since Java and .NET have very similar architectures (Java bytecode running on a JVM versus .NET common language running on a CLR)

Re:Comparisons with the .NET version of Quake2?

[sbrown123]

JNI is likewise a feature of Java -- it doesn't mean it's fair game to just call native code because of this, though.

I did not scroll down far enough to see they had a managed version. Yes, I could see if Jake2 called C++ code using JNI outside just calling the OpenGL/OpenAL bindings to get performance than that would discount the comparison too. I will have to investigate this "fastjogl".

The managed .NET code, according to the developers, runs 85% the speed of the original C game. This seems to be approximately what the Jake2 project has achieved. 85% to me appears to be a win for both .NET and Java as "possible" game platforms.

Re:Comparisons with the .NET version of Quake2?

[samkass]

What they call "fastogl" is just a port of the Quake2 code to use display lists instead of direct OpenGL vertex calls. The non-"fastogl" version is a direct, line-by-line port of the original. They both use JOGL.

The Java Version uses accelerated 3D

[Anonymous Coward]

Most users that played Quake2 did not have hardware with builtin 3D acceleration. So the folks at idsoftware improved their already outstanding software rasterizer for Quake2, which provided almost identical rasterizing performance on then-highend machines compared to modern 3d cards at that time.
If the Java version would do the same, then I would take my java performance prejudices and dump them.

Re:The Java Version uses accelerated 3D

[Midnight Thunder]

This version uses "JOGL", which is a Java wrapper to OpenGL.

Re:The Java Version uses accelerated 3D

[shutdown -p now]

Wasn't Q2 software renderer inner loops hand-written in assembly, though?

Re:"...performance is similar to original C versio

[sprins]

Don't underestimate the execution-speed of Java in a decent JVM. For example: My Java-based HTTPD outruns Apache HTTPD for static file serving.

Re:"...performance is similar to original C versio

[cbreaker]

Don't be a luddite. The port runs really well.

The Slowness Of Java

[Lagged2Death]

Even with 512MB of RAM, Azureus (the hugely popular Java-based BitTorrent client) takes forever to start up, responds sluggishly to user input, and sucks down so much RAM that the Windows PC it's running on is nearly useless for any other task. This isn't simply the nature of BitTorrent - other clients run far more smoothly.

Maybe there are reasons for this that aren't directly related to Java. Maybe Azureus just isn't very well-written, or maybe it's just feature-bloated. Maybe the Windows JVM just stinks.

But in any case, the common perception of Java applications as being slow and ponderous is one that Java applications have earned - there are actual reasons, based on real-world experiences, that cause people to feel this way. That has nothing to do with some pig-headed resistance to change.

Rather than railing against the Java-haters, why not point out some useful, slick, fast Java-based applications? I'd love to see some. Every one that I've tried so far has been a disaster in one way or another. I honestly want to like Java. I like the language, I love the concept - it's the real-world experience with it that I have a problem with.

Re:The Slowness Of Java

[FatherOfONe]

"Rather than railing against the Java-haters, why not point out some useful, slick, fast Java-based applications? I'd love to see some."

Um, you did see what the article is about didn't you? Perhaps you should try it out.

I have used quite a few Java programs and most perform well.

Re:The Slowness Of Java

[CowboyBob500]

Even with 512MB of RAM, Azureus (the hugely popular Java-based BitTorrent client) takes forever to start up, responds sluggishly to user input, and sucks down so much RAM that the Windows PC it's running on is nearly useless for any other task.

One word. Bollocks. I have Azureus running right now. As well as NetBeans, OC4J, VMWare and whole host of other things. Either you don't know one end of a computer from another or you're deliberately spreading FUD.

Bob

top - 14:51:58 up 5:33, 6 users, load average: 0.18, 0.17, 0.51
Tasks: 116 total, 2 running, 114 sleeping, 0 stopped, 0 zombie
Cpu(s): 2.7% us, 1.0% sy, 0.0% ni, 91.3% id, 4.0% wa, 0.7% hi, 0.3% si
Mem: 2076528k total, 1662764k used, 413764k free, 67972k buffers
Swap: 4088500k total, 463460k used, 3625040k free, 1072344k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
8540 mparker -51 0 30176 15m 14m S 3.0 0.8 3:32.12 artsd
7774 mparker 16 0 38724 1032 512 S 0.3 0.0 0:00.92 ocssd.bin
14289 mparker 16 0 2056 992 752 R 0.3 0.0 0:00.04 top
1 root 16 0 680 60 36 S 0.0 0.0 0:01.00 init
2 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/0
3 root 10 -5 0 0 0 S 0.0 0.0 0:00.18 events/0
4 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 khelper
9 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kthread
19 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 kacpid
142 root 10 -5 0 0 0 S 0.0 0.0 0:00.76 kblockd/0
185 root 12 -5 0 0 0 S 0.0 0.0 0:00.00 aio/0
184 root 15 0 0 0 0 S 0.0 0.0 0:07.55 kswapd0
778 root 15 0 0 0 0 S 0.0 0.0 0:00.00 kseriod
1014 root 11 -5 0 0 0 S 0.0 0.0 0:00.00 ata/0
1020 root 20 0 0 0 0 S 0.0 0.0 0:00.00 scsi_eh_0
1021 root 21 0 0 0 0 S 0.0 0.0 0:00.00 scsi_eh_1
1248 root 10 -5 0 0 0 S 0.0 0.0 0:00.57 reiserfs/0

mparker 8616 7989 0 09:51 ? 00:00:00 /bin/sh /usr/local/netbeans36/bin/runide.sh
mparker 8635 8616 0 09:51 ? 00:01:31 /usr/local/jdk1.5.0_03/bin/java -Djdk.home=/usr/local/jdk1.5.0_03 -classpath /usr/local/netbeans36/lib/ext/boot.jar:/usr/local/ jdk1.5.0_03/lib/dt.jar:/usr/local/jdk1.5.0_03/lib/ htmlconverter.jar:/usr/local/jdk1.5.0_03/lib/jcons ole.jar:/usr/local/jdk1.5.0_03/lib/sa-jdi.jar:/usr /local/jdk1.5.0_03/lib/tools.jar -Dnetbeans.osenv=/tmp/nbenv.8616 -Dnetbeans.osenv.nullsep=true -Dnetbeans.home=/usr/local/netbeans36 -Djava.security.policy=/usr/local/netbeans36/bin/i de.policy -Xms24m -Xmx96m -Xverify:none org.netbeans.Main --userdir /home/mparker/.netbeans/3.6
mparker 11799 7989 0 12:44 ? 00:00:05 /usr/lib/vmware/bin/vmware
mparker 11810 11799 0 12:44 ? 00:01:16 /usr/lib/vmware/bin/vmware-vmx -@ pipe=/tmp/vmware-mparker/vmx4380c2c9c1cd53db;vm=43 80c2c9c1cd53db /home/mparker/VMWare/Windows XP Professional/Windows XP Professional.vmx
mparker 11868 7989 0 12:55 ? 00:00:00 /bin/bash /usr/local/azureus/azureus
mparker 11873 11868 1 12:55 ? 00:01:38 /usr/local/jdk1.5.0_03/bin/java -Xms16m -Xmx128m -cp /usr/local/azureus//Azureus2.jar:/usr/local/azureu s//swt.jar:/usr/local/azureus//swt-mozilla.jar:/us r/local/azureus//swt-pi.jar -Djava.library.path=/usr/local/azureus/ -Dazureus.install.path=/usr/local/azureus/ org.gudy.azureus2.ui.swt.Main
mparker 13824 10435 1 14:31 pts/2 00:00:19 java -jar oc4j.jar

ps output abridged to avoid lameness filter.

Re:The Slowness Of Java

[Anonymous Coward]

A port of Quake 2 that is slower and uses more memory than the native client that was released seven years ago?

Re:The Slowness Of Java

[Ced_Ex]

Even with 512MB of RAM, Azureus (the hugely popular Java-based BitTorrent client) takes forever to start up, responds sluggishly to user input, and sucks down so much RAM that the Windows PC it's running on is nearly useless for any other task. This isn't simply the nature of BitTorrent - other clients run far more smoothly.

Maybe there are reasons for this that aren't directly related to Java. Maybe Azureus just isn't very well-written, or maybe it's just feature-bloated. Maybe the Windows JVM just stinks.

I have not noticed anything that you describe. My Azureus runs just as fast as anything else I have running at that time. In fact, I can even work on several photoshop items at the same time I'm using Azureus and have not experienced any slight slow down or sluggishness.

Perhaps it is your own setup?

Re:The Slowness Of Java

[locnar42]

Having picked up Java after using C/C++ for about 10 years, I find the biggest irratation to be the speed (or lack of) that programs run. The language itself is great. The UI is usually the worst part. I highly recommend checking out SWT from Eclipse. I think a lot of the hardcore Java freaks don't like it because it's not true Java and goes direct to the OS, but it can produce a great UI that isn't painful to use.

In theory, the JIT should be able to produce code that runs as fast or faster than C/C++. The JIT compiler has much more knowledge of the execution environment (CPU, memory, graphics) and should be able to optimize the program exactly for this one computer. It has't happened yet though. I'm waiting for it though because Java 5.0 is a fantastic language and I would love to drop C++ for it.

Right now, SWT is the only thing I've found that makes Java UIs bearable for the majority of programs. There are always exceptions to the rule and I'm sure there are some applications where the developers have been able to get decent speed with Java, but the typical C++ program has a considerably more responsive UI than the equivalent Java program when written by programmers of similar talent.

Re:The Slowness Of Java

[SComps]

Either you don't know one end of a computer from another or you're deliberately spreading FUD.

Or he might be a normal non-evangelical java junkie that runs it out of the box. Like me. It runs like shit on my sytems too, and everyone else I know that runs it.. runs like shit. Of course they're not going to tweak the VM, the applications or run around in a handful of config files or whatever else you've done to manage to get it to perform reasonably. Fact of the matter is that it works file for you, and doesn't for him (or me et al)

It doesn't mean he's unable to determine the linear end points on his computer any more than it determines you're able to recognize the difference between your posterior and a pitch fork.

notice, I was able to state my opinion without backing it up with a bunch of useless output from a console. (which mind you is dubious in that I'm sure you can use vi. You're the kind of person that loves vi right?)

Re:The Slowness Of Java

[iapetus]

If only something would come along that would make SWT bearable for the majority of programmers. Working with tables in SWT is enough to make me want to hunt down and kill whoever designed them...

Re:The Slowness Of Java

[CowboyBob500]

Or he might be a normal non-evangelical java junkie that runs it out of the box. Like me.

And me, I'm running a vanilla Java 5 VM with no tweaking.

It runs like shit on my sytems too, and everyone else I know that runs it.. runs like shit. Of course they're not going to tweak the VM, the applications or run around in a handful of config files or whatever else you've done to manage to get it to perform reasonably.

I've done no tweaking whatsoever. Just installed the applications and then run them.

notice, I was able to state my opinion without backing it up with a bunch of useless output from a console. (which mind you is dubious in that I'm sure you can use vi. You're the kind of person that loves vi right?)

Translation - you can't back up your statements.

Bob

Re:The Slowness Of Java

[CowboyBob500]

I made no mention of memory usage - I was pointing out using top that the applications are using less CPU than artsd. Besides I've got 2Gb of RAM in this machine. 81Mb barely registers as a blip.

Bob

Re:The Slowness Of Java

[magoghm]

Try this: www.jrman.org

Re:The Slowness Of Java

[FatherOfONe]

Written by arguably one of the greatest C programmers around. Was the port done by a company? I wonder what the performance hit would be just doing it in C++?

It is amazing that it was even done at all.

Re:The Slowness Of Java

[KinkoBlast]

I haven't had any problems with az... Hell, i've played Half-Life 2 with Az running! Then again, I just upgraded from a p2 286mhz to a AMD Athelon64 2ghz, so maybe i'm more tolerent of poorer proformence...

Re:The Slowness Of Java

[Anonymous Coward]

The benchmarks clearly show that the java version is as fast as the original C version.

Re:The Slowness Of Java

[aJavaProgrammer]

IntelliJ Idea is a amazingly fast considering the number of features that apply to every keystroke (code completion, for example.)

A LOT of enterprise server-side application development is done in java. It's plenty fast for most things. In my java middleware app, we spend most of our time waiting for responses from databases and mainframes. I haven't seen the src for Azureus so I can't comment on it. FWIW, LimeWire performance is decent, but Idea is the gold standard for java gui apps.

john

Re:The Slowness Of Java

[bartok]

"I have used quite a few Java programs and most perform well."

Name them.

Re:The Slowness Of Java

[rafa]

and yet azureus still a memory hog.

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
8216 anglerud 15 0 418m 80m 12m S 0.3 15.9 10:45.20 java

Re:The Slowness Of Java

[GileadGreene]

Rather than railing against the Java-haters, why not point out some useful, slick, fast Java-based applications?

I've had a pretty good experience with jEdit, a Java-based programmer's editor on both Linux and OS X. It's mostly replaced emacs for me now. Although I've only tinkered with Eclipse so far, it's been pretty responsive for everything I've tried. On the Mac, NeoOffice/J (the OS X port of OpenOffice.org, which relies on Java for access to the Cocoa API) seesm to run pretty well. Granted, these are all editing apps, but they're all produced by different dev teams, and all seem to work well.

Re:The Slowness Of Java

[Listen Up]

Java does not earn its reputation, bad programming and bad programming practices give it a bad reputation, with those outside of the professional programming world.

As a Senior Software Engineer with over 8 years of Java programming experience, I can tell you that the real problem is that %99 of programmers do not know how to properly program Java or OOPL's in general. The other %1 do not put the time into making their Java programs professional grade. You can read Sun's JDK documentation and examples showing how Java -should- be programmed from an OOP perspective and how Java is very strict in its interpretation and usage. You can read Sun's documentation and example code showing how to optimize every aspect of a Java program, especially very large highly scaled applications. But, what is happening is that without even reading the Java documentation, bad C/C++ programmers are trying out Java, using bad C/C++ code practices and understanding, and applying them directly to Java. Sure, the bad Java code will compile and run, but will run very poorly. Then Java is blamed and the programmers go back to programming bad C/C++ code without even looking into what the problem may have been to begin with. And this does not even begin to cover people who are trying to transfer over from programming VB.

Now that C# is becoming more popular, which is very close in syntax and concept as Java, along with better Java IDE's, optimizers, programming and testing tools, excellent new JDK features and additions (1.5 is excellent and 1.6 looks to be even more exciting), and excellent JVM's for all supported platforms hopefully programmers will become more educated in programming Java and OOPL's in general.

I have personally, along with my programming team, written many J2SE and J2EE applications which are extremely fast, extremely stable, and extremely scalable. I can only think of a handful of applications which might be better written in any language -except- Java.

To add to what one of the parent posters said, Java bashers/haters are those who have no real experience with the language in a corporate or production environment, especially an environment run by a group of professional and experienced Java programmers. Most people's experiences with Java was back in the 1.0 days and have no idea how far Java has come to reach 1.5 and how many more exciting features are coming in 1.6. On the home computer side of things, Azuerus is nice, I use it myself but it is not the best Java code ever written. Nor has most of the Java code I have seen in the open source programs I have checked out in recent years.

Re:The Slowness Of Java

[Anonymous Coward]

In all fairness, if you look at the benchmarks, they have continued to close the gap in terms of performance with each successive version. The windowed 800x600 version is in some cases faster than the original C code.

It does not seem unreasonable to expect them to further close the gap or surpass the original code in terms of performance in the future.

Re:The Slowness Of Java

[Lagged2Death]

Um, you did see what the article is about didn't you? Perhaps you should try it out.

Other posters here have commented that that the servers offering up 30+MB of game assets per user are completely borked by legions of Slashdotters. Plus, I'm at work. I'd love to give this a go, but this is a bad moment.

If you had some office-work, code-editing type applications in mind, maybe I'd try those, though.

Re:The Slowness Of Java

[Lagged2Death]

One word. Bollocks. I have Azureus running right now. [On a Linux PC with 2GB of RAM].

Do you really feel that your experience running Linux in 2048MB somehow negates my experience running Windows in 512MB?

Perhaps there are JVM tweaks that might improve the situation. I've never looked. I'm not interested. Why should I have to resort to such things? I've switched to uTorrent, which does everything I want in about 1/20th the RAM, no tweaking required.

Re:The Slowness Of Java

[Lagged2Death]

All these replies to my post (which honestly wasn't intended as flame-bait) and only one person actually links to a good Java app. Marvelous.

I've bookmarked this and I'll definitely give it a try. Thanks!

Re:The Slowness Of Java

[lRem]

My general feeling is that most software written seven years ago was faster (relatively to CPU power) and used far less RAM.

Re:The Slowness Of Java

[el_womble]

I'm running a iMac G5 1.8GHz with 1GB of RAM and I'm a Java developer.

The game was playable and really took me back to 1997 and the first time I played Quake2 - a little too much. No other applications running and it still stuttered when a new model appeared. When it was just pulling things from memory the game ran incredibly smoothly.

This is easily the most impressive piece of Java programming I have ever seen. The game was responsive, and the graphics are amazing but you still get the feeling that the JIT was playing catchup in certain sections.

I have no doubt that this could match a C compiled version as 95% of the time it was running incredibly smoothly. But gaming is about a smooth, immersive experience (especially FPS) the semi-random 'jerks' make you aware that you are still playing a computer game and thats the real problem for a commercial vendor.

The one thing that you could probably get from Java that you wouldn't get from C is instant multi-processor support. Given two processors I see no reason why JIT / GC couldn't run in a seperate thread and provide the smooth experiance that we all crave. Not having a dual processor system I can't verify this theory, but this is where I expect to see real advances in the near future. We're already seeing that the first round of games for the 360 arn't fully utlizing the 3 cores, wouldn't garbage collection and JVM be a decent application for those wasted cores? It would certainly reduce the development times, and allow for games to be written for PS3 and the 360 simultaneously and, lets face it, Java development is significantly easier, easier to debug and significantly less prone to crashes.

To see this happen we need to see Sun / IBM developing a JVM for all the next gen consoles that really take advantage of the new architectures. There needs to be better SIMD support and it needs to be transparent to the developer.

Re:The Slowness Of Java

[Lagged2Death]

Perhaps it is "my own setup," the PC is getting a little long in the tooth. But it's not lacking for CPU power. Something like Photoshop might run OK. The slowdown I've noticed excessive disk thrashing from Azureus's RAM consumption and monopolization of the system cache. Tasks which require a lot (or even a little) disk access get quite sluggish. ZIP archiving, usenet decodes, even simple web browsing - things which the PC usually does fairly snappily - become painful. And it gets worse when seeding multiple torrents.

I've got no bone to pick with Java; I'm just pointing out that it still compares unfavorably with precompiled code in real-world, end-user, desktop-type applications, particularly when RAM is tight. If you have a monster desktop, you may not notice, and if you're writing server code, you may not care. That doesn't mean Java is efficient.

Re:The Slowness Of Java

[istrebitjel]

Hey, I get 2.5 SPF on my linux box! OK, without any graphics acceleration...

On my mediocre P4 XP laptop I get 38 FPS :)

Re:The Slowness Of Java

[matfud]

Is that you Adrian? Sounds familiar

Re:The Slowness Of Java

[EmperorKagato]

What version of Azureus are you using?

Re:The Slowness Of Java

[Wolfier]

Not everyone is running with 2GB of RAM.  Most computers sold today still come with 512MB.  Thus, to measure the expected speed of Java you have to take this into account.

When I still had 512MB I tried runining Matlab, Azureus, JSVN and JAlbum (so you can see, I AM a Java fan), my box slowed to a crawl.  The solution?  I had to run Matlab with -nojvm.

I don't have this problem now since I upgraded to 2GB.  Still, had all these apps been native, they wouldn't be such resource hogs.

Had Sun actually thought how to stop different Java apps from loading their own JVM and JRE, it could have really changed people's perception.

Re:The Slowness Of Java

[FLAGGR]

Uh porting code is no where near the feat of writing it, alot of the things they just renamed files .java :P not that great of a feat.

Re:The Slowness Of Java

[cecom]

LOL. Same here - designwise SWT looks like a cleaner version of MFC :-) Also, it is worth pointing out that SWT under Linux is 2-3x slower than Windows. Still usable, but sometimes can be quite annoying.

Re:The Slowness Of Java

[FatherOfONe]

that was my point. it was desinged in c. not c++ and was ported to java as is. it was not architected from the ground up around java or any oo language. it is amazing it does as well as it does and is a testimate to how far java has come.

Re:The Slowness Of Java

[Alban]

The C version could be optimized as well.

Re:The Slowness Of Java

[Alban]

You sound like an armchair general talking about how it is in the trenches (posting as an AC, no less).

John Carmack is not the greatest programmer, but he is a damn fine programmer. He has shipped tons of games, and shipping games is an incredibly difficult thing. You also have to keep in mind that until quake2 included, he handled almost all major programming tasks (rendering, networking, architecture). Doom is one of the first games I've seen to cleverly use the same client/server architecture whether you are playing a single player or multiplayer game. Carmack is an extremely focused and fast programmer that ships games.

It is just soooo easy to look at code and call out its flaws. Would you like to release some of your code online for all of us to scrutinize?

Re:The Slowness Of Java

[jmccay]

It performs well on a fast computer. Let's see them try running this version of Quake on a p2 350 with under 512M memory!

Re:The Slowness Of Java

[doc modulo]

Mod parent up please, because I think he's (she's) right.

In the future, PC's will have a good Java setup. 1GB of memory and 2 processor cores. One for the program and one for the JVM.

However, to use additional cores for the program as well, not just the JVM, you'll need another programming language like Erlang. This is because Java uses shared memory multiprocessing and Erlang uses message based concurrency. Just like Java prevents memory errors because of it's design, Erlang prevents concurrency errors because of it's design.

But hey, Java is still 2x to 4x faster than Erlang if you don't use 4 cores, so until then, let's use Java's (or even more O.S. Mono's) advantages for the greater good of mankind.

Re:The Slowness Of Java

[FatherOfONe]

I agree. I can't understand why Quake III won't run on my 386sx with 4 MB of RAM either.

Obviously C is a bloated piece of crap, and we should all use Assembler.

Re:The Slowness Of Java

[shutdown -p now]

Direct execution speed, yes. But what about memory usage?

Re:The Slowness Of Java

[bloo9298]

Um, no, he's talking about Windows. I fall on the side of Java over C/C++ for most purposes, but Azureus really does perform abominably on Windows.

Re:The Slowness Of Java

[nogginthenog]

I've never had a problem with Azureus, and only 256Mb here. Maybe you need to update your JVM?

Re:The Slowness Of Java

[wheany]

I also have not noticed Azureus using memory or processor any more than any other program. And this is on a machine with 512 MB of memory.

On my machine by far the worst resource hog is F-Secure's real-time scanning. That can really bog down a machine. Especially when trying to open a compressed file. Add to that the virus scanning proxy that downloads and scans any files before it lets the browser get them...

Re:The Slowness Of Java

[@madeus]

I've seen to cleverly use the same client/server architecture whether you are playing a single player or multiplayer game.

That's what you get for not being a mac user.

Re:The Slowness Of Java

[tedgyz]

Weird. I always point out azureus as a fast Java program. I guess I need to downgrade my RAM. I've never thought of it as a resource hog. I monitor things pretty closely with TaskInfo and Bandwidth Monitor Pro. I guess unless I run out of RAM, I don't look at how much my apps are using.

Re:The Slowness Of Java

[jmccay]

No teverybody has the money to shell out for the latest and greatest in hardware. My point is that it seems the Java worshipers seem to be testing Java on the lastest and greatest which may not be the average system.

Re:The Slowness Of Java

[Vorax]

No teverybody has the money to shell out for the latest and greatest in hardware. My point is that it seems the Java worshipers seem to be testing Java on the lastest and greatest which may not be the average system.

What are you talking about? Do you consider the Geforce4 MX to be the latest hardware? That's what they did the Jake2/Q2 benchmarks on (http://www.bytonic.de/html/benchmarks.html). The Geforce 4MX was introduced in 2002 based, but it's a GeForce 2 (2000) chipset with an improved memory controller. It's technology is almost 6 year old - far from cutting edge.

For another example check out Tribal Trouble (http://www.oddlabs.com/technology.php) - it's a game built entirely in Java, it's 3D and it's requirements are - 700Mhz PC with a Geforce 2 MX to achieve 40FPS.

Both of these games operate just fine on below average hardware.

Re:The Slowness Of Java

[bani]

azureus performs like shit on osx as well. and linux for that matter.

Nice to see a full port, not just the game logic

[FerretFrottage]

Q2Java was a port of the Q2 game logic and used JNI IIRC to interface with the game engine since 3D graphics support and serious sound support for Java was still nascent if existing at all. I wonder how hard it will be to port my "grapple the head mod" over to this version?

yes seminal

[Stu Charlton]

Born in 77.. Quake GL was arguably the first eye-opener to 3D gaming, but Quake 2 was the first full experience with 3D cards. It holds a special place in my heart with Wolf 3D and Doom.

Good morning, Already there in Mustang

[Anonymous Coward]

Mustang (Java 6) which is under Open development (not quite open source license) already has wider support for clear type than Microsoft... So you are right its a bit late but people have invested work into that.
Swing is not slow or bloated, it just can't be compared to the native OS size since it duplicates its functionality so its memory usage seems high in the task manager. Startup time and cold start is improving with every release and building serious client side Java applications is becoming a very real option.

Benchmarks

[gr8_phk]

You forgot:

4) People who actually run benchmarks
5) People who write lower level libraries

You may argue all day long because most people don't care about a 10 or even 50 percent performance difference. As long as the GUI responds in a time that approximates "instantly" people are generally happy.

Does this JAVA version of Q2 run so well on a Pentium?

Re:"...performance is similar to original C versio

[timeOday]

Wow, the guy criticising Java performance got modded "troll" even though the benchmarks you linked to support his assertion that the port doesn't run well on the hardware quake2 was designed for. On the K6 2 350, the native version gets 56 fps, while the java port got 21 or 31 fps with the two different java packages. Even on modern hardware the java version is 25% slower in 2 of 3 cases. And yet the java contingent still flames anybody for re-asserting the "old myth" of a java runtime penalty. Wow.

Media Framework

[MrCopilot]

I don't know what this guy is using for sound (although the Java Media Framework might work), or input, but presumably all of the pieces are already there.

https://joal.dev.java.net/joal for Sound according to his site.

https://jogl.dev.java.net/jogl for OpenGL

http://www.lwjgl.org/ Light Wieght Java Game Library

Man this guy is good, he won't even let you copy paste his web text.
Seriously, good work, Are you aware Q3 has been liberated?

Re:Media Framework

[Tim C]

Man this guy is good, he won't even let you copy paste his web text.

I suspect that's a Firefox incompatibility (or if you prefer, the result of coding to IE's broken renderer), as it works fine in IE.

Re:Media Framework

[FuzzyBad-Mofo]

It has something to do with Javascript. Disabling Javascrip allows one to select text on the page with Firefox.

Re:Quake Keyboarding

[Zan Lynx]

In Quake 1 multiplayer, players who tried to play with the keyboard were called "targets." They were ridiculously easy to circle strafe and they couldn't dodge and aim at the same time.

screenshots

[tezbobobo]

Here are some screen shots, coz that's most important and what people really want and shit...

C and profile feedback optimization.

[bored]

I have two points.

Comparing a static C binary, with a JIT is sort of silly. Logically comparing a JIT with a C binary compiled with profile based feedback optimization is probably more legitimate.

Secondly, the released Quake engine had a couple of assembly routines. Proving that C wasn't always the best choice, even back then. My understanding is that the versions of quake with assembly loops are roughtly 30% faster than the C only version they are comparing this with.

In the end these sound like good results, I'm continually amazed at how fast java has gotten. The fundamental arch is pretty much broken for generating fast binaries, and it speaks volumes about the quality of the coders writing the JIT engines that they can make a stack based compilation target run fast on modern processors.

Oh, one final thing, did anyone see what C compiler they used for those numbers? I'm currious if it was the same compiler ID originally used, or one of the more modern intel compilers?

Put up or shut up.

[nobodyman]

Okay, please show me these instances of where the Java version of an app is faster than the C version. That's not a troll: I'd really like to see it. Because I'm now just as tired of the "Java is as Fast or Faster than C Now" myth as I am the "Java is Slow" myth. Time for a reality check: task-for-task, Java is slower than C, period.

Just take a look at some benchmarks. There is only 1 test out of 26 where Java beats C (compiled with either gcc or vc). One!!!

The original Quake2 had a software rendering mode as well as OpenGL. If Jake2 attempted software rendering (does it? I played a Jake2 build from several months ago and I didn't check) I seriously doubt it would come near the performance of the C version.

Does this mean that C is "better" than Java? Certainly not. I am currently writing a JSP/Servlets for a financial web app, and I'd sooner chop off my arms than try to do the same thing in C. However, I am sick of language zealots who try to argue that the [fill in the blank] language is The One True Programming Language. Java is pretty cool but when you try to sell "your" language as all things to all people you're just asking for a backlash.

Ruby is the worst offender -- I'm sure it's great but in 5 years the proponents of [some cleverly named gem or mineral] will try to link Ruby with global warming... you just wait.

Re:Put up or shut up.

[CowboyBob500]

Okay, please show me these instances of where the Java version of an app is faster than the C version.

No. And I'll tell you why. I just don't care. If an app works in the way I require it's a good app. If it doesn't, it's not.

I'm actually trying to argue against this idea that one language is better than another. If something takes 1 second longer to start when written in one language than another, or 5 seconds longer when doing some processing I don't give a shit. The only people who'd notice the difference are people who spend their entire waking life glued to a computer monitor looking for evidence that their favourite language is "better" than another.

Bob

Re:Put up or shut up.

[bentcd]

There is only 1 test out of 26 where Java beats C . . .
This would seem to support the claim that Java can be faster than C.

Re:"...performance is similar to original C versio

[Anonymous Coward]

Please use real comparisons. I could just as easily say that my OpenGL-compatible library renders faster than NVIDIA's on Linux for some random routine. What I fail to mention is that my OpenGL-compatible library happens to implement only a subset of the functionality, and hacks around the standards for speed. /not saying Java is slow, only that your example is broken

How is it bigotry?

[chaboud]

The only reason that this posting is news is that, up to now, Java programs haven't been as fast as C++ programs in the general case. Given the overwhelming experiential evidence, it would seem that the Java bigots are the ones who need to make more of a case than "it is faster because I say so." Quake 2 running on Java is a start. Quake 4 having shipped as full Java would have been a big win. That this post isn't being brushed off as non-news bears out my point.

This is really the conflation of two orthogonal arguments, though, and we should take care to avoid treating languages and their compilation/execution mechanisms as locked behaviors.

When the Cell takes over, we'll all be stuck writing for SPEs in straight C.

Re:How is it bigotry?

[tedgyz]

I tend to knee-jerk react to the "Java is slow" comments, because I have heard them since Java 1.0. Yes, in the old days Java was slow. It still CAN be slow in certain situations. It quite often IS slower than traditional languages like C and C++. When anyone presents any hint that Java might be fast, a backlash of "bullsh*t" comments come flying.

If I wanted to jump on the C/C++ side of the argument, I would point out that a lot of the runtime libraries are written in C/C++. Thus, one could argue that Java could not be fast without the native underpinnings.

Of course, this same argument could be made about Assembly level code with respect to C/C++. When I worked in the HP compiler group, we had a visit from some HP Labs researchers. There was one guy working on a floating point math function for 2 years! He had developed assembly code to get the absolute fastest performance out of the function. I'm glad there are people out there willing to do that, because I sure couldn't. :-)

I guess I should wear my asbestos pajamas when reading /. articles about Java. I would guess that Microsoft advocates have to do the same.

Re:How is it bigotry?

[bentcd]

If I wanted to jump on the C/C++ side of the argument, I would point out that a lot of the runtime libraries are written in C/C++. Thus, one could argue that Java could not be fast without the native underpinnings.
This only holds so long as the VM actually uses those libraries in its implementation. A JIT can choose to use its own optimized-for-the-task-at-hand machine code in stead, making it largely unaffected by the speed (or lack thereof) of the C or C++ compiler it was built with.
It seems likely that a JIT compiler may choose to rely on the C or C++ libraries in some cases and use its own in other cases. As JIT technology improves, one would expect the latter to become increasingly common, thereby largely decoupling the VM speed from the quality of the C or C++ compiler.

Re:How fair is this Java vs C comparison?

[sbrown123]

There is no way to write and read from lots of memory quickly in java is there?

Yes, Java came out with Native I/O API (NIO).

All benchmarks that I have looked into that show that Java runs faster then C/C++ are extremly heavily biased towards making Java look good.

I've read similar reports of .NET being better than Java. Even newer reports show that Ruby is better than .NET. I guess Ruby is the best there is. Expect a Ruby port of Quake that runs faster than the original C version ;)

Correct me if I am wrong, but in order to get towards the original C code, they have had to change the quake rendering code, and in doing so, have made Quake2 more optimal for modern video cards with modern drivers.

Yes, they optimised with vector arrays and how memory is allocated in some loops. Vector arrays meant Java sent fewer calls to OpenGL since one performance issue with Java to OpenGL is calling virtual functions (JNI). Its unlikely that using vector arrays in the original C port would do anything for performance. The memory allocation is a bit more tricky since Java works with memory differently than C and this may not be an improvement to the original C code. I haven't read the source code and have to take the developers word on all this.

But to be fair of Java, it has to go through an extra layer of interfaces to make the calls (On the other had this is always another argument why java is actually slow)

Most Java applications do not use JNI code which would make that argument rather rare in usage.

Is it true java needs more memory, does this therefore this can cause more cache thrashing?

No, the garbage collectors in Java do a pretty good job at making sure the cache is not thrashing. But, if you read some Trolls here on Slashdot they would state that Java not only ate all their computer memory but also kicked sand in their face at the beach and stole their lunch money. Depends if you WANT TO BELIEVE that Java takes 600 megs to run. It won't match reality but might make a "Java Hater" fan club member sleep easier at night.

I've actually had the experience of writing java games on mobile phones, its really sad that the performance of java has become hyped to the point where people think giving developers no other choice but java on these machines is a good idea.

This reminds me of when I was writing PalmOS apps. I was writing them in C using a modified Cygwin compiler on Windows. Some time later I came across SuperWaba and dropped the C code in a heart beat. Main reason? It was cross platform. With SuperWaba I could support all types of PalmOS platforms AND Windows CE. Seems to be the #1 reason phone companies use it too. Theres just too many different types of phones out there with different chips, operating systems, memory sizes, screen resolutions+colors, buttons, etc. Seems smart to give developers the capability to hit more devices rather than fewer. C may give you sweet access to performance for a particular machine/device but it will also lock you to it.

Actually I like GTK

[LWATCDR]

I do like GTK. I don't like GTKmm. I am actually using GTK for a project right now but I am writing my own object wrapper for it. It is not as complete as GTKmm so it doesn't use all the extra libraries that GTKmm does. C# is a none starter because the project I am doing can not afford the Mono framework overhead. It is an embedded device. I am not using Java for that project for the same reason.
  My Java programs predate mono and they work so I see no reason it porting them right now.
I am not going to learn c# anytime soon because it has no benefit for me.
1. Java works for the current application I have. I may need to add some features but there is no reason for a complete rewrite.
2. We already have around 200,000 lines of C++ code in house and when we take our flagship product cross platform we are going to buy QT for that.
3. I have to learn Python since we are going to embedded that as the macro language for our multi platform version.
4. I have to pick and choose what I learn. I don't have time to learn every new language that comes out. I would love to learn Ruby, Scheme, Smalltalk, and Lua but I have only so many hours in a day. As I said just because I dismiss it doesn't mean that it is a bad choice for everyone, just for me.

Re:Actually I like GTK

[zootm]

Fair enough reasons. :)

and the worse is...

[A2GS]

"Some simple optimizations" ? does "simple" optimizations in Quakes C/C++ 'Original C Code' too little kid... (how many java programmers knows/owns JVM/JIT/JSuck optimizations vrs. how many C/C++ programmers knows C/C++ standart code? I will not never pay $100/hour for a Java expert programmer, but $200/hour for a C++ semi-expert programmer!)

Re:and the worse is...

[Listen Up]

You are a complete moron.

And learn to spell.

Re:and the worse is...

[Listen Up]

You have it backwards. I will fix your original post for you:

"I will not never pay $100/hour for a C++ semi-expert programmer, but $200/hour for a Java expert programmer!)"

When you grow up kid, it would be best to lose your ignorance.

Re:and the worse is...

[A2GS]

1. i dont like (and i dont care) your language. I spell how I want... and you could read (i dont care how.. its enough). 2. dont change my words. they are not open source. 3. im a moron working with 3 java programmers and 1 c/c++ programmer. 3 people yet counldnt able to show me why they are good enough to kick off another 1 programmer. Could you? And they are very expert programmers (and yes... c/c++ programmer is very better payed than java programmers... and always will be, cuz he do what the others 3 cannt do.. and cuz I WANT).

Re:and the worse is...

[Listen Up]

Whatever kid.

You and the rest of the idiots should run along and play now.

Re:and the worse is...

[Vorax]

>3. im a moron working with 3 java programmers and 1 c/c++ programmer. Yes you are - not that it needed clarification. If the 3 java programmers are less productive then 1 C/C++ programmer, then they're idiots as well - that doesn't mean Java sucks, it simply means you should put the C++ guy in charge and the rest of you should go grab a "Programming for Idiots" book :)

Re:"...performance is similar to original C versio

[helix_r]

I admit that I was being harsh...

They actually did nice work. It is refreshing to see something in Java that is not a bore-me-to-tears enterprise J2EE framework.

Brightness??

[Rick Richardson]

Unplayable on my monitor. Brightness???

Well of course it runs great

[rsilvergun]

640 mb of ram should be enough for anyone.

The game is slightly altered.

[McCheese]

The first secret level is taken out. There are other small differences.

Re:The game is slightly altered.

[AlexMax2742]

Getting a rocket launcher in stage 1-3 I think was due compensation. It's a demo, so of course there are things taken out. Plays pretty much exactly like I remember the Quake 2 demo playing a long time ago.

Re:"...performance is similar to original C versio

[Wolfier]

I usually run a few more apps alongside with games.

The benchmark does not show how much memory is used - likely, they installed an ungodly amount of RAM on all machines so it's overkill for the C version and adequate for the Java version.

I'd like to see the benchmark on the minimal hardware requirements.

Re:Erm, link: B.S.

[CowboyBob500]

Oops. Non of the above

Let me guess your profile then...

and yet JAVA IS STILL SLOW.

So you're a programmer using a language that you percieve to be going out of fashion and therefore feel threatened by what's new and current and respond by churning out these "facts" to anyone who may listen.

1)Java developers trying to pull the wool over their management's eyes to continue being paid outrageous salaries for working with a flawed language at the wrong abstraction level.

So you're a wage slave who's been hacking away in their chosen language for years and is jealous of the success of others and the fact that your career seems to be passing you by.

2)People who's last and ONLY experience has been "Java"

You may as well admit it, you've never programmed in Java (or any other next-generation language for that matter) have you?

3)Immature college weenies whose idea of a regexp match is a for-next loop stepping through each character of a string.

So you've been in your career for probably about 10-15 years but haven't kept up with the times, so you have to resort to mocking others who have more knowledge than you of the latest technologies.

Bob

This isn't Java code...not..really..

[flibuste]

This is code copied from the C source. Most of the source code files say ".java" in their filename, but I hope that no JAVA developer from the 21th century writes code this way.

The effort should be saluted, but the time spent really is not worth the effort.

benchmarks

[Alban]

The benchmarks show, by the author's own admission, that the java version runs at about 60% of the C version's speed. That's to be expected, and one must keep in mind that the only part that java slowed was the part that runs on the CPU. All the work that is offloaded to the GPU would not suffer from that drop in speed.

I would like to see performance benchmarks done on an older platform where there is not huge amounts of L1 and L2 instruction caches.

Also, a 40% drop in execution speed is very significant. While Quake2 may run at "only" 200 instead of 300 on a modern machine, if we were looking at a more complex game that was barely making 30 fps on an average machine by today's standards, that 40% drop in performance would be much more noticeable.

I am wary of benchmarks that are done on machines that totally overpower the app they are running.

Dungeons of Daggorath

[zettabyte]

Dungeons of Daggorath on the TRS-80 was the first '1st person' game I ever played.

I think it could make a legitimate claim to the title "Original First Person Shooter". Even though it wasn't a shooter. All subsequent 1st person kill 'em all games are derivatives of what they did on that game.

Circa 1982, 8K.

Re:Dungeons of Daggorath

[HolyCrapSCOsux]

Has anybody seen a port?
A [space] R [enter]
A [space] R [enter]

Java 6

[kaffiene]

It's worth pointing out that pre-releases of Java 6 (Mustang) are showing in the order of 10-20% speed increases for many Java apps

see: http://www.javagaming.org/forums/index.php?topic=1 1422.0

I got 20% increase on a ray-tracer. AFAIK this is still without having implemented optimisations based on escape analysis - which are expected to be a huge win for Java, so Java performance is set for another big jump again.

Re:How fair is this Java vs C comparison?

[FLAGGR]

Mobile phones and Java don't mix. Read Carmack's (creator of Doom, Quake) blog. A game he was developing needed a seperate port for each phone, because of variations. Write once run everywhere? Ha.

Re:Erm, link: B.S.

[CowboyBob500]

#1, don't you have some slide presentations to makeup for your boss or something?

I am the boss, as well as lead developer. I run my own software company.

Bob

Excellent.... but

[Zaiff Urgulbunger]

Its amazing how well this runs. But there's no kick-back when you fire the machine gun.... so in my view it fails completely! They might as well scrap the entire thing now!! :D

Anal retentive?

[sprins]

Perhaps my example is somewhat broken, it however illustrates that a decent JVM can keep up with (or even outperform) a (perhaps not all) similar function of a C compiled product. And since in my example it applies to most of the functions of the Java product in comparison to the C product (i.e. serving HTTP and the like) I dare to state: "Don't underestimate the execution-speed of Java in a decent JVM.". Nothing more, nothing less.

Re:How fair is this Java vs C comparison?

[Dr. Photo]

"But, if you read some Trolls here on Slashdot they would state that Java not only ate all their computer memory but also kicked sand in their face at the beach and stole their lunch money."

The same Java that surrendered West Point to the hated British?*

* ;-)

Java Swing application developer for 5 years now

[Anonymous Coward]

I've been doing Java applications since 2000. If you know what you are doing they are not slow. A simple Java application has a minimum footprint of around 3MB regardless. Ever looked out how much
MS Windows Messenger takes up without you using it? About this much idle but if you click on the icon in the status bar it jumps as high as 8MB doing nothing. ;-)

There are ways to cache a JVM so if the JVM has already been loaded the needed system files to bind with the native windowing system you can't tell if it is a Java application or a native application.

This should come standard with 1.6 Mustang but it is pretty easy to do. I had code that did this with 1.3 and xMotif folks were shocked when my Swing applications loaded just as fast.

I've been doing GUI applications since VB 2.0 and have used lots of GUI builder tools on various platforms.

The part that really gets me is when people are shocked to see a Java application like this. Why is it that everyone thinks Java is still slow when it used to be embedded in a browser as an applet?

Doesn't everyone know that the JVM/JRE is written in C? If you run 'javah' from the command line you can easily create a C style header to load your system library into the JVM.

So JOGL which is the JNI version of Open GL has bindings for the different platforms.
If I told you I could write a system in C with garbage collection, threading and networking built in that was almost as fast as standard ANSI C wouldn't you believe it?

The reason Java is slower is because it is DOING MORE. It isn't THAT much slower either. I'm sure everyone out there could write a generic IP stack and garbage collector that will run all CPU platforms and scales well. ;-)

Gosling had a quote that I really love. "C has small problems, like what is an int?"
Not to mention always having to memset your heap data or run into a very big chance of ghosting values or worse yet not null terminating a string and it just run off into the kernal looking for a /0x00 value.

The HTTP loader and ability to auto load and install your application across a hetrogenous network (WebStart) is a pretty nice feature. I'm sure a lot of developers out there will miss having to use REGEDIT to figure out why their application didn't install correctly. ;-)

I don't know anything else that comes close to Java Applications. C# is the next coolest language and the author is a genious. The problem is MS has chosen to poor cement from this very cool language into the kernal. Since it makes native calls to the OS and it is a closed system. I can run a java application on Windows 98 with no problems. Can't do that with C# because it needs system dll calls that MS doesn't want to make virtual or share with anyone else. You will need to buy yet another OS upgrade from MS. ;-)

For the Mono folks out there has it shipped yet? Is anyone using it to develope anything with? I've been shipping Java appications professionally since 2000.

The JIT is the cool part that makes the JVM almost seem like magic. It dynamically profiles the code at run time. Translates the java bytecode that is used the most into native assembler on the fly. There is some overhead for this but it is a one time charge once optimized.

For those out there that say Swing doesn't do multiple threading they should google on 'Swing worker thread'. I've been using that for 5 years as well.

For those out there that have only cooked with the mirco-wave oven Java is gourmet style cooking. If popcorn is all you need then by all means stick with VB, C# or some other tool. If you want to be able to write a very cool looking GUI that will run on any platform then learn Java Swing.
Swing is the real deal. SWT is another option popular by the IBM/Eclipse community. This is a native peer JNI type call which works a lot like C#. It requires some knowledge of the native widget set

Re:JIT

[RamblerRandy]

Ok, for us NON-Java learned programmers (yes, I'm that old...) what the blazes is JIT? Other than the acronym for "Just In Time" as in a delivery methodology used in some industries I used to work with.

Re:"...performance is similar to original C versio

[BlueHands]

First off, he was modded troll because the latest version, .9.4, is VERY comparable and does not require a machine that is vastly greater than the the C version, they are very close.

Secondly, his comment adds nothing useful. he is just bitching pointless. Many trolls do that.

More importantly, even if your numbers are taken as meaningful, look at what we are talking about: A 3d java FPS that is ONLY 25% slower than a compiled C program. 3d and java were never in the same sentence, now they are.

Talking about taking a hit with java now means A LOT less than it used. It is likely java will ALWAYS be slower in most cases then C, just like C is slower than assembly. Yet for some strange reason most people rarely complain about that hit.

As with everything, right tool for the right job and java is becoming more capable of being the right tool more often every year.

could never been considered

Re:JIT

[bentcd]

The Java program is delivered as Java Bytecode. The ancient sort of VM would interpret these as some sort of half-digested shellscript and run them one by one. A JIT compiler will do this the first time, but then it may choose to remember the machine code equivalent of the bytecodes and run it directly next time. Over time, it might collect statistics on how the code is run and introduce various optimizations to make it run faster. It will also typically do some classical optimizations on its first compilation of any given code block.
It's a JIT because bytecodes aren't compiled until they're about to be run anyway. It's a compiler because it may choose to remember the machine code that results from the bytecode interpretation.

Similar stuff done in JAVA?

[woeuwa]

I've found this thread "by accident" and i didn't know about Jake2, so there may be other Java games or similar apps to show off what's possible and what's not (which i'm very interested in). What i do know is the stuff from Puppygames, Oddlabs and Paradroidz. And now this one. Is that all there is?

Eclipse

[aclarke]

www.eclipse.org

Re:How fair is this Java vs C comparison?

[sbrown123]

Can this really provide fast buffer acess conpaired to C/C++?

Yes

Isn't it going to require bounds checking in the JVM?

No.

Otherwise it would be a security problem wouldn't it?

Yes. So is giving people your credit card number to people you don't know or running with scissors.

and the java is significantly less cache friendly,

That is your earlier assumption which, apprently, you have concluded is a fact. Must have been a real scientific endevour on your part.

Back on mobile phones, I think there are mostly arm processors, and C is actually a pretty portable language.

Oh, geez, mostly? We will ignore the likes of Motorola, MIPS, and Intel to name a few? And theres like, what, only one ARM processor out there with cellpones not including any third party chipsets (ASIC's)? Seems like your steering here. Right now I post from a computer that has the only RISC processor, with the one and only type of memory, running the one and only operating system, by using the one and only web browser.

How is doing java support for different screen sizes, colous, buttons, and memory different to a C API?

What is the name of this C API that goes across multiple chipsets and does these things? I take it it only supports ARM processors right (the one and only)? Might as well make use of your platform here and tell the world of this C API. I sure would like to check it out.

We called it write once run away code.

Thats a really bad joke. Does that actually get laughs where you come from?

Re:How fair is this Java vs C comparison?

[sbrown123]

So, you believe there is an interface in java where I can write quickly and read quickly to memory, with out needing any bounds checking to see if you are righting out side of it? Wouldn't this mean It isn't that hard to right a java app that can take control of somebodies computer because there is no security?

Hmmm. Okay, you are probably thinking unsigned Java applets. Those types of applications run in what is often called a "security sandbox" which limits their capabilities. While in these, Java is unable to use NIO APIs. But, as a standalone or signed (and accepted by end-user) applet Java can use these APIs and thus get full powered input/output control.

"C is actually a pretty portable language".

True. And C++ is pretty standard too. Its only when you use APIs like ATL or DirectX that you get into trouble with cross platform capabilities. Ofcourse, unlike Java, you have to have your code compiled into various binaries. No biggy in the PC world but a real headache with phones because of the variety of chipsets.

If all phones allowed C/C++ apps, I would definatly choose to avoid java for games.

Or, even better, just have a tool that compiles the Java bytecode to a target machine code. This is how they did it with SuperWaba. And there are many advantages for doing this. Another approach is Qualcomm's BREW.

If you say so, some peoples sence of humour may actually differe from you. Some people my clame there is right or wrong when it comes to taste but I dissagree.

Sorry, I was in a pissy mood yesterday.

Tried it...liked it!

[UttBuggly]

I was killing time on an old IBM StinkPad with W2K and a whopping 256MB of RAM. Did the Jake Webstart, downloaded the 38MB Quake files, and I was rocking. It actually plays well. Had one lock-up during the initial session, but none since.