Brian Murphy wrote:
On Fri, Mar 19, 2010 at 7:21 PM, Peter Firmstone <[email protected]> wrote:
The old jar's are easily removed, but what about obsolete / duplicate
interfaces, any suggestions?
I'm not aware of any duplicate interfaces. Could you be more
specific?
I don't have any specifics in mind, just posing the question. I was
hoping there might be a way to reduce the conceptual codebase size a
developer has to get over to participate in River development.
I believe there were some deprecated items that were scheduled
for removal after the appropriate number of releases had occurred.
Don't know what interfaces would be considered obsolete though;
such a designation might be more about opinion than functionality
or utility.
There have been some comments in past threads about the
value of services like the lookup discovery service and the
lease renewal service; both of which have little usage as far
as I know. Some have even questioned the usefulness of the
event mailbox service, but for what it's worth, I can tell you that
I know of projects/companies that do use that service. So I
don't know where the line should be drawn, or what criteria
should be applied when deciding when something should be
removed.
Do we need to continue supporting rmic stubs? Should we remove facilities
for RMI communication other than those utilised through JERI?
Are you talking about just removing the generation of the stubs
in the build scripts, or are you talking about the use of JRMP
for example?
I'm not against the use of the JRMP protocol, provided that client and
the Service
implementation don't depend on it, so the Service and client can use
other transport
protocols also.
Exporter exp = new JrmpExporter();
Provided only Exporter methods are used, it can be replaced by any other
Exporter
implementation.
However I believe we still support (discouraged) applications extending
UnicastRemoteObject which implicitly exports a proxy and require the
generation rmic proxy stubs.
Having two distinctly different mechanisms for Remote proxy object
creation for Services causes confusion. At a minimum we need to change
our docs to reflect that.
Seeing that a Service is designed to be an abstraction where service
implementations can be exchanged, it would be wrong to tie a client to
an implementation detail of the Service, which is what extending
UnicastRemoteObject does.
The interface net.jini.core.lookup.ServiceRegistrar has the following
method:
EventRegistration notify(ServiceTemplate tmpl, int transitions,
RemoteEventListener listener, MarshalledObject handback, long
leaseDuration);
Where the MarshalledObject is an instance of java.rmi.MarshalledObject.
Jini has it's own later version of
net.jini.io.MarshalledInstance
net.jini.io.MarshalledObject
Where the latter is a convenience class for converting
java.rmi.MarshalledObject.
This is a little off topic; I've been looking into what's required to
support Java cdc, namely a minimum of Personal Basis Profile 1.1.2 (a
subset of J2SE 1.4.2) and while it supports java.rmi.Remote and all the
exceptions, it doesn't support the server component of rmi and it lacks
java.rmi.MarshalledObject.
There are a significant number of devices: Amazon Kindle, Blue Ray
Players, Set top boxes, extending this profile.
Unfortunately interfaces cannot be changed, however there is something
that can be done:
A super interface without the offending method inserted into the
inheritance hierarchy. However what is actually required to support cdc
is still under investigation.
I'm not sure about the usefulness of manually generating
the stubs.
Are these stubs generated for Clients and Services utilising JrmpExporter?
I had a search through the source code I can't see any real dependency
on using UnicastRemoteObject?
But if you're talking about removing classes like
JrmpExporter and IiopExporter, I'd be very much against that.
No, Exporters are part of Jini 2.
Brian
Best Regards & thanks for the reply,
Peter.
