Why Java, not C++?

General Discussions
#21

[quote] it really does allow component-oriented programming where the contracts are enforced via interfaces or discovered via reflection.
[/quote]
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.

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 ****!

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 :-[)

#22

blahblahblahh wrote:

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!!

#23

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

#24

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

#25

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

#26

Ant’s not really any better than anything else.

Cas :slight_smile:

#27

I would say Ant is much better than make.

#28

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

Cas :slight_smile:

#29

[quote]it’s almost like it was designed by a malevolent entity.
[/quote]
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.)

#30

[quote]Probably, but that’s not saying much, as make is beyond bad, it’s almost like it was designed by a malevolent entity.
[/quote]
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 )

#31

[quote]Why would M$ offer C# (read: Java clone) as their forward-moving replacement for C++?
[/quote]
+1 interesting angle.

Anyone got any good references on MS’s own BS about why C++ devs should “grin and bear it” whilst MS are forcing them to move to C#?

#32

[quote]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.configure…
[/quote]
Interestingly, “there’s no way realistically we can do without visual studio” , “it’s the de facto standard - the standard file format for exchanging projects, the standard for teams to work on, etc” and “I need a debugger at least as good as VS’s” are big noisy complaints in the games devs I’ve spoken to.

Now, it’s been a loooong time since I used VS, and they’ve moved on a version or three since then, so I’m not really able to comment on how eclipse etc match up to VS. But it seems the belief is that C++ is better than java for tools at the moment.

?

#33

blahx3 wrote:

Interesting footnote then: Eclipse is rapidly becoming the defacto ide of choice for embedded C use particularly in the embedded linux/eCoS/etc world. For a Java ide it has really good C/C++ support - I’ve used it myself for embedded work.

#34

Vis studio is still not a patch on eclipse :wink:

#35

On the other hand, Eclipse is still a dog-slow memory hog.

Cas :slight_smile:

#36

…which is irrelevant on any serious development machine, surely?

Chuck in a gig and it’ll run fine. What’s that, 80 quid?

#37

Not irrelevant at all. I’ve got a gig and it’s still a dog slow memory hog. On a 3GHz HT machine. By my reckoning it’s using twice the memory it should do and running at about a tenth of the speed it should.

Cas :slight_smile:

#38

Strange - I run Eclipse on a little old 600Mhz laptop with 256Mb and it runs fine - even with a source tree of over 10,000 C and Java files.

Maybe it could be faster and smaller, but it is more than fast enough for me.

NetBeans is more of a hog and doesn’t run so well on my laptop but it is fine on the desktop.

Don’t forget with Java, comparing Eclipse/NetBeans with Vis Studio can give you a false result as Java IDEs ‘understand’ the source code in far greater depth than a bit of basic pretty printing. All this code structure takes memory - lots more than the raw characters.

#39

DaveLloyd netbeans is swing based while eclipse is SWT based. Thats prolly the difference

#40

Middy wrote:

[quote] DaveLloyd netbeans is swing based while eclipse is SWT based
[/quote]
I’m not convinced. Swing is often held up as the culprit but for what I’m doing the GUI response is not the issue. I suspect it’s more that NetBeans is more deeply structured than Eclipse.

Incidentally, for all NetBeans is a bit of a hog, I still find the more useful of the two.