On 2/2/2011 6:15 PM, Peter Firmstone wrote:
Michał Kłeczek wrote:
On Thu, Feb 3, 2011 at 12:47 AM, Peter Firmstone <[email protected]> wrote:
I like the fact that Gregg's pushed the envelope, he's pushed Jini beyond
it's current capability.
Now I'm wondering if there's a way around the Preferred Classes problem.
The problem with PREFERRED.LIST is more fundamental - for example
every RemoteEvent producer is forced to download a jar file just to
check that RemoteEventListener is not preferred. As such the issue
cannot be solved at the LUS API level.
Michal
Yes there are more fundamental problems with preferred classes, ClassLoading etc
that remain to be solved.
But rather than fix it on this occassion, MarshalledServiceItem is just resolved
with local classes and preferred class loading is not used or needed. When the
client unmarshalls the MarshalledServiceItem, then preferred class loading will
be used and jar files downloaded. MarshalledServiceItem can provide a
significant amount of information by just resolving using local classes, which
the client can utilise.
In the long term I see it like this:
We need to look into dependency inversion to remove implementation classes from
the platform and application class loader, which is the problem that preferred
class loading addresses.
If implementation classes are not present in the platform, you don't need
preferred classes for proxys to have their own copy of an implementation class,
because those classes will be resolved by standard java classloading rules in
the proxy class loader.
One thing to note, is that I have used PreferredClassLoader to fix bugs by
taking common classes that I use in GUI constructions that would have been
resolved in the parent loader and switching them to be preferred so that I'd get
the fixed version. I am not sure that there is a perfect "split" of
implementation vs platform. Sometimes implementation can be a mini-platform of
sorts. Just repackaging/rearranging jars is not a singular fix, always.
Gregg Wonderly
