Java - any good for game programming?

[charlie]

There's no denying that Java is memory heavy. If you need absolute efficiency, Java is probably not what you should be using.

[Tuxide]

To the contrary; we all know a hash map is going to take up more memory than a list, yet lookup is faster. I don't think there's a correlation between memory usage and performance, unless your coding style is really bad.

[igouy]

To the contrary; we all know a hash map is going to take up more memory than a list, yet lookup is faster. I don't think there's a correlation between memory usage and performance, unless your coding style is really bad.

You "don't think there's a correlation between memory usage and performance" but you've just given an example of the time-space trade off negative correlation we all know?

[igouy]

It's not a fair way to judge; but for example jEdit tends to use more memory then pretty much every other text editor I've used, and NetBeans tends to use more then Visual Studio.

Until we see the memory usage you measured, and hear how you measured, we shouldn't give much weight to that claim :-)

[StudioFortress]

There can be a correlation between memory and CPU usage. Partly because if you use more lookup tables, and more caches, you can avoid re-calculating values (but only if the calculations are more expensive then the cost of the lookups). But it also works the other way. A few years ago at university I optimized a sliding-block puzzle solving algorithm for finding the quickest route to get from one state to another. In the strategy we had been taught we used a unique list for each possible path, each containing unique objects to represent each state. Switching this to a tree structure, that re-used states, speeded it up from taking almost a minute to just a couple of 100 milliseconds. Object creation and memory allocation isn't free, and high memory usage is a sign that you are performing a lot of this.

The thing to bear in mind with any of these discussions about performance is that if you write a really slow algorithm, then it'll be slow regardless of language. There will be times that a more efficient algorithm, perhaps written in Java, will run rings around your C++ code.

It's not a fair way to judge; but for example jEdit tends to use more memory then pretty much every other text editor I've used, and NetBeans tends to use more then Visual Studio.

Until we see the memory usage you measured, and hear how you measured, we shouldn't give much weight to that claim :-)

I actually mentioned jEdit because I got into an argument with someone about how sluggish it is about a month ago. I ended up installing and then checking how much more memory it used in the Task Manager compared to NotePad++, my current editor of choice. Without any files open it was using about 75mb, where as on the same machine NotePad++ was using less then 7mb for around 9 files (and had been open for several days). Before switching to NotePad++ I used to use jEdit heavily for about 3 years and one of the main reasons I switched was because I started using a low-end laptop with only 1gb of memory. Generally it does tend to eat a lot of ram.

[Tuxide]

You "don't think there's a correlation between memory usage and performance" but you've just given an example of the time-space trade off negative correlation we all know?

I was responding to the argument that more memory usage means your program runs slower. More memory usage can affect performance either way. It could mean you're using a lot of data structures with constant-time lookup, or you have a lot of dependencies, or you're using some in-memory database like Hypersonic, or your code does a lot of memory fragmentation. Or you really suck when it comes to writing code.

[igouy]

There's no denying that Java is memory heavy. If you need absolute efficiency, Java is probably not what you should be using.

I came to this forum to post these corrections http://forum.freegamedev.net/viewtopic.php?f=3&t=1234&start=50#p15227 to comments you'd made. Do you accept those corrections?

[charlie]

Some good games made in Java include Revenge of the Titans, Spiral Knights, Wakfu and Starfarer. I'm pretty sure there's plenty more but they are the ones featured at http://www.java-gaming.org (not all Java games get posted there, especially commercial titles). I think it is safe to say good games can be made in Java.

[MyEmail]

It depends entirely on the goals for the game. Java has made some great advancements in performance and is a very high-level language (so development tends to be faster), but in most cases I would stick to C/C++ (heck, if you can handle it then go with scheme...).

[StudioFortress]

I don't think Java is that high-level. With Haskell, Ruby and others you have plenty of examples where pages of Java code becomes a couple of lines. File IO is one good example. Even C++ has plenty of features which allow you to build more sophisticated and expressive abstractions then you can do in Java. Java is also often cited because of it's amazing verbosity.

As someone who has written a lot of Ruby, JavaScript and Java; I would say that with all things being equal, Java is the least productive. But things are not equal. Over the last 5 years I've learnt and used about 10 to 20 languages (including 2 I wrote myself), on and off. But over 70% of all of the code I have ever written, is in Java. As a result I am far more confident with Java, and so it's my most productive language, simply because I know it inside out.

What I am saying is that expressiveness is great, but confidence is really what gives you productivity.

[Tuxide]

I don't think Java is that high-level. With Haskell, Ruby and others you have plenty of examples where pages of Java code becomes a couple of lines. File IO is one good example. Even C++ has plenty of features which allow you to build more sophisticated and expressive abstractions then you can do in Java. Java is also often cited because of it's amazing verbosity.

As someone who has written a lot of Ruby, JavaScript and Java; I would say that with all things being equal, Java is the least productive. But things are not equal. Over the last 5 years I've learnt and used about 10 to 20 languages (including 2 I wrote myself), on and off. But over 70% of all of the code I have ever written, is in Java. As a result I am far more confident with Java, and so it's my most productive language, simply because I know it inside out.

What I am saying is that expressiveness is great, but confidence is really what gives you productivity.

I don't know why people consider language syntax as a valid argument when comparing programming languages, because in the end how your code actually runs is more important. Yes, you can probably write your program in some language like Python and end up with a considerably smaller source size than if you did it in Java, but when is type checking done?

In Java, the norm is to make the compiler do as much of the work as possible so the work doesn't have to be done when you actually run your program, and that contributes to the verbosity of the language. This is why Java is a static-typed language and has generics (and why some people complain they're broken), because these are compiler features.

In comparison, JavaScript is designed for web use. Downloading and parsing a <script> resource is generally a blocking operation, and the bigger the resource file is, the longer this takes. This is why JavaScript is a dynamic-typed language and is more compact.

[StudioFortress]

In Java, the norm is to make the compiler do as much of the work as possible so the work doesn't have to be done when you actually run your program, and that contributes to the verbosity of the language. This is why Java is a static-typed language and has generics (and why some people complain they're broken), because these are compiler features.

I personally think it's a bit lazy that static languages, like Java, force the developer to state the type in all places. For example Haskell is statically typed, but you don't specify types anywhere. The compiler works it all out for you using type inference. C# and C++ are also moving that way (a little), as they now allow you to infer types. Why should I have to write 'int' for 'int x = 5' ?

But in regards to the compiler, the standard Sun/Oracle compiler for Java actually does as little work as possible. Obviously it does static analysis, but essentially the compiler does a straight translation to bytecode, as quickly as possible. That is why it runs so fast, and the reason why is because you don't know what you are compiling for. It is the JVM which does all the work on optimizing.

[Tuxide]

I personally think it's a bit lazy that static languages, like Java, force the developer to state the type in all places. For example Haskell is statically typed, but you don't specify types anywhere. The compiler works it all out for you using type inference. C# and C++ are also moving that way (a little), as they now allow you to infer types. Why should I have to write 'int' for 'int x = 5' ?

But in regards to the compiler, the standard Sun/Oracle compiler for Java actually does as little work as possible. Obviously it does static analysis, but essentially the compiler does a straight translation to bytecode, as quickly as possible. That is why it runs so fast, and the reason why is because you don't know what you are compiling for. It is the JVM which does all the work on optimizing.

My argument had nothing to do with optimization, but on how verbosity affects what the compiler does compared to other languages. I don't know a whole lot about Haskell, but in other functional languages I've used you still have to do something like specify types in function signatures. Still, functional languages are only good for some specific applications. Suggesting Haskell for game programming is like suggesting XSLT 2.0 for game programming.

Inferring types might not be a bad idea, but still it is trivial because being able to do so in your code won't make your program run any faster or anything.

[FreakNigh]

Why should I have to write 'int' for 'int x = 5'

The amount of memory that'll be used is different. The size of the number that can be stored in the variable will change. C / C++ has it's place in the embedded environment as well. C / C++ is for when your programming very close to the machine level so it's never going to make itself more like php or javascript or something. C# and C++ should not be grouped together.

Personally from I can tell these days you need to be looking for a programming solution that gets you on any many platforms as possible, particularly mobile platforms. C++, Java, and C# with unity can get you on quite a lot of platforms... The future of gaming might be majorly mobile so if your ignoring that at this point you might be just pissing away lifetime.

[MyEmail]

I don't think Java is that high-level.

Consider this--in C++ it takes well over 2000 lines of code to write a basic RSA implementation. If you want it to be fast on multiple platforms and be secure enough to fit industry standards it takes much more than that. And this isn't the "easy" type of code I am talking about--it is hard, brutal (mathematical+logic * 100) kind of hard, the kind of hard developers spend years working on to get it right.

In Java you can do this in about 20 lines of code and 5 minutes of development time. Is Java a high-level language? Definitely.

{l Code}: {l Select All Code}

import java.math.BigInteger;
import java.security.SecureRandom;

class Rsa {
  private BigInteger n, d, e;

  public Rsa(int bitlen) {
    SecureRandom r = new SecureRandom();
    BigInteger p = new BigInteger(bitlen / 2, 100, r);
    BigInteger q = new BigInteger(bitlen / 2, 100, r);
    n = p.multiply(q);
    BigInteger m = (p.subtract(BigInteger.ONE)).multiply(q.subtract(BigInteger.ONE));
    e = new BigInteger("3");
    while(m.gcd(e).intValue() > 1) e = e.add(new BigInteger("2"));
    d = e.modInverse(m);
  }
  public BigInteger encrypt(BigInteger message) {
    return message.modPow(e, n);
  }
  public BigInteger decrypt(BigInteger message) {
    return message.modPow(d, n);
  }
}


[StudioFortress]

Inferring types might not be a bad idea, but still it is trivial because being able to do so in your code won't make your program run any faster or anything.

To clarify, I didn't mention Haskell because it's a functional language, but solely because of it's type inference, as it uses it quite heavily. I agree it won't make any difference to runtime performance, but it wouldn't degrade performance either. The reason why I'd like to see more type inference is because I would expect it would allow me to write type safe code, in less time, whilst being just as readable.

Why should I have to write 'int' for 'int x = 5'

The amount of memory that'll be used is different. The size of the number that can be stored in the variable will change. C / C++ has it's place in the embedded environment as well. C / C++ is for when your programming very close to the machine level so it's never going to make itself more like php or javascript or something.

In both static and type inferred languages, the type would be an int, and the memory usage would be the same. I think you might be confusing 'type inference' with 'dynamic' languages.

C# and C++ should not be grouped together.

My grouping was valid. I said:

C# and C++ are also moving that way (a little), as they now allow you to infer types.

... and you can find examples of this here for C# and here for C++. I don't use C# or C++ very often, but I'm pretty sure I'm right on this one.

Java has also moved this way a little to allow type inference for generic parameters, but I don't see why they couldn't have gone further and added an 'auto' or 'var' keyword like in C++ or C#.

[MyEmail]

Heck, who are we kidding? Real programmers code in scheme.

[Tuxide]

To clarify, I didn't mention Haskell because it's a functional language, but solely because of it's type inference, as it uses it quite heavily. I agree it won't make any difference to runtime performance, but it wouldn't degrade performance either. The reason why I'd like to see more type inference is because I would expect it would allow me to write type safe code, in less time, whilst being just as readable.

My point is that type inference is a staple of functional languages so we would expect Haskell to have it as well. Type inference is obviously going to be heavily used in Haskell because Haskell is a functional language.

Come to think of it, in functional languages variables are typically final, as in you can't reassign values to them. Java, on the other hand, is an imperative language implying some degree of changing program state. It's not clear to me how type inference would work in C# or C++0x, but I'm inclined to think now that in an object-oriented language type-inferred variables would have to be final by default, else there would be side effects. You'd be able to get away with doing stuff like this:

{l Code}: {l Select All Code}

class Person { };

class Adult extends Person {
  public static Adult newInstance() {
    return new Adult();
  }

  public void payTaxes() { }
};

public static void main(String argv[]) {
  p = new Person();            // Type-inferred, compiler says this is a Person, non-final
  p = Adult.newInstance();     // Reassignment
  p.payTaxes();                // Method is not a member of Person
}

Also, I know this is obvious but type inference could end up leading to tightly coupled code if you're not careful on where to use it. What I mean is this:

{l Code}: {l Select All Code}

m = new HashMap();

would mean this

{l Code}: {l Select All Code}

HashMap m = new HashMap();

not

{l Code}: {l Select All Code}

Map m = new HashMap();

It seems type inference in this context is only really useful for primitives. On the other hand, you can do this in Java SE 7:

{l Code}: {l Select All Code}

Map<String, List<Integer>> m = new HashMap<>();

[oberhamsi]

In comparison, JavaScript is designed for web use. Downloading and parsing a <script> resource is generally a blocking operation, and the bigger the resource file is, the longer this takes. This is why JavaScript is a dynamic-typed language and is more compact.

script files are downloaded in parallel but executed in inclusion order. what this has to do with JS being dynamic is beyond me :)

Heck, who are we kidding? Real programmers code in scheme.

Real programmers open the executable in paint and change pixel colors.

[Tuxide]

In comparison, JavaScript is designed for web use. Downloading and parsing a <script> resource is generally a blocking operation, and the bigger the resource file is, the longer this takes. This is why JavaScript is a dynamic-typed language and is more compact.

script files are downloaded in parallel but executed in inclusion order. what this has to do with JS being dynamic is beyond me :)

No it's not, least not the way I understood this. When a web browser processes a page and comes across a <script> element, it blocks processing of all elements coming after the script (including other <script> elements, <img> elements following the script, etc.) until the script is fetched and evaluated. Parsing an HTML document is blocked until this is done, and the way around this is to load the script using a hidden IFRAME.

My point about JavaScript being a dynamic-typed language is obvious: Less verbosity means smaller code download size and faster page evaluation.

[StudioFortress]

Supporting type inference does not require variables to be final. If I was allows to do:

{l Code}: {l Select All Code}

public List<Foo> getFoos() {
}

public void example() {
    auto foos = getFoos();
}


... the compiler already knows the return type of 'getFoos' when it compiles, so it's just a case of replacing 'auto' with this type. There is no requirement for foos to be final.

If I later did:

{l Code}: {l Select All Code}

public List<Foo> getFoos() {
}

public void example() {
    auto foos = getFoos();
    foos = 5;
}


... the compiler can also work out that this is illegal, since 'foos' would be the type of 'getFoos', which is 'List<Foo>'.

Also, I know this is obvious but type inference could end up leading to tightly coupled code if you're not careful on where to use it. What I mean is this:

I don't fully agree. Yes when compiled, it would end up being the most explicit type possible. But writing 'auto' (or something else to denote type inference) would be more generic then writing 'Map'. For example lets say it changed from:

{l Code}: {l Select All Code}

Map x = new HashMap()


... to ...

{l Code}: {l Select All Code}

Map x = new ArrayList()


... your code is now broken. You would need to update the type of x from 'Map' to 'List' or 'ArrayList', in order to keep the code valid. If the type of x was automatic, using type inference, then the compiler would make this switch for you.

In real Java code, I have some very long types. Such as:

{l Code}: {l Select All Code}

ArrayList<Resizable2DArray<CachingHashSet<A>>> classPointsList = grid.getSubKeys( collisionClass );


With type inference it would be half the length, just:

{l Code}: {l Select All Code}

auto classPointsList = grid.getSubKeys( collisionClass );


I think it's mainly local variables where type inference comes into it's own. However you can also end up with some very funny error messages, and code which is difficult to fully comprehend. For example:

{l Code}: {l Select All Code}

public auto bar( auto a, auto b ) {
    return a + b ;
}


Because primitive types and Objects are entirely separate, the compiler might have to generate versions for every possible combination; i.e. int + int, int + byte, int, int + double, double + long, byte + short, String + Object, Object + String,.. etc.

[oberhamsi]

In comparison, JavaScript is designed for web use. Downloading and parsing a <script> resource is generally a blocking operation, and the bigger the resource file is, the longer this takes. This is why JavaScript is a dynamic-typed language and is more compact.

script files are downloaded in parallel but executed in inclusion order. what this has to do with JS being dynamic is beyond me :)

No it's not, least not the way I understood this. When a web browser processes a page and comes across a <script> element, it blocks processing of all elements coming after the script (including other <script> elements, <img> elements following the script, etc.) until the script is fetched and evaluated.

Used to be true, but see third column here (hover text reads ""This test determines if the browser downloads scripts in parallel with other scripts in the page."):

http://www.browserscope.org/?category=network

I was motivated enough to produce a picture to prove my point for chrome :)

[StudioFortress]

At a guess, I'd say that modern browsers look ahead in the HTML to find items to download in advance. It is the only way to explain the fact that browsers do download scripts in parallel, and do execute them in sequence.

[Tuxide]

Used to be true, but see third column here (hover text reads ""This test determines if the browser downloads scripts in parallel with other scripts in the page."):

http://www.browserscope.org/?category=network

I was motivated enough to produce a picture to prove my point for chrome :)

downloadinparallel.png

Thanks for being motivated, and for taking the time to shift the burden of proof off yourself. The wordage is the following:

When some browsers start downloading an external script, they wait until the script is done downloading, parsed, and executed before starting any other downloads. Although parsing and executing scripts in order is important for maintaining code dependencies, it's possible to safely download scripts in parallel with other resources in the page (including other scripts). This test determines if the browser downloads scripts in parallel with other scripts in the page.

I'll secede that cutting-edge browsers may or may not do this (it seems the browser still makes the final call here); however legacy browsers that are still being widely used do. That is, IE6 and 7, Gecko 1.8 browsers, and all desktop versions of Opera. That might not be relevant or significant to the developer unless you're either using Java for GWT since that's half the build targets in GWT alone, or you're targeting people who live in China.

Either way, whether or not this is a blocking operation in your browser, my point about JavaScript being dynamic typed and how this contributes to source file size remains valid.

Supporting type inference...

After reading a variety of other discussions on the subject, I came to the conclusion that having a strong type inference engine in an imperative programming language is a) possible and b) subject to constraints that Java would normally let you get away with. These are mainly obscure cases that the compiler already throws exceptions against (but still compiles), but also in Java reflection and thus some dependency injection frameworks as well. For example, with the following:

{l Code}: {l Select All Code}

foo = Class.forName("java.lang.String").newInstance();

This returns an Object that has to be manually cast to String in order to be used. Same with BeanFactory.getBean() in Spring Framework.

I do not, however, agree with your reason for wanting a type inference engine in the first place. You don't just want a stronger type inferencer because you don't want to write things like

{l Code}: {l Select All Code}

Map<Service, ServiceImpl> daos = new HashMap<Service, ServiceImpl>();

It's rather you don't want to read it either and you don't want to deal with it when you maintain and refactor your code. Other than that, this wouldn't affect how your code actually runs, but in the end that's no different than saying Java generics don't affect how your code actually runs. I suppose you could argue that adding a stronger type inference engine would be adding an extra level of type checking to your code, because if the type inferencer can't infer the same type that you explicity set then something's wrong. Enforcing this can break backwards-compatibility though, so this would more justify it being an IDE feature, or a feature of another language built on top of Java, than a feature of the Java compiler itself.

If you absolutely need Haskell-like local type inferencing in a static-typed imperative language for game development, and your target is the JVM, then I suppose there is Scala.

I don't fully agree. Yes when compiled, it would end up being the most explicit type possible. But writing 'auto' (or something else to denote type inference) would be more generic then writing 'Map'. For example lets say it changed from:

{l Code}: {l Select All Code}

Map x = new HashMap()


... to ...

{l Code}: {l Select All Code}

Map x = new ArrayList()


... your code is now broken. You would need to update the type of x from 'Map' to 'List' or 'ArrayList', in order to keep the code valid. If the type of x was automatic, using type inference, then the compiler would make this switch for you.

I don't think this is how the Java compiler works, this isn't C++. Classes in Java get compiled only once, unlike things in C++ like templates. That is how they chose to implement generics.

[mdwh]

I don't think Java is that high-level.

Consider this--in C++ it takes well over 2000 lines of code to write a basic RSA implementation. If you want it to be fast on multiple platforms and be secure enough to fit industry standards it takes much more than that. And this isn't the "easy" type of code I am talking about--it is hard, brutal (mathematical+logic * 100) kind of hard, the kind of hard developers spend years working on to get it right.

In Java you can do this in about 20 lines of code and 5 minutes of development time. Is Java a high-level language?

But that's nothing to do with the languages, it's comparing Java with its built in library, to raw C++ and trying to implement it yourself. Yes, one advantage is with Java the built in library - though you're also stuffed if you don't like what's there (I couldn't stand the UI toolkit, full of terrible bugs - maybe they've improved it in recent years, but that's not the point - the point was I couldn't just switch to another toolkit that worked).

Microsoft offer support for BigIntegers on Windows. There are other libraries available ( http://www.win.tue.nl/~klenstra/ , https://mattmccutchen.net/bigint/ , http://gmplib.org/ ).


Definitely.

{l Code}: {l Select All Code}

import java.math.BigInteger;
import java.security.SecureRandom;

class Rsa {
  private BigInteger n, d, e;

  public Rsa(int bitlen) {
    SecureRandom r = new SecureRandom();
    BigInteger p = new BigInteger(bitlen / 2, 100, r);
    BigInteger q = new BigInteger(bitlen / 2, 100, r);
    n = p.multiply(q);
    BigInteger m = (p.subtract(BigInteger.ONE)).multiply(q.subtract(BigInteger.ONE));
    e = new BigInteger("3");
    while(m.gcd(e).intValue() > 1) e = e.add(new BigInteger("2"));
    d = e.modInverse(m);
  }
  public BigInteger encrypt(BigInteger message) {
    return message.modPow(e, n);
  }
  public BigInteger decrypt(BigInteger message) {
    return message.modPow(d, n);
  }
}


[/quote]