On Aug 30, 2012, at 6:05 PM, Fred Gleason <[email protected]> wrote:
> On Aug 30, 2012, at 18:11 08, Dan Mills wrote: > >> I don't know if it is just me (And I have not worked on Riv for a >> while), but EVERY major java application (Possibly except Chrome, I have >> not used it much) I have ever run across has been a right pain to >> install, xml infested, massive, slow to start up, and generally slightly >> crash happy, maybe it just comes with the "Enterprise" label or >> something..... > > This has been my experience as well, with the addition of extreme sensitivity > to the precise version of JRE being used, to the point where I've even had to > *downgrade* it to get a working setup. Not a particularly impressive showing > for a system that purports to deliver 'write once, run anywhere' > functionality. This was several years ago however, so perhaps things have > improved since then. Many people seem to have experience with JavaEE servers as their "Java" experience. There, too many large scale, mismanaged resources and "code-by-tools" creates a lot of problems. I've been using JavaSE for a data brokering system that I wrote from scratch, deployed in the petroleum products market, for the past decade. My experience has been that I haven't had to worry about Java versions, except for some point releases with actual bugs. I understand the GC at the wrong moment won't be good. That's why I'd prefer to leave the play out system in a native C/C++ application framework. It could still load the JVM in that process, and call out to it, if that was a useful part of the system. GC in that JVM would happen on threads independent of the play out mechanisms. > >> I mean eclipse, really, come back emacs (or vim) all is forgiven, and a >> glorified text editor really should not crash! > > I'm there, baby! Using emacs v23.1 (and yes, it's available for OS X as > well). :) I'm a VI user and I am not always excited about IDEs. The Netbeans IDE, is much preferable to Eclipse for me, because it seems to be more like an editor with a navigation tree, instead of some kinds of systems engineering nightmare. >> Now as it happens the log playback logic is somewhat too tightly tied to >> the gui in rivendell, and could very usefully be abstracted into a >> logplayd process (Or three), but remember that even this is fairly hard >> realtime if you want the transitions to sound smooth. GC at the wrong >> time there would be a dead air situation, possibly making the next >> transition also miss its timing. > > This is the real crux of the matter, I think. Multimedia systems that demand > realtime performance remain the almost exclusive province of C/C++. > Unpredictable GC in languages with automatic memory management is one of the > major reasons for that. As I said above. I'd prefer to leave the play out system outside of the realm of a Java implementation. That would not be a great thing without some careful engineering. Don't get excited or too argumentative, because I'm just thinking out loud here. Gregg > Cheers! > > > |-------------------------------------------------------------------------| > | Frederick F. Gleason, Jr. | Chief Developer | > | | Paravel Systems | > |-------------------------------------------------------------------------| > | The UNIX philosophy basically involves giving you enough rope to hang | > | yourself. And then a couple of feet more, just to be sure. | > | -- Anonymous | > |-------------------------------------------------------------------------| > > _______________________________________________ > Rivendell-dev mailing list > [email protected] > http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev _______________________________________________ Rivendell-dev mailing list [email protected] http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
