The memory footprint isn't anywhere near as bad as you might think. The actual in-use heap memory footprint of my games - or let's say Revenge of the Titans specifically - is actually not vastly different from the equivalent that it might have been in C++. What might be fooling people into perceiving Java as a memory hog are the following:

a) jar files mapped into process space (in reality, only a tiny portion of most of the jars is actually being used)b) graphics and sound effects kept in system RAM are huge - easily half of the memory footprintc) the heap hasn't exactly been super-tuned for efficiency; depending on how much time you've got to spare with GC you can shrink the maximum heap size massivelyd) "bad" programming: GC tends to promote a lazy approach to conserving memory. I discovered a while back that the Strings in my configuration data were being kept after startup completely unneccessarily and wasting 50mb of heap - I now null them after startup.e) overlarge vertex buffers

I think Java's memory usage isn't really massively greater than C++ for a non-trivial game but in these days of cheap RAM, we don't tend to spend so much time ensuring that things fit in a tiny footprint anyway.

I suggest we leave it at that, as nobody wants a flamewar in this otherwise informative thread.

Quite! Though it's always amusing to be flamed for saying something you've never said* I have never claimed that JNA is faster than JNI - how could it be, it's built on top of it. I assume that the changes mooted for JDK 9 will also use a mechanism like libffi, and therefore probably be slower too. To which I say ... so what?

My point about JNA has always been my point for using Java itself. Performance isn't everything! Ease of development, deployment, robustness, etc. all come into it too. JNA and Java itself are usually fast enough - otherwise we'd be having this conversation on assembly-gaming.org.

I think Java is great for game server development. This is a sector with a huge amount of support.For the client/singleplayer side Java could be great, but there is a lack of support. Afaik Android games are not that profitable compared to iOS. So many people will look for iOS to Android converters and not the other way arround... Java became too complex before lightweight use of such languages/systems was chic.

I often think about converting Java bytecode to AVM2 bytecode. I think it would be great to be able to use Java and its tools for programming Flash. It may even improve the performance of Flash.

The last time I had to do a GUI in C++, I wrote an OpenGL library that basically mimicked Swing )

Actually there was a time where many people were working on GUI libraries built on top of OpenGL for game purposes... Some of them looked really neat too. I wonder if at least one of them survived and actually became something more than a post on a forum.

My point about JNA has always been my point for using Java itself. Performance isn't everything! Ease of development, deployment, robustness, etc. all come into it too. JNA and Java itself are usually fast enough - otherwise we'd be having this conversation on assembly-gaming.org.

Couple that with the fact that we're currently missing structures, arrays of structures and concrete length arrays...all this nickel-and-diming everywhere adds up fast. (Note this is the source of my whining about per-object locks and identityHash)

Quite large on a micro level but in the grand scheme of things object overhead is irrelevant next to the memory consumed by graphics. A triple A title can have half a gig of RAM just used by textures to render a single frame.

I do agree you can let it get out of hand quickly if you're not doing flyweight pattern or mapped objects to simulate structs but that's only for very particular kinds of data in very particular situations. Nearly all the rest of the time I've noticed that the memory is actually being used by one of the places I outlined above - that is, wasted unnecessarily, in graphics/sound, in unused heap, and mapped jar files. Android gives a very slightly more simple picture of what an app might use as it's nowhere near as sophisticated in its use of mapped files and the resource constraints make it manage memory in a slightly more understandable way.

Also that's not at all the only overhead in a C++ allocation, especially if you're mallocing it; both Java and C++ require memory management structures for keeping track of allocations on the heap, and there's a similar bunch of bookkeeping structures used in both. The main difference is C++ can be forced to use the stack instead whereas Java has only recently started using escape analysis to do it automatically when prudent.

Yes it is important to remember here is that most of us don't really care about any of this. Chances are if you're hitting performance problems that need addressing the issues are going to be more design and algorithm related than Java's weak points.

WRT: moving graphics..different hardware is doing the work so this has (or should have) little impact on the work that the CPU can do.WRT: moving computations to the GPU. This is overrated. You still want to get maximum computation from your CPUs as well as GPUs in bleeding edge work. Everything you move off to a GPU consumes time that it could be doing something else...like rendering (just a for instance).

This whole Java development page is rather interesting since I used to be a C++ programmer before converting to Java. Java does not suck as a language, the amount of tests and routines I tried on it allows it to be a very good platform for game development. It is very well documented, allows you to deliver games solidly cross-platform, and is easier to use than C++. But, despite this, Java just has a lot of stuff working against it.

1) Most of the world PC's use Windows.

This is really hurtful because Microsoft basically controls the gaming market for PC's. C++ is the language of choice and if you are going to affect 70% of the users, who cares about the 30% who get left behind. This mental picture was painted into a lot of my professors and colleagues minds. Support is just better for gaming in Windows and C++.

2) You must do it Java's way...

This is major. You can't avoid the JVM, you can't avoid naming classes with filenames, you can't avoid the GC. Yes, there are ways to improve the performance of Java, but in the end, you end up doing about the same amount of work to cut off time, as you would to build the program from scratch in C++. Indie gamers will flock to it because the concept is easier to grasp than C++. Indie gamers love easy to learn concepts. But, to get the true speed out of Java, you really have to put in the extra effort required for C++/C. I specifically found it rather difficult to argue which language was superior.

3) Popups

The one complaint I got from users the most was "Why the pop-up?" People just want fast deployment. Indie gamers usually never take the route of packaging the JVM, making things a lot worse since every time, you'll eat the pop-up. In reality, the "Java is slow" mantra has spread more than just comparing it to C++.

The users are basing it on how long it takes for when you click the application, to when you actually get to run it.

So, if the deployment time is stopped by a loading screen, a certificate pop-up, and a request to download the latest JVM. It doesn't feel as intuitive as just click .exe program and run. Java might be a lot faster in processing speed, but deployment still seems to be tearing Java's sails. Users immediately think pop-up = bad! (thanks a lot spam) so it works against Java.

I continue to use Java because it has a user community that actually cares about the language. Also, you are never short of documentation on how to get something operating. Its connection to Android is really a deal maker, and I think Java should push itself more into gaming platforms (like Playstation & Wii) and phones (iOS) if possible. I hate the fact that people think of Java as niche software for making quick simple applications. Java deserves more than that. It is a very capable language now, and I think if we don't give up on it, it has great potential to be the next C++.

1) About 10%-11% of gamers on the other hand use Macs, and honestly, the users of Windows or Macs don't care a hoot what language you wrote a game in so long as it works with a minimum of fuss (see 3 below). Some vanishingly small % of ordinary people use Linux, though through random chance it turns out about 10% of our customers use Linux for some inexplicable reason.

2) Java's way is absolutely fine 99.99% of the time. It is "normal" for C++ programmers to be upset by this and try to fight the GC, established naming conventions, general design patterns, etc. Eventually the whole concept is grokked and you end up spotting the real issues, which is where you start finding all these discussions here on JGO about mapped objects. Sometimes there's concern over performance - it being about half the speed of C++ in general - but as nobody here on JGO is actually pushing current hardware anywhere near its limits this rarely concerns us much and usually it turns out that it's actually algorithmic design or GPU limited code that is the problem, just as in C++.

3) Nobody who seriously develops Java games (unfortunately the number of studios who actually do can be enumerated on one hand or thereabouts) actually uses a system JVM on Windows, or actually uses applets. Except for Mojang, and they've had all kinds of trouble from it, but that's because Markus started from scratch with no real knowledge or care of the issues around it all and had no idea Minecraft was going to be quite so successful.

Android's great ... for mobile Java development. I don't think its existence is going to have any useful effect on the perception of Java desktop applications.

This whole Java development page is rather interesting since I used to be a C++ programmer before converting to Java. Java does not suck as a language, the amount of tests and routines I tried on it allows it to be a very good platform for game development. It is very well documented, allows you to deliver games solidly cross-platform, and is easier to use than C++. But, despite this, Java just has a lot of stuff working against it.

1) Most of the world PC's use Windows.

This is really hurtful because Microsoft basically controls the gaming market for PC's. C++ is the language of choice and if you are going to affect 70% of the users, who cares about the 30% who get left behind. This mental picture was painted into a lot of my professors and colleagues minds. Support is just better for gaming in Windows and C++.

If you are making a premium title game, yeah. Otherwise I would be careful.Macs and Linux have a nice base and are interesting markets.

Quote

2) You must do it Java's way...

This is major. You can't avoid the JVM, you can't avoid naming classes with filenames, you can't avoid the GC. Yes, there are ways to improve the performance of Java, but in the end, you end up doing about the same amount of work to cut off time, as you would to build the program from scratch in C++. Indie gamers will flock to it because the concept is easier to grasp than C++. Indie gamers love easy to learn concepts. But, to get the true speed out of Java, you really have to put in the extra effort required for C++/C. I specifically found it rather difficult to argue which language was superior.

Your last line really is the most crucial point. Far to many people do not have the basis to make such a comparison.

Also the bias and habits get in the way.

Quote

3) Popups

The one complaint I got from users the most was "Why the pop-up?" People just want fast deployment. Indie gamers usually never take the route of packaging the JVM, making things a lot worse since every time, you'll eat the pop-up. In reality, the "Java is slow" mantra has spread more than just comparing it to C++.

The users are basing it on how long it takes for when you click the application, to when you actually get to run it.

So, if the deployment time is stopped by a loading screen, a certificate pop-up, and a request to download the latest JVM. It doesn't feel as intuitive as just click .exe program and run. Java might be a lot faster in processing speed, but deployment still seems to be tearing Java's sails. Users immediately think pop-up = bad! (thanks a lot spam) so it works against Java.

If your game has a certain size, you could also simply package the jre with the game.

Note that in C++ you could have similar problems. Do you have the runtimes needed? The right gfx drivers? DirectX?People have no problems doing all this for C++ game, but if they have to do it for Java it is totally unusable all of a sudden?

Quote

I continue to use Java because it has a user community that actually cares about the language. Also, you are never short of documentation on how to get something operating. Its connection to Android is really a deal maker, and I think Java should push itself more into gaming platforms (like Playstation & Wii) and phones (iOS) if possible. I hate the fact that people think of Java as niche software for making quick simple applications. Java deserves more than that. It is a very capable language now, and I think if we don't give up on it, it has great potential to be the next C++.

While I no longer really do any game dev, I still use Java for basically everything simply because it can work everywhere and do nearly anything I need.

Note that in C++ you could have similar problems. Do you have the runtimes needed? The right gfx drivers? DirectX?People have no problems doing all this for C++ game, but if they have to do it for Java it is totally unusable all of a sudden?

Very true, but with one difference: most if not all of that stuff is dealt with through windows updates or even platforms such as Steam - you hardly ever have to think about it anymore as the end-user. Java on the other hand is managed separately and in a far more intrusive way. On top of that, Windows update hardly ever fails (Microsoft is not flawless of course) - the people at Oracle aren't too good at creating reliable installers that work on all machines and under user configurations reliably, the Oracle forums tend to see a major increase in people having botched installations which are near impossible to repair each time a new update is released...

Note that in C++ you could have similar problems. Do you have the runtimes needed? The right gfx drivers? DirectX?People have no problems doing all this for C++ game, but if they have to do it for Java it is totally unusable all of a sudden?

Very true, but with one difference: most if not all of that stuff is dealt with through windows updates or even platforms such as Steam - you hardly ever have to think about it anymore as the end-user. Java on the other hand is managed separately and in a far more intrusive way. On top of that, Windows update hardly ever fails (Microsoft is not flawless of course) - the people at Oracle aren't too good at creating reliable installers that work on all machines and under user configurations reliably, the Oracle forums tend to see a major increase in people having botched installations which are near impossible to repair each time a new update is released...

The appeal of Java is that it is well designed "little" language. And the "little" part isn't meant to be derogatory. The syntax, on the whole, is nice and clean. It's a very good first language as it doesn't have a large learning curve to get up and going. The set of tools & libraries that are freely available are excellent (OK, on the library side there are some big gaps...numeric stuff comes to mind..but most of us don't really care about that). On the performance side, it's quite excellent when compared to dynamically typed languages and is more than sufficient for vast majority of gaming needs as long as your not attempting to compete at the top-end of the spectrum. And if you are, then the fact that it's unlikely that you have tens of millions in budget is probably a much bigger hurdle than any performance issues. (Of course all generalizations will have exceptions)

So, to my mind questions like: "Why isn't Java more successful for games?" or "Why don't big studios use it?" are not very interesting. Question like how to improve user experience (such as deployment) and how to handle current limitations are much more interesting.

Coming back the the performance (and usability) side, what bothers me is that most of the big issues (again for me) are fixable with current technology.

Some vanishingly small % of ordinary people use Linux, though through random chance it turns out about 10% of our customers use Linux ... Nobody cares about Linux.

Er, if it was 10% of my customer base, I'd be caring about it! Do I think that 10% is reflective of the overall Linux user base, no, but nor do I think it's vanishingly small either. Interesting reading things like http://broadcast.oreilly.com/2010/09/debunking-the-1-myth.html, or the stats on http://www.humblebundle.com/ which show Linux share about equal with Mac and less cheapskate too! Your 10% may reflect a more tech-savvy audience for indie games, who knows, but it just might show it's worth caring about.

How can you criticise this??? One of Java's best features IMO, and one reiterated every time I try and grok some code in another language and have to spend time wondering where the f**k someone has hidden something.

It's a very good first language as it doesn't have a large learning curve to get up and going.

Object Oriented programming isn't exactly easy to pick up ya know Its easy to pick up when you already have programming experience; when you're new to the scene I'd hesitate to say that a language like Java can actually be a hurdle. Better start out with something flat and sequential. Like our beloved Pascal, but I'd settle for something like Ruby as well

Quote

The set of tools & libraries that are freely available are excellent

Agreed, but there is still a major problem that stumps people - there is no "java executable" to start. The tools are great, but they are fragmented.

Quote

(OK, on the library side there are some big gaps...numeric stuff comes to mind..but most of us don't really care about that).

Us experienced folk don't, no. But again: major fragmentation and even conflicts; in my opinion the "api/implementation" idea that Sun basically forced on the language created far too much confusion. You keep the platform open, but also create lots of confusions because there are multiple implementations floating around for each API. In some cases Sun/Oracle even neglects to provide or update the reference implementation :/

Quote

So, to my mind questions like: "Why isn't Java more successful for games?" or "Why don't big studios use it?" are not very interesting. Question like how to improve user experience (such as deployment) and how to handle current limitations are much more interesting.

Agreed. It doesn't help to keep tripping over what doesn't work, better to focus on fixin' it. Java has always been community driven to begin with, waiting for Oracle to step up simply isn't productive.

Quote

Coming back the the performance (and usability) side, what bothers me is that most of the big issues (again for me) are fixable with current technology.

What bothers me the most is that the knowledge is in your head and not somewhere where I may benefit from it

The only reason we have that many Linux customers is because of the Humble Indie Bundle. Linux also accounted for 90% of our support costs as well - problems generally being more common, and more difficult to diagnose and fix. Almost no support whatsoever for Mac OS - it's a model citizen with Java and OpenGL, at least how I use it anyway. Windows somewhere in the middle.

If you're not in a Humble Indie Bundle you are basically wasting your time supporting Linux. That hasn't stopped us supporting Linux for the last 10 years of course, but you should know it's basically a time sink you do in your spare time for the love of it.

The only reason we have that many Linux customers is because of the Humble Indie Bundle. Linux also accounted for 90% of our support costs as well - problems generally being more common, and more difficult to diagnose and fix. Almost no support whatsoever for Mac OS - it's a model citizen with Java and OpenGL, at least how I use it anyway. Windows somewhere in the middle.

If you're not in a Humble Indie Bundle you are basically wasting your time supporting Linux. That hasn't stopped us supporting Linux for the last 10 years of course, but you should know it's basically a time sink you do in your spare time for the love of it.

I guess I develop a Linux version that specifically says, when buying, that due to technical complications it is not supported. However offering a linux support email address for obvious problems, if such things exist on linux.Since Linux users usually have a hard time getting anything to run, one would think they could fiddle around for themselves.But good to hear that porting to Mac is so simple, App Maker thing, no problems, no support needed... Sounds good.

WRT: OO not being the easiest. Yeah, Pascal is a fantastic learning language. But given the feature set of Eclipse (and I assume NetBeans), specifically things like easy project creation, auto-magic display of documentation and quick feedback of syntax problems...I'd lean towards thinking learning to program would be easier in Java. The "design" might be ugly for awhile, but so what.

WRT: Performance and usability. I skipped on that cause I figured it has been covered ad nauseam. Short list off the top of my head:

structures Kill pointer bloat. Makes small composition reasonable. Possible to have linear access to memory. Possible to add SIMD operations and caching hints. This is a really really big one.

Versioned language. Kill off some of the bad ideas. Type erasure, per object locks and identity hash come to mind. Covariant overrides: feature or bug?

Sealable packages.Allows much more aggressive optimization.

Caching of compilation aux dataOne big problem with Java vs. C++ is that AOT compilers have all the code that will run upfront and can spend a fair amount of time "thinking". Java's a dynamic language and can only spend small time slices. So rather than perform redundant work every time some set of code is run, cache out known features for a given set of code and use that as a starting point. Spend them slices on something new, dang it!

Change transport IR from Forth to some high level IR.(And yeah, you can half-assed create a high level IR from the current, but it's not ideal) Makes high level optimizations very easy. Another biggy here is Hygienic macros (or templates that don't suck) would be very easy and expand at runtime. Rewriting the same code over and over for various types is sucky. Verifier becomes easy. The size of the classfile would be reduced. It would make the JVM much easier to target for "other languages". There's no downside here kids! (other than that evil change thing)

Notice that a lot of these kinda tie together. I'm sure that there's lots of other things, but I'm running out of steam.

Anyone know what the state of Maxine/Graal is? Or how Shark is doing? I know that Shark is in the JDK8 hotspot codebase (edit: I incorrectly had JDK9 here.) but haven't bothered to check if it's actually in use.

WRT: Coolest language ever - SmallTalk for the thousandth time you heathen!

WRT: OO not being the easiest. Yeah, Pascal is a fantastic learning language. But given the feature set of Eclipse (and I assume NetBeans), specifically things like easy project creation, auto-magic display of documentation and quick feedback of syntax problems...I'd lean towards thinking learning to program would be easier in Java. The "design" might be ugly for awhile, but so what.

Covariant return value overrides are absolutely a good feature. The popular wisdom is "reads should be covariant, writes should be contravariant, read/write should be invariant" and there's more formal ways of putting it with the LSP. A covariant return value from a subclass should be sound by that reasoning.

Now covariant arrays on the other hand are the worst idea since null.

As for become, check out http://bpaste.net/show/2753/ -- I don't know it'll let you redefine True and False, since those are int subclasses, but everything else, pretty much.

Oh, I forgot a very big one (which ties in, yet again, to the above) concrete and packed arrays.

WRT: Convariant - This is one of the features that bother mean since language nannys deny me operator overloading, which is pretty easy to understand, and convariant overrides will be pretty difficult for most people. And yeah, the Map array thing is really annoying. What do you mean I can do map["Some String"] = 3.5f; And I have to do foo.getSomething()? You kidding me???

Anyway, I don't think that the lack of it is what's kept big studios from embracing Java wholeheartedly...

Cas

Its probably also closer related to the skill pool; there aren't that many good Java game programmers out there to complete a team. C++ is a safe bet and it works for all major gaming platforms too; Java doesn't because of that blasted runtime. You know, the more this thread progresses, the more I start to see why the runtime is what keeps the platform down :s

What would be the smallest size the runtime could be crunched to when only implementing the very basic and gaming related classes?I think for leagal reasons its not allowed.But couldnt the runtime be shrunk to like 4MB when the developer only publishes the basic runtime+linked classes?

That would be some interesting project for the OpenJDK.To have a tool that compiles a customized distributable and small runtime.(With builds for Win,Mac and Linux)

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org