Re: Properties

[Jeff Sturm <jsturm@sigma6.com>]

Andrew Haley wrote:
> > > Tom wrote:
> > > > If the class loader could load .so's, then we could just use gij for
> > > > this.
> > >
> > > Cool - yes, exactly!  We could make this work.
> 
> Unless I am missing some important point, this is way overkill.  If
> it's just a question of passing an attribute into an executable,
> surely there's no reason environment variables shouldn't be used; it's
> just a question of setting the environment variable and then launching
> the executable.

So far we have three proposals:

  1) Add a properties section to the ELF image
  2) Command-line arguments to gij, modify classloader
     to load compiled classes
  3) Environment variables

Each of these are useful in some situations.  There are times I want to
distribute a class (or executable) and it's a nuisance to tell users how
to run it (e.g. what env vars to set) or include a wrapper script. 
That's where 1) would be really handy.

Compatibility with existing tools is also a good goal.  The JDK does 2),
but doesn't have to deal with compiled classes.

Environment variables are sometimes a good choice.  I use a number of
wrapper scripts that read the environment and build a `java' command
line.  If I could link native executables that can also read properties
from the envionment, I may be able to do away with those scripts.

Some other java compilers (Toba, at least) also do 3).

I see no reason gcj couldn't support all three, even if environment
support were left as a configure-time option.

> Okay, I admit this won't work on the benighted systems where the
> environment really is global.

Are there really any systems that work that way?

-- 
Jeff Sturm
jsturm@sigma6.com