river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Dolan" <christopher.do...@avid.com>
Subject RE: Java package names
Date Thu, 14 Oct 2010 14:40:00 GMT
Thanks, Patricia.  I took your first option and I removed the last TaskManager reference from
my implementation yesterday.  You might find this amusing:

    private static TaskManager logTaskManager = new TaskManager(1, 0 /* thread never dies
*/, 1);
    private void logLater(final LogRecord record) {
        logTaskManager.add(new Task() {
            public boolean runAfter(List tasks, int size) {
                return false;
            public void run() {

That is, it was just being used as a single threaded executor for asynchronous logging.  I
replaced it with a LinkedBlockingQueue<Runnable> and a Thread for a net increase of
about 5 lines of code.

Now my code is down to just these com.sun.jini dependencies:
  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;
This thread has been very useful to me!  :-)


-----Original Message-----
From: Patricia Shanahan [mailto:pats@acm.org] 
Sent: Thursday, October 14, 2010 7:56 AM
To: river-dev@incubator.apache.org
Subject: Re: Java package names

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 

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?


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:pats@acm.org] Sent: Tuesday, October 12, 2010 3:54 PM To:
> river-dev@incubator.apache.org 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:bimargulies@gmail.com] Sent: Tuesday, October 12, 2010
>> 11:51 AM To: general@incubator.apache.org;
>> river-dev@incubator.apache.org 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?

View raw message