Compared to .NET Java has less predictable performance. For example, I wrote a date chooser and my code used quite a lot of anonymous inner classes. The first time the user used that part of the application there was a noticeable delay due to classloading, that I moved to application startup time just so that the user wouldn't see a delay.
It was actually a pretty small delay, less than a second, but in the context of an app that normally responds instantly it was visibly slow. As I understand it, .NET loads an assembly at a time, not a class at a time. It does generally 'seem' faster regarding GUI operations, which can be more important than actual number-crunching speed. That applies to Mono too. Work with Eclipse for a day then play with MonoDevelop and you'll probably notice a striking difference in responsiveness. I have no idea whether MonoDevelop's responsiveness still applies when you have very large projects open; nothing I've ever done in C# hit the 1000 line barrier. -----Original Message----- From: clay <[email protected]> Sender: [email protected] Date: Wed, 18 Jan 2012 23:02:32 To: The Java Posse<[email protected]> Reply-To: [email protected] Subject: [The Java Posse] Re: Sony's PlayStation Suite for Vita/Android Chooses C#/Mono Exclusively. What's the Alternative? On Jan 18, 9:09 pm, Josh Berry <[email protected]> wrote: > I don't know what to tell you. Game developers by and large avoid > Java. I think if you honestly want a good answer as to why, ask them. Thanks Josh. I think I figured this out. And I think I can articulate this better than most game developers could (I don't think game devs have thought as much about this issue or the JVM as I have): The most important missing feature is having easy to use, embeddable, micro-VMs. Microsoft .NET doesn't have this, but the Mono guys made their own implementation of the CLR with this as a primary concern. There are no legal or technical obstacles stopping this from happening on the JVM side, it's just no one has done it. Game developers want to target iOS, Android, and PlayStations. Those devices do not and will not run traditional system-level Java. Embeddable micro-VMs are the solution and they don't exist yet on the JVM side. I really wish I had gone to grad school for this type of stuff, because I think this is a hot project but it requires a specialized set of skills to do well. The second issue is the programming language. Ideally, you support multiple languages, but you still need a flagship language. Java, the language, is behind the times. C#, the language, has incrementally improved upon Java overall. However, there are other languages that deliver even further incremental improvements. I don't think the game development community is ready for the type theory, the deep abstractions, and the radical nature of Haskell or Clojure. I think the most promising candidate is the forthcoming Kotlin. It definitely one ups Java/C# and doesn't require paradigm shifts and I'm hoping it won't have the compilation speed penalty and runtime speed penalty that Scala seems to have. What else do we want from Java: the super IDEs and the build tools. As I explained earlier, the Java build tools are really at the leading edge of the industry. And almost every dev I know that has used it would pick IntelliJ any day over Visual Studio. But to resummarize an earlier point: I don't think runtime performance is a problem with the JVM. Even without "unsafe" casting and memcpy type tricks and the issues you raised, the JVM generally outperforms both Microsoft's CLR and Mono. The two of you in this thread that insist this is a problem are just not being reasonable. > Also, it isn't like anyone here dismisses the JVM. We just can't > offer any compelling reason why game developers should choose it over > alternatives. I can articulate some compelling reasons: - Kotlin is a better, more exciting, and more elegant language than C#. - Better IDEs and wider selection of IDEs. - Better runtime performance. - Better build tools and a wider choice (Maven, Gradle, SBT). - A deeply meritocratic culture rather than one that is forever in lock step behind a corporate despot. "Can you give an example of such code that would cease to work should Java add unsigned ints?" I can't, but I haven't thought about this issue deeply. You may know this issue better than I. "But yes, at least unsigned integer math is coming in Java 8, afaik." Where did you hear this? Do you have a link? I can't find this on google. FYI, I remember during this last year, famous game programming expert John Carmack posted on his Twitter about some unsigned integer corner case that caused problems and said something to the effect of maybe it wasn't a bad thing for Java to avoid them. I am unable to dig up the exact quote/link at the moment. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
