On 22 June 2012 07:35, Peter Firmstone <[email protected]> wrote:
> By using a tool taking advantage of bytecode analysis, a developer could > first annotate the ServiceAPI interface eg: @ServiceAPI, then the bytecode > analysis could find all dependencies that exclude the jini platform and any > other interface (and it's dependencies) that declares @ServiceAPI > > Every class reachable from @ServiceAPI interfaces would have to be > considered in the public API namespace, and as such should be excluded from > preferred lists. > > A smart proxy could be annotated with @SmartProxy, then all dependencies > could be discovered using bytecode analysis, ignoring any classes reachable > from service api, the jini or java platforms. This remaining classes would > be the preferred class list. > > This list of preferred classes would never be shared with other proxy's or > clients, the server service implementation would still depend on these > classes. > > The following Nic's advise, use URL's for all code bases, to avoid > annotation loss. > > Thoughts? > > Could work for anything other than cases where someone makes liberal use of dynamic class loading via Class.forName and similar. So let's say I have a smart proxy that has some dynamically assembled bits, the references will be in String form making bytecode analysis difficult. I wouldn't say this is likely a common case, more something that would have to be noted as a limitation of the tool so developers are not caught out. Peter. > > >
