Sign in to follow this  
Dahamonnah

How powerful is Java?

Recommended Posts

jbadams    25674
[quote name='Dunmord' timestamp='1351968546' post='4996939']
Last time I checked, C++ had much more mature game development tools than Java. You can even compare tools like Java 3D vs the C++ Irrlicht3D engine
[/quote]
That's not a great comparison though, as Java3D and Irrlicht aren't really meant to be equivalent or even particularly similar. I think [url="http://jmonkeyengine.com/"]jMonkeyEngine[/url] is probably a fairer comparison to Irrlicht, and it matches up pretty well. Something like OpenGL (although this is available to Java programmers via [url="http://jogamp.org/jogl/www/"]JOGL[/url] or [url="http://www.lwjgl.org/"]LWJGL[/url]), Direct3d or perhaps at a stretch OGRE might be a fairer comparison to Java 3D.

You're actually right that there's less variety in the tools and libraries available to Java developers, but it's misleading to make an inaccurate comparison between things that were never intended to be equivalent, and although there's a bit less choice there are some good quality and well supported choices available.

[img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]

Share this post


Link to post
Share on other sites
Anri    971
Its surprisingly powerful. True, C++ is great for speed and flexibility, but Java is a good all-rounder. For 2D games, C++ isn't going to provide any more speed than Java, but getting into 3D, you might find C++ a better choice - but even then, it depends on how advanced you want your visuals to be: are you aiming for a Doom 3 level 3D engine or are you thinking of writing a 3D app like Maya or 3dsMax?

From experience, Java is certainly a good choice. At the end of the day, if there are only two heavy-weight languages its without a doubt C++ and Java. The only other language I would even consider would be C# but that is pretty much the MS version of Java, so learning Java you would know 90% of C# anyway. But anyway, you cannot go wrong with either C++ or Java.

Share this post


Link to post
Share on other sites
ATC    551
Programming languages do not have any quality or property called "power"... So you'll never see anything like:

Language: C++
Horsepower: 700
Torque: 580lb-ft

There's simply no such thing... [img]http://public.gamedev.net//public/style_emoticons/default/biggrin.png[/img]

Some languages perform differently from others, but there are no hard-set rules about performance either. Generally, languages compiled to machine code (native binary for the CPU) are faster than "JIT'ed" managed languages which are faster than interpreted languages. But there are even exceptions to this general rule... On quite a few occasions I've written and tested C/C++ and C# code side-by-side and seen the C# code out-perform the native code. There are various articles you can find online if you're more interested in language performance.

Any language that is Turing-complete (which is pretty much [i]every [/i]programming language) is theoretically capable of calculating/simulating the entire history of the known universe; provided it runs on a system with unlimited memory. Therefore there's no reason you cannot create the same game in C, C++, Java, C#, Visual BASIC or assembly language.

Regards,

--ATC--

Share this post


Link to post
Share on other sites
carloscruz    149
Many functions of Java rely on the utilization of API that are not specilalized (like using BufferedImages and 2D GUI Api to draw sprites). Depending on which API you will use, your game may consume many more memory than necessary and go much slower than you would expect. The compiler+language+architeture are not a deal but how they are binded with some technologies(API) makes a HUGE difference.

I don't like to be forced to use (b & 0xff) for every byte to be able to know its integer value (to the hardware it donesn't need that operation but whenever the data need to be known or parsed it will have to be translated to more common values, if you like to use more known constants).

Data are not data.. you can't just cast things because they are encapsulated in round/closed solutions called classes... and they require you to use paths to deal with them: functions.. and java functions can be tedious since you may lose speed if you are heavy user of objects..

Java is not for speed. Is for portability and facilities(web). What you see as graphical results comparing Java and C/C++ is just the work of native graphics API/drivers receiving the necessary data at a constant rate. And the data received by OpenGL, for example, must match its requirements and I don't know if the java interface doesn't shift things before sending to the drivers.

Memory: you don't know how much memory an object will take and how worse it can get when you use third-party objects made for other kinds of solutions (not specialized in your case/solution) when you just use a bunch of them (Java is good using arraylists to store objects, not arrays - as records/structures..). In Java, all turns to facilitate the alignment in memory: I believe that most of the speed Java has is because the compiler hides what he does do store your, for example, stricted 3 byte data in 4 bytes in memory, wasting one byte just to have easy access, and how big is the speculation of the amount of memory needed for your JVM when you allocate memory: if you read a 30MB file, the JVM will request more than 80MB to the OS, trying to facilitate things for the programmer by speculation to the "future".. the flawless impression that Java does costs memory because when there is no more memory, your virtual machine/application just stalls and you have nothing more to do (even freeing objects won't make you able to continue, by how I use to face).
There is the garbage collector but it is more to a unspecialized guardian of presumable roads through what you may go or not, trying to let out of the oval circuit of memory reutilization the "stones" that your last lap had left and that you are maybe still using... lost threads sometimes are part of those.. but it is not easy to have a virtual clean and opened highway in front of you when you don't have ways to know in what speed you'll go (I mean dynamic memory utilization) because only the JVM knows where to store what you need.. and aligned in 4 bytes.. always.. per object (if you have a thousand objects of 3 bytes, you'll lose a thousand bytes if you store it in objects - if it is good or not, is up to you to know).

You may notice that if the project made in Java acts like a known tree, having all its growth process presumed and repeating it everytime, the JVM will not have so many issues about memory or the lack of speed that some facilitations that high level languages offer and that it is up to the programmer to make code that will slimly fit into the sharp requisites of API, working perfectly in the electric level of seam between the software conceptions and its overheads and the hardware immediate needs and characteristics but.. take care about what Java hides.. Edited by Caburé

Share this post


Link to post
Share on other sites
Aeramor    1930
I was once tasked with creating a game in java. Here is what I learned:[list]
[*]Java is a terrible environment to work in. Debugging is atrocious and the tools for it are from the archaic at best and intentionally tortuous at worst. (compared to something like VS2010/2012).
[*]Speed wise it's incredibly slow but it's been mentioned several times here that for an indie team or a beginning developer you are not going to be pushing the envelope so don't worry about that.
[*]Java applets (so you can have a user play on/in a webpage instead of downloading your game first) means a lot of extra headaches not least of which is securing your assets.
[*]Java updates will constantly break your build and having the JDK on your computer will drive you insane.
[/list]

That said, I don't think that speed should be your primary concern if you are just starting out in game development. C++ is much harder to develop and poorly written c is still going to be slow perhaps even slower with more memory leaks and crashes.
My recommendation for most new developers is C#. It's a SOLID language with incredibly robust tools, tons of support and an awesome community at the XNA forums. With some clever code you can attain perfectly reasonable speed even on heavy weight 3D applications. If your end goal is to be an engine developer somewhere like Epic or Rockstar games you need to be learning C++, otherwise pick a language that makes you comfortable with tools that you can understand.

Obviously you can tell I didn't personally like working in Java but then I'm an old fogie C developer. Hopefully you will take what I said with a grain of salt, evaluate the tools/language for yourself and make an informed decision you don't regret later.

Share this post


Link to post
Share on other sites
ATC    551
[b]@ Aeramor[/b]:

I agree with pretty much everything you said. I've never liked Java. I won't say language A sucks or language B is the greatest, but Java always seemed slow and unstable to me, whereas C# applications are snappy and responsive like C/C++ applications. I also agree that Java IDEs don't even hold a candle to Visual Studio; its really the best IDE for Windows available, and you can also of course use it to develop cross-platform applications.

However, I disagree with this:

[quote name='Aeramor' timestamp='1352149825' post='4997731']
If your end goal is to be an engine developer somewhere like Epic or Rockstar games you need to be learning C++ [...]
[/quote]

Yes, he does need to be learning C++... but not because it's the only path to being an engine developer, but because knowing C/C++ is an essential skill for any game programmer worth his salt! The 2000-teens are going to be the era of the managed engine. For years gamers have been accepting a lot of unstable code (consider Skyrim's tendency to CTD and lose textures at run-time) because applications/games are growing so large and complex that no mere mortal can manage all of its memory and resources. In this context C# and the CLR looks more appealing every day because its gains in memory efficiency, stability and type-safety are beginning to make it a more performant choice than native languages. This is precisely why my company is developing a managed engine in C# instead of using the traditional approach of C++...

Regards,

--ATC--

Share this post


Link to post
Share on other sites
SimonForsman    7642
[quote name='Anri' timestamp='1352028105' post='4997140']
Its surprisingly powerful. True, C++ is great for speed and flexibility, but Java is a good all-rounder. For 2D games, C++ isn't going to provide any more speed than Java, but getting into 3D, you might find C++ a better choice - but even then, it depends on how advanced you want your visuals to be: are you aiming for a Doom 3 level 3D engine or are you thinking of writing a 3D app like Maya or 3dsMax?

From experience, Java is certainly a good choice. At the end of the day, if there are only two heavy-weight languages its without a doubt C++ and Java. The only other language I would even consider would be C# but that is pretty much the MS version of Java, so learning Java you would know 90% of C# anyway. But anyway, you cannot go wrong with either C++ or Java.
[/quote]

Actually, the visuals is the part least affected by the language/compiler/vm/runtime choice since it is (Assuming you use a modern 3D API) handled by the GPU. (There is a bit of additional overhead on the API calls themselves but it is fairly negligable unless you use something silly like OpenGL immediate mode).

I'd be far more worried about things like Physics(Allthough this can run on the GPU these days as well), While Java does perform the actual calculations just as fast as any other compiled language, with some exceptions since Java guarantees a minimum accuracy for all math operations(and the x86 CPUs doesn't meet all of them so you have to be careful there or things can slow down considerably) If you are writing a advanced game in Java you should read up on what Java operations the x86 will struggle with.
It also doesn't give you any low level control which does make it impossible to manually optimize things at a low level. (You can't write your own SIMD code for example and you can't fully control the memory layout), you get what Oracles JIT compiler gives you.

The biggest performance issue however is usually not with Java or the JVM itself, but rather with the practices Java encourages. (Excessive heap allocations/deallocations for example is one of the more common mistakes Java programmers tend to make and it results in memory fragmentation and increased cache misses (Which really kills performance).

Share this post


Link to post
Share on other sites
Anri    971
Re: SimonForsman

I quite agree. The problem I've had in Java programming is with software rasterization, but who uses that in todays game development? Apart from perhaps raycasting or educational purposes, there isn't much point.

Share this post


Link to post
Share on other sites
carloscruz    149
Java offers ways to process pixels fast using BufferedImage. I've made this sample to test it (2D):

[media]http://www.youtube.com/watch?feature=player_detailpage&v=646NKDbbUxA[/media]


There is just one character and effects made straight to the pixels. I believe that, if things should have been spread through other objects, it could need a redesign to take advantage of architetural aspects as how loops and other predictions and metadata creation are made. Edited by Caburé

Share this post


Link to post
Share on other sites
carloscruz    149
I am not saying java is bad or worse. It is different. I'll try to explain what I've got trying to use both OOP and needed software graphics simple operations as arraycopy and simple mean, additions/subtractions for bright/contrast (without hardware acceleration).


In Java, you can't control things at the hardware level (you can just prepare data to send to it): you just write and hope it to run at reasonable speed and Java doesn't have accurate timers - even a diference of time can't be assured to be real. Example:

// compares two moments, in miliseconds

long time1 = System.currentTimeMilis();

anObject.doThings();

long timeElapsedMs = System.currentTimeMilis() - time1;

System.out.println(timeElapsedMs);

//--------------

The time shown above can't be trusted to be exact about the time ran.

I was once trying to use math to make a sequence of events to become stable by skipping fixed periods of time based on a known variation and sleeps, shifting from slow to fast to make all run in the expected framerate and I could not make it work because the time difference always were over a limit of ˜8FPS (1000/8 = 120 ms) USING System.ArrayCopy (supposed to be the fastest way) - the job was to copy to a buffered image pixels the pixels of a source buffer, in the same format: Java schedules memory reallocation and garbage collection while in the loop and, for being so oriented to objects, I could never know when Java was bouncing the top amount of memory needed to keep the animation/reallocation (I tried to cut all to a fixed size copy/paste of memory) but for every single aspect, even to get current timedate you need a new object - new Date( ), for example. In the withins, Java creates many more objects. If you rely on that, your perfect Java written code may (may) become a powerful... resource eater.


If you need precision, you must rely on hardware. Relying on hardware makes that assumption about "compile once, run anywhere" worse: C/C++ can be used to run software that binds straight to the OS, without balances and fixed panorama about a basic architeture and reasonable speed conform that design. Reasonable speed conform the design is something that must be very good in Java Code for you to have a good result if you pretend to port applications. Edited by Caburé

Share this post


Link to post
Share on other sites
PurpleAmethyst    335
Does anyone ever get sick of the "How powerful is language X?" or "My language pwns yours"?

Better to ask "Can I get the job done in time with language X?". The answer is usually yes.

*yawn*

Share this post


Link to post
Share on other sites
tufflax    504
One good thing about learning Java is that when you realize that Clojure is the best language ever you will be able to carry a few things over. [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img] (I don't mean to start a flame war, I just want more people to know about the absolute awesomeness that is Clojure.) Anything that Java does, Clojure does better. Programming in Clojure is pure bliss.

Honestly, if you are gonna go with Java, you might as well go with Clojure. Check it out: [media]http://www.youtube.com/watch?v=Aoeav_T1ARU[/media]
Although the video does not do the language justice. Edited by tufflax

Share this post


Link to post
Share on other sites
tufflax    504
[quote name='PurpleAmethyst' timestamp='1352389764' post='4998904']
Any anything clojure does Groovy does better ;)....

[url="http://groovy.codehaus.org/"]http://groovy.codehaus.org/[/url]
[/quote]

And you have tried Clojure?

Share this post


Link to post
Share on other sites
PurpleAmethyst    335
I've never used Clojure on a commercial project. I have, however, used Groovy. I liked the fact I could inline JAVA and Groovy together. It helped get the job done very quickly.

Also, as you can see below, Groovy is less typing (Trivial example I know).

Groovy (70 Characters):

[source lang="groovy"]for (i in 1..100) { println "${i%3?'':'Fizz'}${i%5?'':'Buzz'}" ?: i }[/source]

Clojure (116 Characters):

[source](map #(cond (zero? (mod % 15)) "FizzBuzz" (zero? (mod % 3)) "Fizz" (zero? (mod % 5)) "Buzz" :else %) (range 1 101))[/source]

Share this post


Link to post
Share on other sites
tufflax    504
[source lang="plain"](map #(condp (fn [d n] (= 0 (mod n d))) % 15 "FizzBuzz" 3 "Fizz" 5 "Buzz" %) (range 1 101))[/source]
91 characters. [img]http://public.gamedev.net//public/style_emoticons/default/tongue.png[/img]

I haven't used Groovy, but I can't imagine that it could be better than Clojure. [img]http://public.gamedev.net//public/style_emoticons/default/tongue.png[/img] Anyway, I wouldn't inline Java in Clojure even if I could. Clojure's Java interop is very good. For example:
[source lang="java"]JButton okButton = new JButton("Ok");
okButton.setBounds(30, 35, 80, 25);
okButton.addActionListener(this);
panel.add(okButton);[/source]
becomes
[source lang="java"](.add panel (doto (JButton. "Ok") (.setBounds 30 35 80 25) (.addActionListener this)))[/source]

And even though Clojure is code not the shortest when it comes to small examples, the homoiconicity and simplicity of the syntax is very useful, and macros can get rid of a lot of code in longer programs. Edited by tufflax

Share this post


Link to post
Share on other sites
[quote name='PurpleAmethyst' timestamp='1352397379' post='4998945']
Also, as you can see below, Groovy is less typing (Trivial example I know).
Groovy (70 Characters):
[source lang="groovy"]for (i in 1..100) { println "${i%3?'':'Fizz'}${i%5?'':'Buzz'}" ?: i }[/source]
Clojure (116 Characters):
[source](map #(cond (zero? (mod % 15)) "FizzBuzz" (zero? (mod % 3)) "Fizz" (zero? (mod % 5)) "Buzz" :else %) (range 1 101))[/source]
[/quote]Comparing apples to oranges. The Groovy one-liner is so clever it's no longer readable (nested ternary operators? please) and I'd complain about it in a code review, whereas both your and tufflax' Clojure implementations are clean code minus whitespace.

Share this post


Link to post
Share on other sites
PurpleAmethyst    335
Yeah, I realize it was a bit trivial. Neither example is mine. I guess I'm not a big fan of LISP (yet) which doesn't help. I'm studying Haskell at the moment with some friends in the local hackerspace so my mind may change.

One thing I do like about Groovy is the ability to encode statements in the quotes using ${}. The in the above example isn't really a great demonstration of where it would be useful and I wouldn't be using nested ternary operators myself either, I'd complain about it too in a code review.

Share this post


Link to post
Share on other sites
jbadams    25674
[quote name='Aeramor' timestamp='1352149825' post='4997731']
Debugging is atrocious and the tools for it are from the archaic at best and intentionally tortuous at worst. (compared to something like VS2010/2012).
[/quote]Try [url="http://www.jetbrains.com/idea/"]IntelliJ[/url] -- I haven't used it for quite some time, but last time I tried it was very good, and the other products from the same company are excellent. [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]

Share this post


Link to post
Share on other sites
Bacterius    13165
I'm not sure why people are fighting over which language can produce the shortest one-liner to the fizzbuzz challenge, or any other problem for that matter. As far as I'm concerned it's the logic, concepts and train of thought behind the code that matter, rather than how many bytes I can encode my solution into. Sure, it's fun and all to compare, but unless said one-liners are readable, I don't want them in any code I look at (the Clojure code is quite nice, actually, but the Groovy one is at the edge).

It's like that guy who implemented a basic ray tracer in 99 lines of ultra-compressed - and, quite frankly, unreadable without adding line breaks - C code. I just don't see the point. Every time I stumble across it, I die a little inside. I too can compress my code with 7z and end up with sub-1KB source code, big deal. Is it useful? No. Is it helpful to others? No. Does it warrant bragging rights? To people who want to understand the code, certainly not. Edited by Bacterius

Share this post


Link to post
Share on other sites
Alpha_ProgDes    6921
[quote name='Stroppy Katamari' timestamp='1352404015' post='4999000']
[quote name='PurpleAmethyst' timestamp='1352397379' post='4998945']
Also, as you can see below, Groovy is less typing (Trivial example I know).
Groovy (70 Characters):
[source lang="groovy"]for (i in 1..100) { println "${i%3?'':'Fizz'}${i%5?'':'Buzz'}" ?: i }[/source]
Clojure (116 Characters):
[source](map #(cond (zero? (mod % 15)) "FizzBuzz" (zero? (mod % 3)) "Fizz" (zero? (mod % 5)) "Buzz" :else %) (range 1 101))[/source]
[/quote]Comparing apples to oranges. The Groovy one-liner is so clever it's no longer readable (nested ternary operators? please) and I'd complain about it in a code review, whereas both your and tufflax' Clojure implementations are clean code minus whitespace.
[/quote]
I'm sorry but that Groovy isn't that clever (ie. terse) and it's very readable. And actually it's easier to read the Groovy than the Clojure. As far as Scheme-like languages go, I've used Racket, as a learning tool. And I think it's great.

But to get back on topic, Java as a language or a platform can address all the needs a developer or business may have.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this