On Nov 4, 12:41 pm, boroph...@gmail.com wrote:

Yes.

Yes, at startup.

Current? Well, there is e.g. a Quake 2 engine port to Java
http://bytonic.de/html/jake2.html

There are other game engines, too. E.g. http://www.jmonkeyengine.com/

And there are other types of graphic intensive applications, too. CAD
systems have been written in Java, so have GIS systems. People do
complex simulations in Java and all kinds of computational intensive
stuff.

For what? Games? Game users might be used to all kinds of long startup
times, so Java's typical long startup times might not be an issue.
Game users are also used to be able to use a number of HID devices
(joysticks, wheels). There is a total lack of out-of-the-box support
in Java for such devices. There are third-party libraries to overcome
this. There is also an almost total lack of out-of-the-box integration
into advanced sound engines. Java-sound does not cover all details.
There are maybe third-party libraries to fix this, I am not aware of
any. There is at best mediocre media support (video playing, MP3
playing). The Java media framework has been neglected for years.

What is really bad in Java is desktop integration. Interaction with
native installation management or package management does not exist.
All things which are closer to the system are bad. Dealing with
removable media in general is bad, e.g. figuring out if a CD or DVD is
in a drive can't be done with Java alone. Dealing with all kinds of
system services is bad. Typical desktop I/O (serial, USB, parallel
ports, Firewire) is not or badly supported.

There is only one compelling technical reason to do a desktop
application in Java. When you really, really, really badly, need the
cross-platform features of Java so your application runs on multiple
platforms. The price you will have to pay for this is that the
application will look and behave slightly alien on all supported
platforms. And some things won't work at all.

It has advantages and disadvantages. You can study the details for
ages. But in short it usually doesn't hurt and is in general "better",
unless you mess up things.

borophyll@gmail.com schrieb:

I would say problematic is that for example OpenGL needs native
librarys.. calling these via jni has an overhead that will kill your
performance.

The other thing which I have seen is that java may have caught up with
performance.. though a little overhead stays .. specially if you not
program c++ but hack c++ you can gain some bits of performance that may
be relevant for one of the latest games to even run on a machine (like
doing bitflipping in a pointer to traverse a list of vertices really fast).

Java is a great language but it doesn't fit for everything. Thinking
Java and its features like the runtime optimization will fix everything
for you in speed that the additional security like typechecking or
nullpointer checking costs you is I think hybris.

You have the option of native compiled code with Jet.  See
http://mindprod.com/jgloss/benchmark.html

Jet produces BETTER code than hand assembly.

There is VolatileImage which gives you ability to rapidly bitblt
inside the regen.

I have not played with Java 3D.

In the old days you poked the hardware directly with machine code.  I
presume today you have device drivers to access the clever parallel
processing hardware in the video cards.  The key would be how
impedance matched the Java API is to the device driver API on any
given platform.  Java is always constrained my the least common
denominator principle.  In general, it can't use features of a
platform unless all platforms support it.

In the extreme short-term (i.e., in the first few minutes), Java is
going to have noticeable impact: one comparison metric gives it about
1.2-1.3 times native code (after taking startup into account). Over
longer periods of time--especially if the server VM is used--Java
performance is near, at, or better than native compiled code.

In most cases, yes. Part of the problem is that manual management is
manual and people are not quite as good at profiling memory as computers
are. In addition, garbage collection can more easily benefit from
parallel execution, a bonus in the coming days of multi-core CPUs and
other parallelization techniques.

True in many cases, yes.

That's one reason that Java is currently far more popular for long-running
server applications than it is for browser applets or desktop apps. Startup
time isn't such a big deal when the app is rarely killed and restarted.

I've quite a bit of experience in cross-language development (see my .sig),
and in my experience the cost of crossing the language barrier tends to be
pretty high. That doesn't make Java unsuitable for high-performance 3D apps,
it just means you need to carefully think about and manage how your Java
code calls the low-level 3D rendering functions.

It's easier than some manual schemes, and about on par with others. It's
definitely easier than old-school malloc()/free(). But, there are "semi-
manual" techniques such as those used in C++ (stack-based objects and STL
collections) or Objective-C (autorelease pools and design patterns that
support them) that are also much easier than the old-school approach.

Sun likes to pretend that the old-school approach is the only possible
alternative to Java, so as to make Java look better in comparison. The
truth isn't as black-and-white as that.

sherm--

On Nov 4, 9:41 pm, boroph...@gmail.com wrote:

Thanks all for the responses.  The feeling I am getting is that Java
is not very suitable for apps where it needs to interact quite closely
with the machine (such as graphics, device I/O) because of large
runtime overhead of JNI.  Can this overhead be circumvented by
compiling Java to native code?  Or is it unavoidable for some reason..

Does Java suffer from GC pauses anymore(on UP systems), or are they a
thing of the past?

<OT> I am looking for a language that is as close to the metal as C++,
yet has garbage collection, which I think is a better idea than manual
mm.  Any ideas? </OT>