Looks good for the most part. Two things I'd like to see: 1. Put the descriptions in javadocs for each field. API docs are going to be more popular for browsing the full set of configuration options. Does the description/toString ever get used in a meaningful way? 2. Do away with the static-ness of the fields. Can we get away with them being instance variables and a Properties-instance-per-runtime? I'd rather see that approach with a fallback to a statically loaded value. That would allow different runtimes in the same JVM to be configured differently, either through updating system properties or via an API that gives access to the Properties object (that was the original intent for RubyInstanceConfig).
One final mention -- naming the class Properties clashes with java.util.Properties too easily for me. /Nick On Wed, Oct 26, 2011 at 10:15 AM, Charles Oliver Nutter <head...@headius.com> wrote: > I finally tackled the cleanup and centralization of all property-based > JRuby configs. They were sprinkled all over as simple property loads, > with many of them left undocumented and some others completely stale > and unused. The new structure centralizes all properties in one place > along with their valid options, default values, and descriptions. > > The commit is pushed to my jruby fork here: > https://github.com/headius/jruby/commit/02732c2725271eafb021e78dfb793934d2e85fee > > I am requesting more eyes on it to make sure I did not botch the > migration...for example, copying over the various default values, > wiring up the new property logic where we had lookups before, and so > on. > > I'm also interested in suggestions for way to improve this layout. I > looked a at few configuration libraries for JVM and they were all > either too complex or not what I needed. Hand-rolling this seemed like > the right way to go. > > - Charlie > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
