Properties

[Jeff Sturm]

On Sun, 12 Sep 1999, Anthony Green wrote:
> 	What is really needed is some way to specify default
> `Properties' on a per-application basis.  Here's an idea that involves
> modifying binaries - not a very popular idea, so I thought I'd run it
> by folks for comment.
> 
> 	The basic idea is to allow for binding property files (or some
> representation of them) to fully linked executables.  This proposal
> works for systems that support arbitrarily named sections (like ELF).

That would work well for certain problems, like setting properties for
applications that will be distributed to remote machines, especially
targets that don't support environment variables or anything similar
(embedded targets, perhaps?)

However, binding properties to an application isn't always a reasonable
thing to do.  For instance, in a multiuser system each user running
some Java application may need to specify properties unique to themselves.
Environment variables work well for that, since they are inherited across
processes.

Here's one realistic example: I use a set of small Java programs, based on
JDBC, to manage my database systems.  They let me execute SQL batch
commands, import/export data, etc. from a uniform interface independent of
database vendor, so if I migrate a system from MSSQL to Oracle for
instance I don't have to switch all my scripts from isql to sqlplus.  I
use four Java properties:

jdbc.driver
jdbc.url
jdbc.user
jdbc.password

the scripts that launch the java classes read these settings from a
property file, named as an environment variable.

I'd like to try compiling these with gcj, but, among other problems I'm
undecided how I'd pass in the properties at program launch.  Binding them
to an executable isn't helpful since I frequently have several instances
of a class running simultaneously, with different properties.
(Simply copying the executable is an inefficient use of disk and VM.)

Perhaps we could also have a utility that would bootstrap libgcj, set
properties and GC parameters, then dynamically load an application
compiled by gcj as a shared object, find and execute the main() class.
Maybe call it `gcjrun':

gcjrun -Dsomeproperty=somevalue -mx32m myapp.so MyApplication

That's more-or-less equivalent to what the `java' interpreter does now.
By combining this with the capability of binding properties into an
executable, we could have the best of both worlds...

Thoughts?

Jeff