Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (577)
games submitted by our members
Games in WIP (498)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2 3 4
  ignore  |  Print  
  Why Java, not C++?  (Read 12935 times)
0 Members and 1 Guest are viewing this topic.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Posted 2004-12-01 13:13:36 »

I'm getting ready to evangelise java as a games-dev language to professional games devs. Most of this I can do no problems but there's some help I could do with: bullet-points to answer the question "why bother switching from C++ lang to java lang?".

i.e. NO platform points (got more than enough of those).

i.e. it's been sooooo long since I've been a C dev (and I never did much C++) that I now only have vague memories of what makes it so much nicer to code in java.

So...let me have em! Smiley.

NB: I'm not looking for arguments, just single sentences. If I have no idea what you're getting at, I'll ask. But I'm pretty sure I'll recognise them when I see them.

malloc will be first against the wall when the revolution comes...
Offline kevglass

JGO Kernel


Medals: 85
Projects: 25


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #1 - Posted 2004-12-01 13:17:25 »

* Productivity - spend time focusing on the game functions not the language functions.

* Reusability - a lanaguge designed to produce reusable components tending the developer away from "shot term hacks"

* Toolset - Development toolset is rich and for the most part free. (note this isn't a great point when you consider the current engine status)

Kev

Offline shawnkendall

Senior Member





« Reply #2 - Posted 2004-12-01 13:27:41 »

Security - due to impossibility of pointer/memory exploits/bugs

Shawn Kendall
Cosmic Interactive, LLC
http://www.facebook.com/BermudaDash
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #3 - Posted 2004-12-01 13:37:06 »

I was hoping for:

Quote
* Productivity - spend time focusing on the game functions not the language functions.

more specific than this - you know what programmers are like, they want concrete examples.

For instance, saying "never have to do malloc" as opposed to "it's better to have stuff managed".

Quote

* Reusability - a lanaguge designed to produce reusable components tending the developer away from "shot term hacks"


Again, need specifics.

Quote

* Toolset - Development toolset is rich and for the most part free. (note this isn't a great point when you consider the current engine status)


That's something I'd see as platform, not language.

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #4 - Posted 2004-12-01 13:41:43 »

Quote
Security - due to impossibility of pointer/memory exploits/bugs


Great. As above, "security" on it's own would be too general, but the details are good. Even better would be particular concrete differences such as (off the top of my head):

"buffer-overflow attacks are impossible because you cannot overflow data structures and write to memory"
"typeless references are impossible so you always know exactly what you are pointing at; modifying a pointer to point at something unexpected hardly has any effect on the program at all"
"all methods pass-by-reference-value, so you can guarantee that method args are implicitly final (as the caller; no such luck for the callee)"

etc...

malloc will be first against the wall when the revolution comes...
Offline kevglass

JGO Kernel


Medals: 85
Projects: 25


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #5 - Posted 2004-12-01 13:52:37 »

You asked for single sentences Wink

Selling Java is selling the platform.

Productivity - Stop worrying about preprocessor directives, inlining and the name mangling a particular library uses. Start focusing on making your game toolset as smart as possible using the wealth of built in libraries for XML, GUI Design and Networking.

Reusability - Use a language designed around OO methodolgy instead of a lanaguge designed to illustrate an outdated unstanding of it. Stop worring about ornate intricaces of namespaces and multiple inheritence in C++ and start using the powerful yet simple syntax of Java.

No apologies for how managerial BS this sounds Wink

Kev

Offline Spasi
« Reply #6 - Posted 2004-12-01 14:21:59 »

I think you should also get prepared (if not already) to give arguments against the reverse: why C++ and not Java.

For example, we know that any C/C++ developer will argue about speed (and the lack of it in Java). And we also know that game developers are not particularly interested in OO/design/reusability advantages.
Offline crystalsquid

Junior Member




... Boing ...


« Reply #7 - Posted 2004-12-01 14:30:25 »

As a games proffesional (previously a lead core tech engineer writing graphics engines) I would have pooh-pooh'd java straight off due to the legacy of 'interpreted language'.

My advice would be to big up the JIT compilers by usingthe anology of the bytecode being the intermediate output in the compiler, and the final compile being on the target machine - hence able to optimise for the specific processor in question. Won't convince any console coders (fixed processor) but may sway a few PC programmers to the cause. Also point out that improving VMs would mean the code gets better optimised at a later point without you haveing to do any more work Smiley
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #8 - Posted 2004-12-01 14:43:35 »

Thanks. I've got some pretty convincing arguments lined up on the architectural and theoretical points, along similar lines. But I noticed I was short on specifics Sad.

malloc will be first against the wall when the revolution comes...
Offline oNyx

JGO Coder


Medals: 1


pixels! :x


« Reply #9 - Posted 2004-12-01 14:52:33 »

Quote
Security - due to impossibility of pointer/memory exploits/bugs


That one is a very strong argument. If you take a look at all those *serious* bugs n loop holes... 99.99% of em are just forgotten checks... or using a signed variable where it doesn't make much sense (the bmp exploit) etc.

弾幕 ☆ @mahonnaiseblog
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #10 - Posted 2004-12-01 15:09:38 »

Almost but not entirely irrelevant for client game code (one exception: network multiplayer games) (ok two exceptions: dynamic mods).

The real deal is all about productivity. More time writing game, less time chasing bugs, followed by loads more re-use later on, followed by really trivial refactoring even later.

The second deal is getting your software out on MacOS X for nothing.

Cas Smiley

Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #11 - Posted 2004-12-01 15:13:11 »

And as far as the platform goes - feck the platform, it's next to useless still as its market penetration is hopeless and broken. I've got my own platform now, a micro-VM and LWJGL. It's the bomb. I think you might want to mention that to these guys.

And I noticed your PM - would be glad to do an article on the micro-VM.

Cas Smiley

Offline CaptainJester

JGO Knight


Medals: 12
Projects: 2


Make it work; make it better.


« Reply #12 - Posted 2004-12-01 16:22:34 »

Quote
Security - due to impossibility of pointer/memory exploits/bugs


Somewhat along these lines:

Have you EVER received a Windows GPF programming in Java?(Don't know what the equivalent is on *nix/Mac)

Sometimes you can spend hours/days/weeks tracking down a GPF bug.  Especially if it is not your code.  You will not get a GPF/Blue screen of death in Java.

Offline Eliwood

Junior Member




Stencyl


« Reply #13 - Posted 2004-12-02 00:34:42 »

Quote

You will not get a GPF/Blue screen of death in Java.


Hehe, unfortunately, this can happen, but it's not our fault. It happened in the 1.4.1.x series with some buggy graphics code. It freaked out my video card and blue screened me every time until Sun patched it up.

Offline Giddy

Senior Newbie




Java games rock!


« Reply #14 - Posted 2004-12-02 15:32:02 »

Everytime you write a class in C++ you have to remember the 50 pieces of advice from Effective C++. (A great book)

They are all workarounds for flaws in C++, and most of them have been fixed in Java.


edit: messed up the BBCode
Offline TheAnalogKid

JGO Coder


Projects: 3



« Reply #15 - Posted 2004-12-06 12:55:27 »

from http://java.sun.com/developer/technicalArticles/Interviews/hamilton_qa2.html

Looking back at C++, there were a whole set of factors at work that make reading source code difficult: First, the C++ language itself became very complex. Many new ideas were added incrementally and, unfortunately, the seams show. Second, the C++ language consciously chose to emphasize "power" and "flexibility". That sounds nice initially, but, unfortunately, it also means that there is very little you can rely on and almost any simple program statement can have weird side effects. In C++ the statement "a = b;" must be approached with caution. Finally, the macro pre-processor reinforced the "power" aspect, but again at risks to comprehension.

Offline DaveLloyd

Junior Member




Making things happen fast with Java!


« Reply #16 - Posted 2004-12-06 12:58:42 »

My tuppen'th:

(1) Java is more than just conventional OO - it really does allow component-oriented programming where the contracts are enforced via interfaces or discovered via reflection. For games this is a real win as game engines often have a lot of different components that must interact cleanly.

(2) The great corollary of (1) is that it is sooo much easier to bolt on a third party component to a Java system and expect the result to be well behaved - in stark contrast to C/C++ where you can't even be sure all components are using the same malloc/free or where you get unexpected namespace pollution and you're no longer calling the function you first thought of.

(3) And following further on with bean-flavoured programming you get some big wins in the design stage as well as being able to drop new modules in at runtime. This usually eliminates the need for an auxiliary scripting language.

(4) The net result of all this is a platform with a truly astounding set of APIs (all cleanly documented with javadoc) - not just Sun's but all the FOSS contributions as well. I'm pulling together components from all over the place for my projects. So much effort saved, it's unimaginable to have done it any other way.

(5) The final argument on performance is JNI which is a really good way of packaging up high-performance C++ code which can focus on raw number crunching using available vectorisation etc, but where all the high level structure is kept in Java. Tools like SWIG make this pretty damn easy. (I also like the discipline that goes with separating out the performance specific kernel of the algorithms from the data structures.)

Dave
----
Fuze3D: http://www.shortfuze.co.uk/shortfuze/template/Fuze3D,Index.vm
Machinimascope: http://www.shortfuze.co.uk/shortfuze/template/Machinima,Engine.vm

Offline TheAnalogKid

JGO Coder


Projects: 3



« Reply #17 - Posted 2004-12-06 13:14:17 »

I totally agree with all of your arguments but with point 5, JNI calls overhead has to be considered since it's a significant performance hit. About that, are there solutions in the future to eliminate this problem since it prevents Java to be as fast as C in games in most cases?

Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #18 - Posted 2004-12-06 14:19:40 »

"significant performance hit" sounds like a mantra to me... our own testing shows that it is actually so small it can't even be measured reliably.

Cas Smiley

Offline TheAnalogKid

JGO Coder


Projects: 3



« Reply #19 - Posted 2004-12-06 14:34:32 »

Then how do you explain the performance hit encountered in Jake in there previous release? They clearly said that they had a significant overhead due to there numerous JNI calls.

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #20 - Posted 2004-12-06 15:51:16 »

Quote
it really does allow component-oriented programming where the contracts are enforced via interfaces or discovered via reflection.


Thanks. That's a great one, but I'd not really been thinking of it as a low-level practical thing - more as a platform thing - yet it *is* a low-level concrete thing.

Ditto your other good points.

Quote

all cleanly documented with javadoc


Sad but true, I was in danger of forgetting to mention javadoc. This would be unforgivable. C++ colleagues still strut around saying "yeah, I use doxygen for everything" as if it makes them a cut above the rest of the C++ developers.

Show doxygen to a typical java programmer and watch them die in horror.

Or, if you're old enough, go back through some old API docs and wonder how you retained your sanity with such horrendous documentation. I found myself stuggling to blieve that I really coded against such vaguely-defined ****!

Quote

(5) The final argument on performance is JNI


This one is bothering me quite seriously. Games devs *really* care about speed of access to memory. JNI still has significant per-call overheads, doesn't it?

I belive this is not a problem for most games dev, since you ought to be batching things to pipelines (hardware, etc) anyway if you care about performance, given the way modern hardware tends to have high-initial-hit-latency, low-subsequent-hit-latency.

But...what is the total overhead for using direct native BB's for communicating between java and C? I need to revise this (it's stuff I researched, evaluated against my own work, then didn't bother to remember the details of, only the conclusions that pertained to the work I was doing at the time  Embarrassed)

malloc will be first against the wall when the revolution comes...
Offline DaveLloyd

Junior Member




Making things happen fast with Java!


« Reply #21 - Posted 2004-12-06 16:09:27 »

blahblahblahh wrote:
Quote

Quote:
(5) The final argument on performance is JNI

This one is bothering me quite seriously. Games devs *really* care about speed of access to memory. JNI still has significant per-call overheads, doesn't it?


I think you put your finger on it with the per-call overhead. Whatever language you use, the real high performance kernel should have its data batched up and run in very tight loops - otherwise you cannot sensibly superscalar.

An obvious example is with OpenGL where the goal is to push the bulk of the work further down the pipeline (and hopefully stay on the graphics hardware) so JNI call overheads are lost in the noise.

Or ODE (a rather good physics engine in C) where the kernel is essentially a wopping great matrix SVD (or approximation thereof). Again I've never noticed any performance loss just because I'm setting things up from Java but then running a sim step in C all via JNI.

Heck if you're writing top-end physics sims you'll probably still end up using hand-crafted BLAS libraries to get the max out rather than write it in Fortran (and Fortran generally optimises far better than C/C++).

Commercial engines these days push more and more of the basic graphics/physics and other raw computing down into middleware layers (Renderware, Gamebryo, Lithtech, ...) so that games programmers can focus on the game not on the engine.

(Aside: has anyone got any good BLAS bindings for Java?)

PS: You are so right about the days before Javadoc!!

Offline the2bears

Senior Member


Projects: 2


Little Bear: Code Fu!


« Reply #22 - Posted 2004-12-06 18:23:52 »

This seems obvious after thinking about it:

Why would M$ offer C# (read: Java clone) as their forward-moving replacement for C++?  Now, I'm no fan of Redmond but they must have done some research and they must have good reasons for essentially moving a huge development community to a Java clone.

Though they've made lots of mistakes before:)

Bill

the2bears - the indie shmup blog
Offline TheAnalogKid

JGO Coder


Projects: 3



« Reply #23 - Posted 2004-12-06 19:22:09 »

One reason (among others) might be that Java is a very popular ($$$) language/platform.

Offline DaveLloyd

Junior Member




Making things happen fast with Java!


« Reply #24 - Posted 2004-12-07 09:09:33 »

Another thought on Java evangelisation for you: tools. With NetBeans and Eclipse you get code completion and javadoc lookup with live error checking while you're writing code. You just can't do this effectively in C/C++ because even if you got over the hurdles presented by the language, you'd still have the preprocessor and the archaic header structure to contend with. You also get ANT instead of make, automake, autoheader, autoconf and configure...

[Edit] Nearly forget - and then throw in refactoring for real C21 programming!

Dave

Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #25 - Posted 2004-12-07 10:16:41 »

Ant's not really any better than anything else.

Cas Smiley

Offline phazer

Junior Member




Come get some


« Reply #26 - Posted 2004-12-07 10:51:22 »

I would say Ant is much better than make.

Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #27 - Posted 2004-12-07 12:02:33 »

Probably, but that's not saying much, as make is beyond bad, it's almost like it was designed by a malevolent entity.

Cas Smiley

Offline DaveLloyd

Junior Member




Making things happen fast with Java!


« Reply #28 - Posted 2004-12-07 12:42:29 »

Quote
it's almost like it was designed by a malevolent entity.


Almost. Make was designed by a student during a summer job. Several years later now working in the industry he was horrified to discover that make was now a 'standard' tool complete will all of his bugs carefully documented - most infamously the use of tabs rather than any whitespace.
(I have the full story from comp.compilers somewhere but can't find it on google.)

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #29 - Posted 2004-12-07 15:23:54 »

Quote
Probably, but that's not saying much, as make is beyond bad, it's almost like it was designed by a malevolent entity.


100% agree. Except...I sometimes wonder if it was really invented by some malicious deity so that ANT users would have something to point to and say: "...it's so much better than Make". /me ducks and runs for cover

"make was a really good project for a college student [to implement] 20 years ago."
-- Tim Leonard, Intel Massachusetts Microprocessor Design Center
( http://vestasys.org/why-vesta.html )

malloc will be first against the wall when the revolution comes...
Pages: [1] 2 3 4
  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.

xsi3rr4x (24 views)
2014-04-15 18:08:23

BurntPizza (19 views)
2014-04-15 03:46:01

UprightPath (33 views)
2014-04-14 17:39:50

UprightPath (17 views)
2014-04-14 17:35:47

Porlus (33 views)
2014-04-14 15:48:38

tom_mai78101 (59 views)
2014-04-10 04:04:31

BurntPizza (117 views)
2014-04-08 23:06:04

tom_mai78101 (217 views)
2014-04-05 13:34:39

trollwarrior1 (184 views)
2014-04-04 12:06:45

CJLetsGame (191 views)
2014-04-01 02:16:10
List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:05:20
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!