Jump to content

  • Log In with Google      Sign In   
  • Create Account

[java] Java disadvantages


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
43 replies to this topic

#21 StratBoy61   Members   -  Reputation: 232

Like
0Likes
Like

Posted 26 April 2007 - 08:20 AM

I am surprised not to read anything about the *supposedly* Java multi-platform feature. I remember back in the years, where my Java program would behave differently depending on the JVM. Sometimes it would simply crash.
I could not believe that nowadays the problem no longer exists.

Anyways, I think that if one wants to create something such as a casual game, and is targeting different platforms, Java + a 3D accelerated library should be a good choice. There might be slight problems on different platforms, but it should be overcome for a game not too demanding. Now, if you target some specific environment, you might want to take the most specialized tool for it, with compiled code, that will not move/change. I believe that it is actually dangerous to be able to change a part of a program later on, like a library or JVM version, although it can sound attractive at the beginning. Some people see it as a plus... I assume it is because they have not got into the hassle yet ;)
Cheers
StratBoy61

[Edited by - StratBoy61 on April 26, 2007 2:20:50 PM]

Sponsor:

#22 Alpha_ProgDes   Crossbones+   -  Reputation: 4688

Like
0Likes
Like

Posted 26 April 2007 - 09:14 AM

Quote:
Original post by pinacolada
On a similar topic, all this talk of performance makes me think of another Java disadvantage: writing high performance Java code requires too much Java-specific knowledge.


I believe that holds true for ANY language you program in. ANY.

#23 CaptainJester   Members   -  Reputation: 523

Like
0Likes
Like

Posted 26 April 2007 - 09:18 AM

Quote:
Original post by Captain Goatse
I think it is a very bad idea to push this issue down because language X happens to be your favorite language, since in reality it is a issue. I just finished porting some 2d physics code from C++ to Java and I'll have to say I am very disappointed in the pure number crunching performance of Java. With the C++ application I am able to push through 500 objects that consist of a polygon easily, whereas the Java application starts struggling heavily if the number of objects exceeds 100. Same computer, same code, different languages.


And therin lies the problem. You wrote C++ code in Java, that will always take a penalty. When you are writing in a language you have to write in that language, not just copy code over fix the errors and say it's done. Any half decent Java programmer could look at your code and double it's output without breaking a sweat.

"None of us learn in a vacuum; we all stand on the shoulders of giants such as Wirth and Knuth and thousands of others. Lend your shoulders to building the future!" - Michael Abrash[JavaGaming.org][The Java Tutorial][Slick][LWJGL][LWJGL Tutorials for NeHe][LWJGL Wiki][jMonkey Engine]

#24 pinacolada   Members   -  Reputation: 834

Like
0Likes
Like

Posted 26 April 2007 - 09:49 AM

Quote:
Original post by Sneftel
Quote:
C++ was always designed to be no more high level than necessary. And so there's nothing going on "behind the scenes", the program does what you tell it to and doesn't do what you don't.

The hell it does. Tell me: What happens when you do dynamic_cast? If you can tell me in less than 1000 words, you're wrong.

Okay. Saying there's "nothing" going on was a bit too far. But I maintain that Java has several orders more behind-the-scenes action going on.

And C++ has many subsets. If our naive programmer doesn't like or trust dynamic_cast, they have the option of avoiding it (maybe by writing a pedantic C-like version that solves the same problem). In this way C++ has fewer gotchas, as programmers aren't forced to use features that they don't understand. But all Java programmers, beginner and expert, are forced to deal with a monolithic, magical garbage collector.

Quote:
Er, once you've explained to him when he should pass by reference and when he shouldn't, and when he should throw exceptions and when he shouldn't, and when he should use endl and when he shouldn't, and the difference between std::find and std::set::find, and when he should use std::vector instead of std::list even when he's doing a lot of middle-insertion. Oh, and don't forget to explain to him all the different common idioms for memory ownership transfer and how to recognize them and when he should use shared_ptrs and when he shouldn't.


I wouldn't call memory ownership transfer a domain-specific problem, it applies to any language that doesn't manage your memory. Plus, even the complicated memory ownership algorithms are easier to understand than the intricacies of the Java GC. Pass-by-reference versus pass-by-value is also not specific to C++ (and it's also pretty easy to explain)

Those other things you mentioned probably do qualify as C++ gotchas, but (and this part is subjective), they all seem pretty trivial in comparison to Java gotchas. If I was going to write a list of C++ gotchas versus Java gotchas, my opinion is that the Java list would be several times longer and have more severe items.

Quote:
Throwing around a statement like "Java needs more special-purpose knowledge to obtain good performance" without real-world measurements is pulling facts out of your butt.


Point taken :)

#25 Ahnfelt   Members   -  Reputation: 176

Like
0Likes
Like

Posted 26 April 2007 - 11:51 AM

Quote:
Original post by pinacolada
Java on the other hand, has tons of stuff going on behind the scenes. And our expert programmer (who also doesn't happen to know much about Java) can't just walk up to a Java compiler and write fast code. He needs to be an expert at Java. He needs to understand all those runtime flags for specifying the behavior of the garbage collector. He needs to understand generational garbage collection, so that he can avoid letting objects unnecessarily survive to the old generation. He needs to know to use ByteBuffers when using JNI code. And the list goes on..

Garbage collection is by no means specific to Java; it was invented and implemented in Lisp more than 10 years before C was conceived, and virtually every language designed during the last 10 years has garbage collection. Hence, a programmer that does not know how garbage collection works can hardly be called an "expert" programmer.

Sure, the JNI interface is messy; most language to language interfaces are. Is C++ any different? (there are automation tools for JNI just like there are for language interop in C++).

So what's left as a burden on the programmer is runtime flags? Given the choice between learning these - after your program is working, when you get to the optimization - and spending time from day one on manual memory management in C++, which do you prefer?

#26 Aldacron   GDNet+   -  Reputation: 3181

Like
0Likes
Like

Posted 26 April 2007 - 03:34 PM

Quote:
Original post by pinacoladaIn this way C++ has fewer gotchas, as programmers aren't forced to use features that they don't understand. But all Java programmers, beginner and expert, are forced to deal with a monolithic, magical garbage collector.


Yeah, and C++ programmers are forced to manually manage memory. There's nothing magical about garbage collection (and I wouldn't describe Java's implementation as 'monolithic'). In languages that don't have it, you often wind up implementing some form of it anyway (or integrating a third-party solution). Sure, you don't implement full on garbage collection algorithms, but some form of custom or third-party memory manager is common in games and other applications (just look at how many of the Gems from the GPG series deal with the topic, or search for all of the posts on this forum about it). You could argue that it's tailored to the needs of a particular game or engine, but then I could argue right back that you've increased code complexity, maintenance costs, and when it comes time for the next game, or an overhaul of the engine, you've got more to refactor.

Garbage collection in Java has evolved over the lifetime of the language. There is more than one implementation to choose from, but for most purposes the default serves just fine. Walter Bright wrote a nice little summary of garbage collection, both positives and negatives, in the D specification. He has said that he once was highly skeptical of garbage collection until he actually did the research on it. From then on, he understood the benefits and that led him to make it a must-have feature for D. D's garbage collector is still quite primitive and not highly optimized, but still works well and does not impact performance in the majority of cases. Compare that to the Java implementations, which have years of evolution and optimization behind them.

There are issues that arise from using Java and tradeoffs to be made. But generally, they are not the issues that people who don't use Java *think* they are. Until they've rolled up their sleeves and gotten covered in a language up to their elbows, how can anyone say with any authority what the benefits and drawbacks are? Just dabbling their fingers in it isn't enough. If that's all they've done, most of what they say is just speculation and hearsay.

I can speak from experience on C, Java, and D because I have spent a lot of time with them and know them well. I'll happily list for anyone all of the things I dislike about Java (and there are actually quite a few). I've never been interested in C++, nor had a need to use it in anger. I know the basics, understand templates, have a passing knowledge of the STL, and can generally get on with it. But if I were to go off on what I think are the deficiencies of C++, I'm sure that most of my arguments would be shot down by those with millions of lines of C++ code behind them.

There's nothing wrong with criticizing a language, but you have to be aware of the difference between an educated critique and that based on limited exposure to the language. The list of deficiencies and you get from an experienced user of a language is going to be quite different than the one from someone who has only dabbled.

#27 Simbosan   Members   -  Reputation: 122

Like
0Likes
Like

Posted 26 April 2007 - 04:15 PM

As a dabbler I am aware that Java 'in theory' can be faster than C++ for all the very erudite reasons in this thread.

But it doesn't do DirectX

So for me it's irrelevant. Java has always been superb in its little sandbox, but as soon as you try and 'talk to the machine' I find it's usefulness begins to erode.

Am I too fixated on DirectX? In my understanding, 'Windows Game' pretty much equates to 'DirectX Game'. Am I mistaken?

S

#28 Hodgman   Moderators   -  Reputation: 30384

Like
0Likes
Like

Posted 26 April 2007 - 04:42 PM

I made some test programs a few years ago, because the Java fanatics kept telling me that Java is just as fast as my precious C, and I refused to believe them.

To my surprise, simple programs, such as running a tight for-loop and assigning values to primitive types in java had almost exactly the same execution time as C! (the difference was only a few milliseconds for billions of loops - which is probably incurred by Java's start-up overhead).


Although Java can do simply things as fast as C, I still think it probably has a lot of overhead in other areas (garbage tracking, runtime compilation, all functions are virtual, etc...).

The programming language shoot-out benchmarks show C++ being between 1.1 to 13.0 times faster than Java on most tests. Java is only faster (1.3 times) than C++ on one test for concurrency (and if you're a cynic, you could blame the fact that the C++ implementation uses pthreads).


As a side note, last time I checked the Java spec, it was optional for a VM implementation to actually run the garbage collector at any time besides at program shutdown. I know of a few mobile phones that do this - and it forces the developers to abandon automatic memory management and OO-style code in favour of something resembling a C-program designed to work without a heap!

#29 SimonForsman   Crossbones+   -  Reputation: 6109

Like
0Likes
Like

Posted 26 April 2007 - 05:03 PM

Quote:
Original post by Simbosan
As a dabbler I am aware that Java 'in theory' can be faster than C++ for all the very erudite reasons in this thread.

But it doesn't do DirectX

So for me it's irrelevant. Java has always been superb in its little sandbox, but as soon as you try and 'talk to the machine' I find it's usefulness begins to erode.

Am I too fixated on DirectX? In my understanding, 'Windows Game' pretty much equates to 'DirectX Game'. Am I mistaken?

S


Indeed you are mistaken, OpenGL works just aswell in Windows (better even on modern hardware in XP and older windows versions)
Then ofcourse, DirectX works pretty darn well with java aswell if you write a wrapper for it. (I can't think of any reason why a sane person would bother though as OpenGL gives full hardware access on all major platforms (with the appropriate drivers ofcourse))

#30 Simbosan   Members   -  Reputation: 122

Like
0Likes
Like

Posted 26 April 2007 - 05:17 PM

I would think OpenGL games are as rare as hens-teeth nowadays. I can't remember the last time I had to install OpenGL drivers on a PC. I don't think my current PC has them at all.

And just 'writing a wrapper' for DirectX isn't so straightforward, and has (major?) performance implications.

S

#31 Ro_Akira   Members   -  Reputation: 212

Like
0Likes
Like

Posted 26 April 2007 - 05:30 PM

OT, but AFAIK, all id Software games starting with glQuake have supported OpenGL. And that means all games based on the QuakeII/QuakeIII/Quake4/Doom3 engines have been using OpenGL aswell. I think you'll find that's a reasonable number of well known games, all being said...

#32 SimonForsman   Crossbones+   -  Reputation: 6109

Like
0Likes
Like

Posted 26 April 2007 - 05:44 PM

Quote:
Original post by Simbosan
I would think OpenGL games are as rare as hens-teeth nowadays. I can't remember the last time I had to install OpenGL drivers on a PC. I don't think my current PC has them at all.

And just 'writing a wrapper' for DirectX isn't so straightforward, and has (major?) performance implications.

S


Normally you can't avoid installing OpenGL drivers on a modern system, they are included in the normal driver package if you have a graphics card from AMD/ATI or nvidia.

Most OpenGL games doesn't mention opengl in the system requirements. (They generally use DX version support for the cards instead to avoid confusing the consumers)

Quake4 uses OpenGL but still has
Quote:

3D Hardware Accelerator Card required
100% DirectX 9.0c compatible 64MB
Hardware Accelerated video card and the latest drivers

ATI Radeon 9700
ATI Radeon X300 Series
ATI Radeon X550 Series
ATI Radeon X600 Series
ATI Radeon X700 Series
ATI Radeon X800 Series
ATI Radeon X850 Series
NVIDIA GeForce 3/Ti Series
NVIDIA GeForce 4/Ti Series
NVIDIA GeForce FX Series
NVIDIA GeForce 6 Series
NVIDIA GeForce 7 Series


in its requirements for example.

#33 Christian Weis   Members   -  Reputation: 97

Like
0Likes
Like

Posted 27 April 2007 - 02:31 AM

Quote:
Original post by Ahnfelt
Quote:
Original post by Christian Weis
That's the point. Most objects only survive for a short period. So why not just place them on the stack. Even if generational GCs can handle them somewhat effectively, they won't do it as good as a stack can. And please note that generational GCs are very complex and therefor hard to maintain and even harder to debug. A stack would be so pretty simple and powerfull.

Actually, blindly allocating on the stack when the object only lives for the duration of a function can be quite ineffective. Consider the following C++ example:
void foo() { MyObject object(); object.doStuff(); while(...) {some long-lasting loop not using object} }
will keep object alive for far longer than it needs to be. Even worse is a recursive function that stack allocates a temporary object before the recursive call, thus filling up the stack with temporary "dead" objects.

...

But obviously stack allocation can be a speedup when used with care. It's just that it's a burden on the programmer.

Region-based memory management may be the solution, allowing most objects to be statically memory managed with little programmer interference. I haven't read the whole article yet though. Edit: eeeek, it's even more technical than I expected. Maybe I'll wait for the Wikipedia entry ;-)


I'd never sad that object's should be placed on stack blindly. And the example you've presented is correct but only for beginner/unexperienced coders. And stack allocation is not a burden but more an exoneration and more freedom of decision-making.

Quote:
Original post by Ahnfelt
A GC would free these as soon as they're dead and the memory they take up is needed.

This depends on the implementation of the GC. In fact most GC's does simply nothing but waiting until a given threshold is reached. This threshold is typically 3/4 of available RAM. Generational GCs may jump in more often but the main problem of the GC in Java is:
You cannot know for sure!

Another problem of java is the high memory consumption. Every object in Java is bloated with a bulk of stuff:
- Pointer to its class
- Reflection-cache/data
- Internal statistics/data needed for HotSpot compilation
- Synchronization-objects for GC/lazy loading
- VM internal bull-shit
However there're cases where you can live without the above stuff. But in Java it's impossible to declare some kind of *naked* class.

In theory a HotSpot/JIT-compiler can do much better than a static compiler like in C++, that's true. But in practice it cannot. If you have ever compiled a multi-mio LOC application with all optimizations turned on you know that this takes hours to complete. Just because the compiler spends most of the time (90%-95%) optimizing the code. So how many time do you think has a JIT to compile a class/method in native form? Do you really think that a JIT has enough time to do fency optimizations? In fact a JIT has only few milli-seconds. Maybe some inlining here and there. Maybe some peep-hole optimization. That's it. But no time for heavy time-consuming global optimizations.

cu,
Chris

#34 Captain Goatse   Members   -  Reputation: 100

Like
0Likes
Like

Posted 27 April 2007 - 03:55 AM

Quote:
Original post by CaptainJester
Quote:
Original post by Captain Goatse
I think it is a very bad idea to push this issue down because language X happens to be your favorite language, since in reality it is a issue. I just finished porting some 2d physics code from C++ to Java and I'll have to say I am very disappointed in the pure number crunching performance of Java. With the C++ application I am able to push through 500 objects that consist of a polygon easily, whereas the Java application starts struggling heavily if the number of objects exceeds 100. Same computer, same code, different languages.


And therin lies the problem. You wrote C++ code in Java, that will always take a penalty. When you are writing in a language you have to write in that language, not just copy code over fix the errors and say it's done. Any half decent Java programmer could look at your code and double it's output without breaking a sweat.


Oh please, tell me how do I increase the speed of raw calculation code by utilizing these advanced features of Java? There is only a number of ways you can do x*y. Also thankyou for making useless assumptions on my skills and the skills of the people I work with.

#35 Simbosan   Members   -  Reputation: 122

Like
0Likes
Like

Posted 27 April 2007 - 08:36 PM

Quote:
Original post by Ro_Akira
OT, but AFAIK, all id Software games starting with glQuake have supported OpenGL. And that means all games based on the QuakeII/QuakeIII/Quake4/Doom3 engines have been using OpenGL aswell. I think you'll find that's a reasonable number of well known games, all being said...


For purely 3D graphics yeah, but for everything else, sound, networking, input, it uses DirectX. I also think you will get more dev effort put into D3D drivers than OpenGL but thats just opinion.

Seems to me that Java means OpenGL unless you want to get into writing wrappers. Not via necessity, but just pragmatically.

S


#36 Ahnfelt   Members   -  Reputation: 176

Like
0Likes
Like

Posted 28 April 2007 - 12:21 AM

Quote:
Original post by Christian Weis
Quote:
Original post by Ahnfelt
A GC would free these as soon as: (they're dead and the memory they take up is needed).

This depends on the implementation of the GC. In fact most GC's does simply nothing but waiting until a given threshold is reached. This threshold is typically 3/4 of available RAM. Generational GCs may jump in more often but the main problem of the GC in Java is:
You cannot know for sure!

Sorry for being ambigious, see the inserted grouping paranthesis for my intended meaning.

But the point is that until you've eaten up that RAM, you don't really need to free up memory.

Quote:
Original post by Christian Weis
Another problem of java is the high memory consumption. Every object in Java is bloated with a bulk of stuff:
- Pointer to its class
- Reflection-cache/data
- Internal statistics/data needed for HotSpot compilation
- Synchronization-objects for GC/lazy loading
- VM internal bull-shit
However there're cases where you can live without the above stuff. But in Java it's impossible to declare some kind of *naked* class.

Apart from the pointer to it's class, I believe all of the above is stored in the class, not in the object. So it's a non-issue.

I'm more worried about the security features of Java, but I need to read up on that.

I can see where you're going with the restrictions on JIT optimization. I wonder if it caches some of the compiled native code on the disk somewhere for next time.

#37 CaptainJester   Members   -  Reputation: 523

Like
0Likes
Like

Posted 28 April 2007 - 04:35 PM

Quote:
Original post by Captain Goatse
Quote:
Original post by CaptainJester
Quote:
Original post by Captain Goatse
I think it is a very bad idea to push this issue down because language X happens to be your favorite language, since in reality it is a issue. I just finished porting some 2d physics code from C++ to Java and I'll have to say I am very disappointed in the pure number crunching performance of Java. With the C++ application I am able to push through 500 objects that consist of a polygon easily, whereas the Java application starts struggling heavily if the number of objects exceeds 100. Same computer, same code, different languages.


And therin lies the problem. You wrote C++ code in Java, that will always take a penalty. When you are writing in a language you have to write in that language, not just copy code over fix the errors and say it's done. Any half decent Java programmer could look at your code and double it's output without breaking a sweat.


Oh please, tell me how do I increase the speed of raw calculation code by utilizing these advanced features of Java? There is only a number of ways you can do x*y. Also thankyou for making useless assumptions on my skills and the skills of the people I work with.


Oh please, you have a highly complex physic library and all you do is x*y. Bull. That is not useless assumptions, it is fact if you program in one language for a long time, then switch to another, you will not be proficient in immediately. And since you seem to hate Java so much, that usually means no effort is put forth to use it properly.



"None of us learn in a vacuum; we all stand on the shoulders of giants such as Wirth and Knuth and thousands of others. Lend your shoulders to building the future!" - Michael Abrash[JavaGaming.org][The Java Tutorial][Slick][LWJGL][LWJGL Tutorials for NeHe][LWJGL Wiki][jMonkey Engine]

#38 Aldacron   GDNet+   -  Reputation: 3181

Like
0Likes
Like

Posted 28 April 2007 - 10:51 PM

Quote:
Original post by Simbosan
Quote:
Original post by Ro_Akira
OT, but AFAIK, all id Software games starting with glQuake have supported OpenGL. And that means all games based on the QuakeII/QuakeIII/Quake4/Doom3 engines have been using OpenGL aswell. I think you'll find that's a reasonable number of well known games, all being said...


For purely 3D graphics yeah, but for everything else, sound, networking, input, it uses DirectX.


Actually, if you look at the Quake 3 source, you'll find on Windows that input is handled by Win32 system messages and networking is done via WinSock. While a lot of games do use DirectInput, DirectPlay never really caught on. Most games use WinSock on Windows.

Access to DirectInput is available in Java via the JInput API, which can be used in conjunction with JOGL, and is also used internally by LWJGL. For audio, both JOAL and LWJGL give access to OpenAL (LWJGL also comes with an FMOD binding). For networking, Java has 2 networking APIs (java.net and java.nio).

Quote:
I also think you will get more dev effort put into D3D drivers than OpenGL but thats just opinion.


Yes, it is most certainly opinion. OpenGL is used in many, many computer graphics projects, including CAD software and special effects in movies. Games are only a small slice of the overall market. Many such projects rely on consumer-level hardware these days rather than the specialty machines of old. So graphics card vendors who target those markets, such as NVidia, put considerable effort into their OpenGL drivers.

Quote:
Seems to me that Java means OpenGL unless you want to get into writing wrappers. Not via necessity, but just pragmatically.


One of the motivations for many people using Java to develop games is to ease cross-platform development. That means OpenGL. The fact that no DirectX binding exists (other than that used internally by Java3D) just means nobody has wanted one badly enough to create it. DirectX is nice is you want to lock yourself in to Windows or increase your code complexity and maintenance overhead by maintaining multiple code paths (such as D3D and OpenGL renderers). When neither of those options is attractive, it's not the best alternative.

#39 Ahnfelt   Members   -  Reputation: 176

Like
0Likes
Like

Posted 28 April 2007 - 11:34 PM

If you want to make DirectX games with all the goodies that come with it, and don't mind that your games only run on Windows, you should certainly use C#. I, for one, care enough about other platforms to stick to portable game libraries and Java (or maybe Scala running on the JVM).

On the topic of efficiency, it won't take long to convince me that Java does not optimize number crunching a lot - because I don't care. It's not a problem; just make sure your design allows you to reimplement the bottlenecks in C where it might be needed. That is, when everything works and you want a few extra frames per second or lower cpu usage. Anything else is premature optimization.

As for virtually any hobby coder, he won't need those extra frames per second.

#40 Jemburula   Members   -  Reputation: 341

Like
0Likes
Like

Posted 29 April 2007 - 10:28 AM

Unfortunately I study Java at uni, I by no means know the language inside out or can put any real comparison between them. I do know however, that I have to participate in an online competition using Java as part of my marks for one of the subjects I am doing... Everytime I run my code I get a "time limit exceeded" error. On the site, Java is given twice as long as any other language to execute but I still can't make the cut. No one else I have spoken to can either... It's a fairly simple and small problem. It takes 0.1 second in my C++ version that is designed exactly the same and over 2 seconds (that is when the limit is exceeded) in Java. Ofcourse that is discounting this 'hot-spot' thing I just read about in here. Either way it annoys the hell out of me.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS