Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (491)
Games in Android Showcase (112)
games submitted by our members
Games in WIP (556)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 ... 3 4 [5]
  ignore  |  Print  
  Reasons why Java is not a good language for game development  (Read 24522 times)
0 Members and 1 Guest are viewing this topic.
Offline princec

JGO Kernel


Medals: 369
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #120 - Posted 2008-11-16 23:11:46 »

It's pretty fragile elimination that only occurs in a few relatively simple circumstances, and what's more it costs the VM time to calculate when and where it can do it.

I think the @BoundsCheckDisabled attribute is a great idea; it could be used to mark an entire class or a single method. It would only have effect when both:

a) The code is executed with full security privilege; i.e. it's either signed or executing locally and
b) I explicitly say that I want it turned off by the VM at startup

In other words it is no more dangerous than disabling assertions. But it could be used to great effect when writing codecs or doing some of the fancier graphical stuff, and very nicely ringfenced into particular methods or classes.

We really need to get out of this mentality that the JVM is the boss. They're our computers and we want them to do what we tell them to do not what someone at Sun decides they want them to do.

BTW Excelsior JET has had this ability for a long time now.

Cas Smiley

Offline Mr_Light

Senior Member




shiny.


« Reply #121 - Posted 2008-11-16 23:33:20 »

This would create grand effect of crippling Java as many (standalone) apps will disable it and value of Java platform will decrease rapidly. Try look to things at big picture... Luckily this won't happen, Sun won't allow this. You're perfectly OK to modify OpenJDK code if you wish, but it won't be Java.

I don't know what's wrong, either you like Java strengths and use Java for them or use native languages instead.

Quote
-J-Xverify:none - this switch turns off Java bytecode verification, making classloading faster, and eliminating the need for classes to be loaded during startup solely for the purposes of verification. This switch improves startup time, and there is no reason not to use it.
which breaks java security just as much - that is if I understood Whitfield Diffie right.

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline jezek2
« Reply #122 - Posted 2008-11-16 23:53:04 »

which breaks java security just as much - that is if I understood Whitfield Diffie right.

That's quite different thing, in how it affects typical program. You would have to manually generate bytecode to exploit it, which is not common. But what is very common, that there is chance of getting ArrayIndexOutOfBoundsExceptions in your code. Without forced bounds checking they'll trigger crash or what is more dangerous, just overwrite some memory and corrupt state of program.

If you're in need to have very performant code, write it as native code and call it using JNI. It will be just a fractional of the code base, thus it'll be much easier to check it's correctness and adding proper checks for input/outputs when interacting with Java side (again this is what JRE does when calling system calls). Then you'll get precise error reporting on most of code base and still have performant algorithm where really needed.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Mr_Light

Senior Member




shiny.


« Reply #123 - Posted 2008-11-17 00:10:32 »

Thats poor subsitude for the solution at hand: for the jni bit you can't turn bounds bounds checking on/off adleast while debugging you reap the benefits. Also you'd only annotate a fraction of your base which you can also write the same code around. - again a crash or corrupt state (instability) still dwarfs user experience for certain applications.
Quote
Then you'll get precise error reporting on most of code base and still have performant algorithm where really needed.
Under the proposed solution it's the same.

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline jezek2
« Reply #124 - Posted 2008-11-17 00:27:52 »

Under the proposed solution it's the same.

You're right it's the same, but if you're seeking for maximum performance, most likely you want also to use vectorized SSE2 code or things like that. These things are inaccessible in Java anyway and JNI way allows anything like that and it's the proper way and very well supported.

Which gets to that it would be nice to have some SSE2 library for Java implemented as intristicts to JIT (where you wouldn't have to worry about range checks as it would be done on full blocks). But I have problem imaginating how to make the API good enough cross platform wise.
Offline ewjordan

Junior Member





« Reply #125 - Posted 2008-11-17 02:39:36 »

This would create grand effect of crippling Java as many (standalone) apps will disable it and value of Java platform will decrease rapidly. Try look to things at big picture... Luckily this won't happen, Sun won't allow this. You're perfectly OK to modify OpenJDK code if you wish, but it won't be Java.
If elimination was done per-method or per-block instead of as a global flag, I can't think why everyone would just do it by default; at the very least that would be premature optimization.  Personally I would never, ever, ever do something like that unless I had a robust mathematical proof that I would never go over the bounds limits (which you should almost always have anyways -  plenty of us code C++ as well, and once I release it I'm just as positive that it's correct as I am about my Java code; I doubt many of us actually try to recover from index out of bounds errors, usually they just crash programs, so I don't know that we gain very much in a game from having the checks at all).

See below, though; I don't personally think the bounds checks are that much of a problem.

Quote
I don't know what's wrong, either you like Java strengths and use Java for them or use native languages instead.
I think that a lot of people want to use Java's strengths most of the time, but have the option to dig down and have a little more control over the details so that they can optimize bottlenecks.  Think C++ vs. assembly - the fact that occasionally a critical section of C++ code is written in assembly doesn't mean that the programmer should just write the whole thing in assembly, since they still get a lot of productivity out of the higher level features even if there are a few bits that they need more explicit register control over.

(Re: bounds check elimination)
It's pretty fragile elimination that only occurs in a few relatively simple circumstances, and what's more it costs the VM time to calculate when and where it can do it.
Yeah, but those "few relatively simple circumstances" probably cover 95% of the for loops ever written, which just loop over a pre-specified and unchanging range.  If your bottleneck doesn't fit into that category then it would most likely trash the cache anyways even if you did it in C++, so you've got bigger issues to contend with.  And I'm pretty sure the calculation cost for those checks is all at JIT time, so it shouldn't hurt your overall performance too much.

However, I totally agree that it would be far preferable to have the option (again, only for full-privilege code) - useful as training wheels may be, nobody in their right mind welds them on to all bikes by default!

Quote
We really need to get out of this mentality that the JVM is the boss. They're our computers and we want them to do what we tell them to do not what someone at Sun decides they want them to do.
Your statement sums up my feelings almost exactly.  No matter what optimizations make their way into the VM, it would be nice to have a little more flexibility ourselves if we do turn out to need it, even if it was just in the form of a few more flags that could be used to tune full-privileged applications or some annotations on methods to be handled specially.  IIRC some of the debug builds already have a lot of these options available, so it would just be a matter of swapping deployment flags so that they were included in the release VMs.

Quote
BTW Excelsior JET has had this ability for a long time now.
Does anyone here actually use JET?  It seems like a great piece of technology, with a lot of stuff that I'd really love to see in the JVM proper, but the price tag is awful high, esp. for independent game devs.  Also, am I correct that there's no Mac target? Sad

Quote from: jezek2
If you're in need to have very performant code, write it as native code and call it using JNI. It will be just a fractional of the code base, thus it'll be much easier to check it's correctness and adding proper checks for input/outputs when interacting with Java side (again this is what JRE does when calling system calls). Then you'll get precise error reporting on most of code base and still have performant algorithm where really needed.
I'd say that was a great option if not for two things:

1) The interface is quite slow, which renders it unsuitable for drop-in replacements of small hotspots.  It's really only going to help performance if you have a whole native library that you need for some heavy lifting, not just some simple bottlenecks in your own code that you want to speed up in straightforward ways like by eliminating bounds checks or manually managing memory (at least in my experience, which has been minimal because it was so painful and gained me so little).
2) It's a real pain in the ass to use.

If JNI allowed something more akin to C++ support for inline assembly, and made the interface a whole lot faster, I'd find it more usable.  I know that's almost impossible to get right technically, but to me that's what keeps it from being a real solution.
Offline mgianota

Senior Newbie





« Reply #126 - Posted 2008-11-17 04:52:54 »

This thread has taken a number of diversions away from its intended purpose but I can't say that I am unsurprised to see a discussion  of JNI. My feeling on Java now after having spent a week or so with the language is that it is mean-spirited. Let me explain. I was initially bemused as to why Java does not include so much of the C/C++ syntax which gives that programming language so much of its power and flexibility, but understanding dawned when I read this article: http://www.eweek.com/c/a/IT-Management/Father-of-Java-Has-His-Eye-on-Jackpot/.

I wish you the best of luck with your Java creations but I cannot help but feel that you are being led up the garden path with a watered down version of C++ by a very clever man that has deliberately forbidden vital syntactical constructs and programming idioms because the inclusion of those constructs would fight his ability to create tools that produce "semantic models of the application", not because the use of those constructs and idioms are representative of bad programming practice. What he means by semantic models of course is a model of a program that is amenable to algebraic manipulation.

Finally, to sum up. I read comments from one young man who proclaimed that, "Java is a language that your grandfather uses.". I'm inclined to agree; it is safe and doesn't allow you to do anything "dangerous". For dangerous, read "truly useful".

--Mario
Offline VeaR

Junior Member





« Reply #127 - Posted 2008-11-17 07:33:08 »

deliberately forbidden vital syntactical constructs and programming idioms
I find this one of the strengths of Java, and a (huge) problem of C++. A Java parser is easier to make, its simpler and faster. It is the reason why we have so much better tools for Java than there is for C++. Stricter, simpler syntax forces the programmer to write readable code. Java is much more readable than C++. Its easier to prototype, to debug, to reuse and maintain others code. Its more productive. C++ just cant compete with Java in these fields. C++ is so much occupied with making framework code, that it takes away a lot of time from working on the useful functionality. C++ makes you invent new language constructs, it makes you improve the language itself, while Java keeps you focused on the actual task. What Java lacks is a better, more direct control over the underlying VM. The language itself is fine.
Offline ewjordan

Junior Member





« Reply #128 - Posted 2008-11-17 08:51:30 »

I was initially bemused as to why Java does not include so much of the C/C++ syntax which gives that programming language so much of its power and flexibility...
Just to be clear: Lisp is a powerful and flexible language, as are many of its clones and spinoffs; C++ does not even approach that, and I think you'd be hard pressed to find someone skilled in many languages that would put it on the "flexible" end of the spectrum.  You can do anything you want in it, but it ain't gonna be pretty or fun!

What C++ is is a language that allows you access to low level features, and this is the fundamental difference between it and Java.  Most of the other differences are really superficial, and in most cases I actually think Java got them right (well, the lack of the friend keyword or anything that would let classes in different subpackages see each other's internals really bugs me - that one is a real pain to work around, as in, you can't work around it at all!).
Offline mgianota

Senior Newbie





« Reply #129 - Posted 2008-11-17 10:55:21 »

Hmm... I have enjoyed my time on this forum immensely, it is populated by very intelligent programmers. However, the real world beckons and I have a game to produce which I would have liked to have produced in Java but cannot because of the performance. I have seen the eminently capable LWJGL library though I am unwilling to opt for using OpenGL over DirectX. It is a shame that he used OpenGL 'cos I quite liked the screenshots for Puppygames and was disappointed that I couldn't play them. BTW IMO David Brackeen's Pulpcore is grr-eat. And JOGL is well... JOGL reminds me of that horse that is running around outside of a closed stable door.

I still have strong reservations about using Java exclusively for writing games and I simply don't believe it is up to the job. But I am not going to spend anymore time prodding at your hearts and minds by advocating C++ because it is obvious you have your souls set on Java. So I shall bid the forum a fond farewell and depart back to Microsoft land, where everything is bright and whizzy and explodes for no apparent reason. Grin Sanity beckons. As a parting shot, I'll leave you with a reference to a picture of a truly great language designer: http://www.research.att.com/~bs/

I shall return when I am equipped with OpenGL... Hell, maybe I'll write a Java SDL wrapper and return bearing a whizzy thin Java library. Who knows.

TTFN

--Mario
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #130 - Posted 2008-11-17 12:58:21 »

Since it seems you have your mind set on C++ anyway, why did you want to use java for your game in the first place?
I mean, to me this seems rather odd if you are unwilling to use OpenGL over DirectX. Have you considered using C#?
Just out of interest, what kind of game are we talking about anyway?

BTW, there is an SDL wrapper called sdljava. I've never used it, but maybe it could save you the trouble

Quote
But I am not going to spend anymore time prodding at your hearts and minds by advocating C++ because it is obvious you have your souls set on Java.
To be honest, I think the problem is maybe that you seem to be trying to be prodding at hearts, rather than contributing compelling reasoning. Maybe it was unintended, but some of your remarks were dangerously close to trolling IMHO.
(EDIT: on hindsight that was not totally fair. Sorry, just had the worst morning EVER)

Anyway, to each his own, and if you're happy with C++ then power to you. It's a safe bet. Believe it or not, many of us here use C++ too.

Offline princec

JGO Kernel


Medals: 369
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #131 - Posted 2008-11-17 14:42:12 »

'Tis a shame we still don't have DirectX though isn't it... after all this time...

Cas Smiley

Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #132 - Posted 2008-11-17 15:03:00 »

'Tis a shame we still don't have DirectX though isn't it... after all this time...

Cas Smiley

Oh, absolutely. It seems the appearance of Vista introduced a lot of OpenGL related compatibility issues.

Offline CommanderKeith
« Reply #133 - Posted 2008-11-17 15:15:03 »

Hmm... I have enjoyed my time on this forum immensely, it is populated by very intelligent programmers. However, the real world beckons and I have a game to produce which I would have liked to have produced in Java but cannot because of the performance. I have seen the eminently capable LWJGL library though I am unwilling to opt for using OpenGL over DirectX. It is a shame that he used OpenGL 'cos I quite liked the screenshots for Puppygames and was disappointed that I couldn't play them. BTW IMO David Brackeen's Pulpcore is grr-eat. And JOGL is well... JOGL reminds me of that horse that is running around outside of a closed stable door.

I still have strong reservations about using Java exclusively for writing games and I simply don't believe it is up to the job. But I am not going to spend anymore time prodding at your hearts and minds by advocating C++ because it is obvious you have your souls set on Java. So I shall bid the forum a fond farewell and depart back to Microsoft land, where everything is bright and whizzy and explodes for no apparent reason. Grin Sanity beckons. As a parting shot, I'll leave you with a reference to a picture of a truly great language designer: http://www.research.att.com/~bs/

I shall return when I am equipped with OpenGL... Hell, maybe I'll write a Java SDL wrapper and return bearing a whizzy thin Java library. Who knows.

TTFN

--Mario

This mario character is really quite funny. pity there'll be no more entertaining posts. And thanks so much for that picture!!!

Offline princec

JGO Kernel


Medals: 369
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #134 - Posted 2008-11-17 15:52:08 »

Kinda weird he couldn't even manage to install GL drivers; although about 35% of Vista OEM machines don't have them installed, all vendors do actually supply newer drivers that have OpenGL capability...

Cas Smiley

Offline Renoria

Junior Member




...


« Reply #135 - Posted 2008-12-13 13:22:09 »

Quote
[1] Native libs. Currently the only way to get decent graphics performance is to use native libraries. Native libraries such as LWJGL rely on the fact that the player has a decent video card, otherwise the library won't even open up a window. Most PCs have low-end video cards in them.

All good games require a good video card.

Quote
[2] Java2D's performance is awful. Even when using the hardware accelerated graphics you still find that the game's main loop stutters and lags.


This is not the case for me. I have developed lots of ORPGs in Java2D with no probs. If you do have problems, use JOGL.

Quote
[3] Bloated API. Many method names and class names are stupidly, anally long. For example, how many times have you had to type System.out.println("some string");? This is a ridiculous amount of typing for such a simple task.

Ever heard of "import static System.out;"?

Quote
[4] The garbage collector makes games slow and unpredictable. Good time management is a crucial aspect of any game. When you think about it a large chunk of the playability tuning that goes on in game development comes down to adjusting the timed appearance of game objects such as aliens and other moving objects. For a large game, the garbage collector makes it nearly impossible to perform synchronised screen updates.

This is not true. I run the GC once every min with no lag whatsoever. (1 GB ram, 1.3 Ghz CPU)

Quote
[5] Write once, run anywhere is a complete myth. It is write once, debug everywhere and if you are writing applets then that means testing it in IE, Mozilla & Opera running on a combination of Mac, Linux and Windows. Because of the run anywhere myth developers rarely take the time to produce different versions of their software tuned for different machines, something that happens in the C++ world all the time as a matter of routine.

Well this seems reasonable, as some functions work differently in other OSes.

Quote
[6] The lack of function pointers is a major pain in the arse. Having no closures is also a major pain. True, Java has anonymous inner-classes but anonymous inner-classes are ugly as Hell; they hang off your code in the editor like a wart.

If you need pointers, use a language like C++ or Delphi, or use a Native Lib.

Quote
[7] The security restrictions on applets have rendered them almost useless; you can't even read and write a temporary cache which means that games can't save state for the player. Games that force a player to revisit completed levels are a bit lame.

I'm sure RuneScape creates a cache on  your computer. If i'm not wrong its called file_store_32 in your OS drive... Also, RuneScape is
an applet.

Quote
[8] Size. At 14.5Mb the Java runtime is a huge lump of code for a casual game to be dependant upon. Flash games use only a small 1.8Mb runtime.

This was fixed in the newer releases. Also, you can compile your Java files to a native EXE format.
Pages: 1 ... 3 4 [5]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Nickropheliac (15 views)
2014-08-31 22:59:12

TehJavaDev (23 views)
2014-08-28 18:26:30

CopyableCougar4 (32 views)
2014-08-22 19:31:30

atombrot (41 views)
2014-08-19 09:29:53

Tekkerue (40 views)
2014-08-16 06:45:27

Tekkerue (35 views)
2014-08-16 06:22:17

Tekkerue (25 views)
2014-08-16 06:20:21

Tekkerue (37 views)
2014-08-16 06:12:11

Rayexar (72 views)
2014-08-11 02:49:23

BurntPizza (49 views)
2014-08-09 21:09:32
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!