22 May
2010
22 May
'10
1:06 p.m.
On Fri, May 21, 2010 at 11:01:44PM +0200, Arnout Engelen wrote:
i doubt it can.
On Fri, May 21, 2010 at 11:42:13AM -0700, Niels Mayer
wrote:
that statement about the pricing model was a quote from the java RTS
FAQ.
opensourcing something of that price would be a bit dumb :)
On Fri, May 21, 2010 at 8:33 AM, torbenh
<torbenh(a)gmx.de> wrote:
Well, indeed a big part of the Sun JVM has been open-sourced under the name
'OpenJDK'. That does not mean the Java RTS is open-sourced - I'm pretty
sure it isn't. But I'm not even sure RTS provides the kind of RT we're
looking
for in the LAD world. On Thu, May 20, 2010 at 10:37:30AM -0700, Niels
Mayer wrote:
Java is open source. "hard realtime" often precludes the use
of Garbage collectors. Of
course Java has RT garbage collectors available:
http://java.sun.com/developer/technicalArticles/Programming/rt_pt2/
Java RTS has an innovative pricing model that starts at $6500 per
socket/CPU for development or internal deployment.
well... thanks :S There are people using embedded and sometimes RT
java,
to varying degrees of effectiveness, in all sorts of everyday devices, like
your cable company-provided DVR and set top box (which I've worked on) and
sometimes even your credit card verification devices (which i've also
worked on).
What kind of 'real time' are we talking about here, exactly? I think the
definition relevant for the LAD world is basically: "it can be guaranteed that
no non-RT-safe calls (like anything that may block, including malloc) will
take place while handling the JACK process() callback".
Can OpenJDK provide that guarantee? This never has been quite clear to me.
The JACK thread can be run at a higher priority than the other Java process
threads (including the GC thread), so as long as there's no non-RT-safe calls
I think we should be safe from being interrupted by the GC (right?). Probably
the jack process() callback would call some Java code though JNI (like JJack[1]
does). *If* JNI doesn't do anything non-RT-safe, and *if* it is possible to
avoid doing non-RT-safe stuff at the Java side (by adhering to some rules in
your Java code, much like you'll have to do when writing C code), it'd be
possible to write RT-safe code in Java.
there is another if:
*if* the jvm can guarantee me that it will only execute jit compiled
code in my process callback. without such a guarantee the whole jit
compiler is irelevant, since we are only interested in maximum
execution times.
It sounds possible, but there are some big 'ifs' there.
Of course the more interesting features of Java would probably still be
forbidden to be used in the JACK process() callback.
I tend to disagree: actually I find changing/updating/adapting things in a
dynamic language is more frustrating and tedious because there's no compiler
to tell me which bits I missed. But perhaps we shouldn't rehash the old static
vs dynamic typing debate here ;).
no we shouldnt.
thats pretty much the point i was referring to.
for just quick prototypes dynamic languages are naturally better.
--
torben Hohn
i dont
understand... are you seriously arguing that dynamic languages
are always better ?
No! (...) However programming in those languages, prototyping UI's in those
languages is really tedious. Changing and updating and adapting applications
for new uses is very frustrating in those environments.