On 14/09/2012 06:25, Mandy Chung wrote:
:
I'm not sure I fully understand. Are there no other cases where
packages are split across modules?
Our goal is to remove all split packages.
Yes, as Mandy said, we want to keep things as clean as possible and that
means aligning the modules on package boundaries. So far this has worked
out quite well in our prototyping to date. By far the most problematic
area in the Java SE APIs java.beans, it's just too tied into Applets,
AWT, Swing, even XML. It's unfortunate that JMX uses it, particularly
for use-cases such as small environments where one should be able
install a "management" module to be able to remotely monitor or manage
applications on the device. If JMX requires JavaBeans then it means
needing to install a lot of things that might not make sense in that
environment.
At this point I think our only remaining hard dependency on JavaBeans
from JMX is the ConstructorProperties annotation, you might remember we
put in a helper to identify getter methods when the beans Introspector
is not available. For the JMX Remote API then I think specification
changes will eventually be required to allow the RMI-IIOP transport be
optional (this is something you will probably have an opinion on). This
is another cases where we have a split-package issue, this time due to
the CORBA stub/tie classes that are in javax.management.remote.rmi
(something that the IDL Mapping specification requires if I remember
correctly).
My main observation on ConstructorProperties is that any code that uses
it will require the module containing ConstructorProperties to be
present when compiling that code. If the module declaration is setup so
that the module containing the annotation type is required to be present
at runtime then I think we are okay and Mandy's changes amount to a
no-op. If the application is not using the annotation then it doesn't
matter if ConstructorProperties is present or not and I think the
proposed changes are benign. So my view is that the onus on anyone using
ConstructorProperties needs to ensure that they have their module
declaration right, otherwise their code will not compile or run.
Mandy - I've looked at webrev.01 and the changes look okay to me. The
only thing is that the value method may throw a RuntimeException or
Error and it would be good to propagate those rather than throwing an
AssertionError.
-Alan.
