I agree with the idea of designating suitable com.sun classes as
external interfaces.
We could reduce pain during repackaging by retaining but deprecating the
old classes, only removing them at the next major release after the
repackaging. That would allow users to adjust gradually.
One option is to simply remove TaskManager from your program. If you
don't need its specific runAfter behavior, that may be relatively easy.
If you are likely to go on using it, I would like your opinion on some
changes to TaskManager.Task that would help improve scalability of
TaskManager:
Make it an abstract class rather than an interface.
Change runAfter to:
public abstract Task runAfter(Iterable<Task> candidates);
requiring the runAfter implementation to report the first Task in
Iterable order that it has to run after, null if it can go now.
Making Task an abstract class allows TaskManager to efficiently
associate working data with the Task. The change from a List with a
promise of fast indexed access to an Iterable allows the TaskManager
implementation to use an efficient data structure to represent its
modified FIFO. An ArrayList is not an efficient representation of a FIFO
unless there is a guarantee that the FIFO will only ever contain a few
elements. The change to reporting a specific Task, rather than a boolean
indicating if the current task has to wait for any Task, helps with
efficient activation of waiting tasks when a task finishes.
As a potential simplification for TaskManager users, I am also proposing
providing a default runAfter implementation:
public Task runAfter(Iterable<Task> candidates){
return null;
}
Would these changes be a problem for your uses of TaskManager, if any?
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?
