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.
