"Jonathan S. Shapiro" wrote:
> One of the top things on my to-do list is a configuration management system
> that actually works (as distinct from CVS). The design of this has now
> pretty well emerged, and it shouldn't take long to get a first version
Grrr. CVS isn't a configuration management system, so what's the point of complaining it doesn't work?
> I am debating doing the implementation in Java for reasons of portability
> and garbage collection, and since all of you have more experience with Java
> runtimes than I do, I would appreciate your thoughts. Here are my concerns
> about using Java for this application. Perhaps you will be able to shed
> light on how realistic these concerns are.
> 1. Portability
> Until the release of the IBM JDK, there has not been a sufficiently reliable
> JDK for linux/x86 (or any other open source OS). The kaffe effort doesn't
> appear to have a consistent, easily installed set of libraries. I am
> therefore concerned that if I do this in Java I will wind up in difficulty
> when the time comes to run it on top of EROS. Realistically, is there a
> fully open-source Java implementation (including libraries) that can be
> relied on at this point?
I'm told the JDKs available for Linux are fine. Certainly they're widely used for servlet stuff by Apache types. I also use the FreeBSD JDK and that's fine, too.
> In particular, can Swing be redistributed (in bytecode form) on a non-Sun
> JDK, and is the JDK support out there on the open-source Java
> implementations good enough to support it?
> 2. Startup Time
> Since the first iteration (and probably the most commonly used version for
> the forseeable future) of this program will be a command-line tool, I am
> concerned about the startup-time cost of JIT compilation. My experience is
> that it is quite slow, and in the "start run exit" model of program you pay
> this cost again and again.
> Does anyone have an opinion on whether it is "fast enough"?
> Since this application doesn't require (indeed, does not *want*) dynamic
> class loading, does anyone have experience to share with the bytecode->C
No, but I did hear that someone is doing the opposite: a C++->bytecode compiler (not sure if its Java bytecode, though). Pretty cool, huh?
> 3. Heap image size
> The required heap size for this application is a function of the size of the
> code base. It is likely that for any given max heap size some code base will
> overflow the heap. Why the hell did the bozos at Sun set a max heap size,
> and how does one get the runtime to simply grow the heap in reasonable
> In the short term, I may decide to go with C for portability reasons. I'm
> hoping someone can tell me a story to the effect that I do not need to.
> Partly, I just hate to ask people to download 8 megabytes of Java runtime
> just to run this application.
> Eventually, there will want to be GUI versions of this tool, and the
> portability of Java is very attractive. I just want to understand how it's
> going to bite me down the road before placing my own bets...
I think its a pretty safe bet, simply because of the amount of momentum behind it.