Do any of your unit tests test the Jini implementation, independent of
the rest of your own code? If so, please consider contributing them, so
that they can be run as part of the build tests. The more unit tests,
from the more different sources, the better.
One way of minimizing pain during a package reorganization would be to
go through a step of having both old and new versions of the classes,
with the old versions unmodified except for being deprecated. Code using
the classes could be modified gradually to remove references to
deprecated classes.
Patricia
Christopher Dolan wrote:
It turns out that I overstated my case, so I withdraw my negative
vote. I wrote my previous email before researching how extensively
my code actually uses the com.sun.jini.* classes. It's not nearly as
bad as I thought -- I had misrecollected that some of the
AbstractEntry subclasses were in com.sun -- and some of it is just
bad code in my project. Anecdotally, here are the classes my project
currently uses (not including my unit tests, which dig deeper):
import com.sun.jini.config.Config; import
com.sun.jini.config.ConfigUtil; import
com.sun.jini.landlord.Landlord; import
com.sun.jini.landlord.LandlordLease; import
com.sun.jini.landlord.LeaseFactory; import
com.sun.jini.loader.pref.internal.PreferredResources; import
com.sun.jini.logging.Levels; import
com.sun.jini.thread.TaskManager.Task; import
com.sun.jini.thread.TaskManager;
I've been trying to refactor many of those out (like TaskManager),
but some of them are hard to avoid, especially the landlord classes
and Levels. PreferredResources, for example, is in my custom
PreferredClassLoader implementation.
Chris
-----Original Message----- From: Patricia Shanahan
[mailto:[email protected]] Sent: Tuesday, October 12, 2010 3:54 PM To:
[email protected] Subject: Re: Java package names
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?
