Java - any good for game programming?

[StudioFortress]

I meant if the developer changed the code from 'HashMap' to 'ArrayList', they would have to update this in (at least) two places, rather then just one.

Backwards compatibility seems to be the main focus for most new Java features, which is a big strength, especially given it's high-use in Enterprise environments (where they have tonnes of Java code). But for local variables, I don't see why this couldn't be added, without remaining backwards compatible. Again, it's just allowing you to make your code a bit more terse and easier to refactor.

[Tuxide]

...for local variables, I don't see why this couldn't be added, without remaining backwards compatible. Again, it's just allowing you to make your code a bit more terse and easier to refactor.

I was trying to find an answer to this I only found two reasons; one of them I wasn't satisfied with because the answer was incomplete. The first answer is that it's not as simple as adding new tokens and semantics, but also adding new restrictions to the type checker that would end up breaking legacy code. I wasn't satisfied with this answer because I didn't see enough good examples supporting it. This also might have to do with why they chose to pursue type inferencing on the right-hand sign of statements (with the diamond <> operator) instead of the left-hand sign, like they do now in C#. The second answer I found is that they recommend the type checker be heuristic-based so that it runs faster. That makes sense if you're making your own language targeting the JVM like Scala or Groovy or AspectJ or Velocity, since you probably need to write a type checker for it anyways and you can make it as advanced as you want to.

I meant if the developer changed the code from 'HashMap' to 'ArrayList', they would have to update this in (at least) two places, rather then just one.

I don't even know what you mean by this example because HashMap and ArrayList don't share a common interface in java.util.*; ArrayList is not even a type of Map. It's not like you can treat a Map as a List in the rest of your code anyways because they don't even share a common interface in any package, so if that's what your goal was and if this was possible, then you wouldn't be able to call any methods from your variable in the first place.

If you're looking to, say, replace HashMap with something else that implements Map such as TreeMap, then that's what dependency injection techniques like factory method pattern and frameworks are for. Hardcoding your dependencies into your classes using the new keyword (static binding) is generally considered to be a bad thing anyways, and the way around it is to use dependency injection. Binding dependencies is then done during run-time (dynamic binding), unless you're using GWT which does this during compile time (deferred binding).

[StudioFortress]

My point was that you were changing to a completely different data structure. If it was HashMap to TreeMap, then you can mitigate this by having x to be of type 'Map'. But if you just used an imaginary auto instead, then that is one less item to alter (although obviously other parts of your code would need altering too).

[Tuxide]

I just came up with an example of how an auto keyword wouldn't work in Java that actually satisfies me. Consider the following:

{l Code}: {l Select All Code}

final auto foo;                         // type-inferred
if (condition == true) {
  foo = new HashMap<String, Integer>();
} else {
  foo = new ArrayList<Float>();
}

In this example, foo can either be a HashMap or an ArrayList; the final keyword doesn't actually do anything to help enforce type. If you replace auto with Object, the code is legal in Java. I throw the final keyword in here to show that the code would still be legal even if you finalize it. The problem that this example brings out is that the type of foo can be more than one thing... HashMap and ArrayList share three common types that have nothing to do with each other: Object (class), Serializable, and Cloneable (interfaces). In fact, replacing auto with either Object, Serializable, or Cloneable would still make the code legal in Java.

The problem is this now creates an ambiguity in the type checker. If you're creating your own well-formed language, this clearly is something you want to avoid, and catching all cases like this one is important. Because of this, you wouldn't be able to use an auto keyword to do stuff like reduce boilerplate code in something like factory method pattern.

[MyEmail]

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).

Umm, sure it does. Regardless of whether it is "Java" or "Java's toolkit" that is high-level--its still high-level.

But who cares anyway--Scheme owns Java hands-down so why argue? In fact, Scheme owns everything .

[Zlodo]

I just came up with an example of how an auto keyword wouldn't work in Java that actually satisfies me. Consider the following:

{l Code}: {l Select All Code}

final auto foo;                         // type-inferred
if (condition == true) {
  foo = new HashMap<String, Integer>();
} else {
  foo = new ArrayList<Float>();
}

I agree that this wouldn't work, but the auto keyword in C++0x (or var in c#) don't work that way either, they infer the type from the initializer. So you can't write auto foo; because the compiler can't figure what type it should be. What you can write is auto foo = something;