Regressions from gcj 4.2 to 4.3 involving XML

Mario Torre neugens@limasoftware.net
Fri Mar 9 21:37:00 GMT 2007


Il giorno ven, 09/03/2007 alle 13.30 -0700, Tom Tromey ha scritto:
> >>>>> "Mario" == Mario Torre <neugens@limasoftware.net> writes:
> ated service files.
> 
> That said, I think we should probably not use this approach to
> configure Classpath itself, at least not for areas where the user
> might need to be able to override the default.  In those situations,
> maybe compiling in a default system property would be better.

Yeah, I agree about that. FWIW, the preferences look at a system
property first, that go to look the default in the service and then
revert to the hardcoded class.

For classes that can be configured at runtime, like the desktop api, I
have just created two options, a system property (for each
action/method) and a preference (same as the system property). The
system property has precedence always, so a user can ovverride the
default from the command line. The preference has precedence only over
the default (that in that case depends on the detected desktop, for
other things can be hardcoded).

This has the nice side effect that packagers/users can override the
settings at runtime. This approach can be a security risk in some cases,
so we should pay attention for any given case.

The problem I see here, though, is an "organisation" problem (I like the
english sound, with the 's'. The american one is similar to the
italian :) :  keep track of all the preferences (and then on the system
properties) instead to have them just forgotten in the .java files.

About that, I'm working on a tool that let, at least for now, to
configure the preferences described in a config file (xml). This file
can be generated by the build system or just be there for use.

For now just the preferences are supported (and only for the Desktop
API, because it uses the Preferences API), so that could need some code
changes. Runtime behaviour by mean of system properties is my goal,
though.

If this is a reasonable approach, I would suggest to follow that when
writing new classes. All the options should be documented in some
README.options or README.configurations file too (I've started this too,
but I'm running out of time!).

What do you think?

> Tom

Ciao!
Mario
-- 
Lima Software - http://www.limasoftware.net/
GNU Classpath Developer - http://www.classpath.org/
Jabber: neugens@jabber.org - Profile: http://www.gtalkprofile.com/profile/9661.html
pgp key: http://subkeys.pgp.net/
PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Please, support open standards:
http://opendocumentfellowship.org/petition/
http://www.nosoftwarepatents.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Questa ? una parte del messaggio	firmata digitalmente
URL: <http://gcc.gnu.org/pipermail/java/attachments/20070309/cdd6a831/attachment.sig>


More information about the Java mailing list