Re-writing JBLS

[Sidoh]

Ok, I just re-read the relevant posts, and I retract my question in favor of a new one: Why the f*ck would you use XML for a list of properties? Use a properties file!

Why does it matter?  If you can bind a properties file to a class for easier access with a clearer interface, then I'm not seeing a noteworthy advantage one has over the other.  Maybe there's less overhead in parsing and deploying it, but why does that matter if you're going to load it into memory once on startup?

I try to not overuse XML, but this seems like a very appropriate use for it.

[Camel]

Because java.util.Properties is a standard class provided by the JRE.

[Sidoh]

Because java.util.Properties is a standard class provided by the JRE.

Can you bind a properties file to a Java class?  Like I said, that makes the interface a lot cleaner and easier to access.

[Ender]

Because java.util.Properties is a standard class provided by the JRE.

Can you bind a properties file to a Java class?  Like I said, that makes the interface a lot cleaner and easier to access.

yes.

[Ender]

I agree with Camel. No need to overcomplicate it with XML, especially a non-standard package like xmlbeans. Properties file is simpler and sufficient.

[Sidoh]

I agree with Camel. No need to overcomplicate it with XML, especially a non-standard package like xmlbeans. Properties file is simpler and sufficient.

If you can bind it to a class, then I'd definitely go with that.  The XML approach has the advantage of having a schema describing all of the settings, making it a bit more transportable, but since it's just a local settings copy, it doesn't matter.

For reference, Ender, you don't have to include any xmlbeans libraries when you ship your binaries.  It uses a schema compiler to turn a xsd into some java classes that describes the type(s) you define, which you then use in your code and that's all there is to it.