I *am* sensitive to the notion of compatibility but I would argue that
no effort should be spent creating a compatibility layer for the
com.sun.jini classes. It has historically been made perfectly clear
that the developer depends on these classes at his/her peril. There is
plenty of work to do and I do not think time should be spent on this.
On 7/22/07, Niclas Hedhman <[EMAIL PROTECTED]> wrote:
On Sunday 22 July 2007 17:52, Dan Creswell wrote:
> We would appreciate some clarification in respect of the above and some
> guidance on what the minimum requirements might be. For example would
> it be acceptable to create a compatibility layer and thus, for at least
> this first release, have both com.sun and org.apache namespaces present
> in our codebase and release? This would allow our users some time to
> transition smoothly to the new package namespace.
IMHO, yes transitional solutions are acceptable, and possibly even preferable.
*I* would like to see;
First Incubating Release - current package names.
Then (optionally) - compatibility layer where org.apache.river wraps the
com.sun.jini classes.
Last Incubating release - the com.sun.jini classes are the wrappers to the
org.apache.river classes.
First Full Apache release - only org.apache.river classes.
And I also think there is no contention about keeping the net.jini API classes
as-is, without package name changes, which is what the majority of the Jini
users actually refers to.
Would that work?
Cheers
Niclas
