Eamonn,
I filed a RFE that the serviceability team can follow up your suggestion:
7199353: Allow ConstructorProperties annotation from any package
Alan - I modified the fix to throw InternalError instead of AssertionError.
Thanks for both of your review and I'll only list alanb in the
Reviewed-by list
per Eamonn's request.
Thanks
Mandy
On 9/16/2012 7:07 PM, Eamonn McManus wrote:
OK, well if you've managed to align modules on package boundaries
everywhere else then congratulations, because that can't have been
easy! Certainly a relatively minor feature like ConstructorProperties
shouldn't be the only obstacle to completing that split. If we had
known that this question would arise when we were defining
ConstructorProperties I feel sure we would have put it somewhere else,
perhaps a new package on its own like java.beans.annotations, or
perhaps an existing package like javax.annotation (though I think the
process for that one would have been very hard).
I do feel that if, at the end of the exercise, it turns out that there
is a nontrivial number of other split packages then
ConstructorProperties should be put back the way it was. And,
regardless, a JMX spec change allowing ConstructorProperties
annotations from any package, as I suggested earlier, would clarify
the situation for users. As it is, they are likely to want to avoid
ConstructorProperties just in case their code might end up on a
profile that doesn't include it. That would be unfortunate, because
the code one has to write to achieve the same effect by defining
from(CompositeData) is nasty.
(Although I have reviewed this change, I would rather not be mentioned
in the Reviewed-by field.)
Éamonn
On 14 September 2012 06:46, Alan Bateman<alan.bate...@oracle.com> wrote:
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.
