I agree that dynamic proxy classes should remain dynamic downloads,
however much of net.jini.* isn't in the jsk-platform.jar
Should we expand the platform to contain all net.jini.*?
Except for providers? (com.sun.jini.resource.Service, similar to Java's
sun.misc.Service and java.util.ServiceLoader)
Perhaps we can include more in the platform and reduce the number of jar
archives we've got?
Any thoughts?
Cheers,
Peter.
[email protected] wrote:
Isn't that already jsk-platform.jar? I would object to anything that subverts the dynamic proxy loading concept that is central to Jini.
It is imperative that people don't, for instance, get the service-registrar
proxy impls in their local class path. That would break compatibility with
future or alternate impls.
Cheers,
Greg
------Original Message------
From: Sim IJskes - QCG
To: [email protected]
ReplyTo: [email protected]
Subject: river.jar
Sent: Dec 31, 2010 10:07 AM
Hello,
anybody have an objection against a river.jar in the build that contains
all river runtime classes?
Gr. Sim
