On 9/14/2009 3:53 PM Christopher Deckers wrote:
I understand that it is cached. But conceptually, I don't see why
there would be a problem of updating that cached value (propagating
the change) rather than imposing users to add this property to the
JNLP.
At least, would it be possible that the system property be set to
"true" or "false" once the value was decided and cached rather than
staying null? That way, I would know that the property caching
happened and take appropriate action (continue, or message to the user
about setting that property, etc.)
I doubt if either is possible technically: the System.get/setProperty()
API does not (and should not) know anything about AWT and its
properties. Therefore, unless the property is explicitly set, the getter
returns null according to its specification. On the other hand, the
setter doesn't know where this exact property is cached, and we do not
get notified when someone sets a property, and hence are unable to
update the cached value.
I can understand that eventually the whole issue would vanish when
HW/LW mixing works properly (revalidation et al), but there does not
seem to be much activity on that front at the moment.
I guess only patience might help us. The 6u16 is probably going to be
able to work with the property correctly. And currently we don't have an
intention of introducing new APIs that might become unnecessary one day
(which is why, btw, the property is at sun.awt., not at java.awt.)
--
best regards,
Anthony
