• Messages sorted by: [ date ][ thread ][ subject ][ author ] [ Next ]
• [ Previous ] Next in thread: Mark S. Miller

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 running.

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?

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 compilers?

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 increments?

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

Thanks alot.

Jonathan

[ Next ]
• [ Previous ] Next in thread: Mark S. Miller