Preferred list generation - some thoughts

[Peter Firmstone <pe...@zeus.net.au>]

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?

Peter.

Re: Preferred list generation - some thoughts

[Dan Creswell <da...@gmail.com>]

On 22 June 2012 07:35, Peter Firmstone <pe...@zeus.net.au> 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.
>
>
>

Re: Preferred list generation - some thoughts

[Dan Creswell <da...@gmail.com>]

On 24 June 2012 06:50, Peter Firmstone <ji...@zeus.net.au> wrote:

> One of my first tasks as a River developer was to rewrite ClassDep,
> previously it was based on a jvm tools library, now it uses ASM.
>
> What became painfully obvious at the time: IT IS NOT POSSIBLE to determine
> all runtime dependencies at compile time.
>
> However this could be sufficient for most developers, even if it's not
> preferred, a class found during runtime may be not be available at the
> client and could still be loaded from the proxy jar, it just means the
> parent class loader will be tried first.
>
> So the preferred list automatically generated would not necessarily be
> comprehensive, but in most cases adequate, this seems less confusing than
> writing a new class loader with different behaviour.
>
> Can anyone see any issues with this?
>
>
No. The only problems we've ever had with this are that we do the most
flexible option as a default which puts load on the developer. So we're
picking a different default which, so long as we document it, and explain
what to do if that default is no good for you (and I reckon it will be for
most), we're done.

Peter.
>
>
>
> Peter Firmstone wrote:
>
>> Well spotted, I spoke to Peter Kriens over the phone about this in 2010
>> (very smart guy btw), ClassDep doesn't detect Class.forName dependencies.
>>
>> A string might not be defined until runtime, so it's not something that
>> can be easily determined.  This could become even more difficult if dynamic
>> languages like Groovy are used in the proxy.
>>
>> Another alternative might be to prefer everything resolvable by the proxy
>> codebase string annotation at runtime.   It would be up to the developer to
>> ensure that proxy classses are packaged correctly, annotations could go
>> some way to automating this for the developer.  The developer could include
>> any library jars required in their codebase string.
>>
>> Perhaps a classloader called ProxyPreferredClassLoader might be created
>> for such a purpose.
>>
>> @ServiceAPI - dependency tree excluded from proxy codebase.
>> @SmartProxy - root class for dependency search, to determine classes to
>> be included in proxy jar file.
>>
>> Consideration has to be given to felixibility for developers using Maven,
>> OSGi and dynamic languages.
>>
>> Peter.
>>
>>
>>  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.
>>>
>>
>>
>>
>>
>

Re: Preferred list generation - some thoughts

[Peter Firmstone <ji...@zeus.net.au>]

One of my first tasks as a River developer was to rewrite ClassDep, 
previously it was based on a jvm tools library, now it uses ASM.

What became painfully obvious at the time: IT IS NOT POSSIBLE to 
determine all runtime dependencies at compile time.

However this could be sufficient for most developers, even if it's not 
preferred, a class found during runtime may be not be available at the 
client and could still be loaded from the proxy jar, it just means the 
parent class loader will be tried first.

So the preferred list automatically generated would not necessarily be 
comprehensive, but in most cases adequate, this seems less confusing 
than writing a new class loader with different behaviour.

Can anyone see any issues with this?

Peter.


Peter Firmstone wrote:
> Well spotted, I spoke to Peter Kriens over the phone about this in 
> 2010 (very smart guy btw), ClassDep doesn't detect Class.forName 
> dependencies.
>
> A string might not be defined until runtime, so it's not something 
> that can be easily determined.  This could become even more difficult 
> if dynamic languages like Groovy are used in the proxy.
>
> Another alternative might be to prefer everything resolvable by the 
> proxy codebase string annotation at runtime.   It would be up to the 
> developer to ensure that proxy classses are packaged correctly, 
> annotations could go some way to automating this for the developer.  
> The developer could include any library jars required in their 
> codebase string.
>
> Perhaps a classloader called ProxyPreferredClassLoader might be 
> created for such a purpose.
>
> @ServiceAPI - dependency tree excluded from proxy codebase.
> @SmartProxy - root class for dependency search, to determine classes 
> to be included in proxy jar file.
>
> Consideration has to be given to felixibility for developers using 
> Maven, OSGi and dynamic languages.
>
> Peter.
>
>
>> 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.
>
>
>

Re: Preferred list generation - some thoughts

[Peter Firmstone <pe...@zeus.net.au>]

Well spotted, I spoke to Peter Kriens over the phone about this in 2010 
(very smart guy btw), ClassDep doesn't detect Class.forName dependencies.

A string might not be defined until runtime, so it's not something that 
can be easily determined.  This could become even more difficult if 
dynamic languages like Groovy are used in the proxy.

Another alternative might be to prefer everything resolvable by the 
proxy codebase string annotation at runtime.   It would be up to the 
developer to ensure that proxy classses are packaged correctly, 
annotations could go some way to automating this for the developer.  The 
developer could include any library jars required in their codebase string.

Perhaps a classloader called ProxyPreferredClassLoader might be created 
for such a purpose.

@ServiceAPI - dependency tree excluded from proxy codebase.
@SmartProxy - root class for dependency search, to determine classes to 
be included in proxy jar file.

Consideration has to be given to felixibility for developers using 
Maven, OSGi and dynamic languages.

Peter.


> 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.