2006/10/17, Mikhail Fursov <[EMAIL PROTECTED]>:
On 10/17/06, Pavel Pervov <[EMAIL PROTECTED]> wrote: > > Mikhail, > > EM, as I see it, is interchangeable component. Should we require defining > " > java.compiler" for interpreted mode from all EMs?EM does not know the semantic of options it adds to the system properties. See client.emconf file to see how options are passed to JIT and EM knows nothing about their meaning. EM configuration is very convenient place to put all options that affect the current execution mode. And if you want to have meaningful "java.compiler" option a EM configuration file is the only place. My idea is to initialize "java.compiler" to some default value ("none"?) in > VM, and then overwrite it with actual value wherever actual information is > available (in EM in our case). EM does not override system options that are already set. Such a behaviour allows to make cmd-line option to have higher priority then those in EM configuration file. I would vote to keep the behaviour.
This behaviour is fairly reasonable and I agree we should keep it. To solve Pavel's concerns, VM could set this property after EM init if needed. Though this might feel like a hack, this is a matter of when and how VM initializes Java properties (aka "public" in a recent thread) with default values. Seemingly default Java properties are not significant for components loading and should be set after all components init, no overriding.
And one question follows: what if we have three different JITs defined in EM > configuration file? :) What value "java.compiler" will contain in this > case? client.emconf already has 3 JITS configured inside. The common name for the configuration is 'client mode' -- Mikhail Fursov
--------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
