Hmm,
How about a compromise:
1. Lets get all tests passing, then release as is.
2. The original intent behind com.sun.* is that it's subject to
change, this should remain.
3. Developers do use the com.sun.* name space.
4. Renaming the entire com.sun.* name space now, might be too much
change too quickly.
A reasonable compromise might be to retain the com.sun.* name space,
however we will advise changes, such as Patricia's TaskManager
refactoring in the Release Notes.
Downstream developers, will have to address changes in the com.sun.*
name space.
As before there is no guarantee the com.sun.* name space won't change.
I use these name spaces when developing new classes:
org.apache.river.api.*
org.apache.river.imp.*
I think we need to break up River's build and make it more Modular, we
can still have a main build script to tests and assembles the release,
that calls the individual builds, but I think we need several minor
builds perhaps broken down into modules like this:
* Jini Platform
* Service API (compiled with Java 1.4, how often do we need to
rebuild them? Almost never.)
* Implementation Libraries
* Reggie
* Mahalo
* Phoenix
* Outrigger
* Mercury
* Norm
* Fiddler
* Test Platform
Then developers will be free to work on one Module, which is an
independent build, each module should contain it's own tests. All tests
can be run weekly on Hudson as an integration test.
If we version the implementation components and they are independent,
then client and services can depend on particular versions, each client
or service can go in their own namespace, to avoid class conflicts:
Example deployment namespace:
Jini Platform & Service API (stable)
______________________________________|______________________________________________
| | | |
| | |
Reggie Outrigger Phoenix *Client *Service
*Proxy Platform Implementation
+ Imp Lib + Imp Lib + Imp Lib + Imp
Lib Classes (not publicly visible)
* Represents client developer applications.
Reggie, Outrigger, Phoenix shown here are Service Implementations, not
their proxy's.
Each private namespace can utilise a different implementation library
version, implementation classes required by the Jini Platform will need
to remain with the Jini Platform.
All implementations cooperate using the common stable api in the Jini
Platform & Service API.
It will be easier to support different platforms, like Java CDC (Java
1.4 subset), using a subset release, this could potentially become our
largest Java client base with internet connected BlueRay Players and
Digital TV's. ServiceUI is a competitive advantage in this environment.
These are just my thoughts, what are yours?
Cheers,
Peter.
Patricia Shanahan wrote:
This is troubling news. My proposed refactoring of TaskManager to
enable performance tuning depends on the assumption that, as a
com.sun.* class, it is only used within the project.
In general, we will be severely limited in our ability to progress if
we have to treat all public com.sun.* interfaces as external interfaces.
Patricia
Christopher Dolan wrote:
I vote against such an incompatible change. There are a lot of
classes under there, for example com.sun.jini.thread.TaskManager,
that are utility code employed by downstream developers. I think all
new code should go elsewhere if possible, but changing the existing
com.sun.jini packages would be hard on existing users.
Chris
-----Original Message----- From: Benson Margulies
[mailto:[email protected]] Sent: Tuesday, October 12, 2010 11:51
AM To: [email protected]; [email protected]
Subject: Java package names
River imported packages of code from the original Sun grant under the
name 'com.sun.whatever'.
How important is it to change that?
