river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: Java package names
Date Thu, 14 Oct 2010 01:00:33 GMT
I think this kind of report is excellent, and I think many of us
recall that some classes (e.g. JoinManager) were similarly 'promoted'
from com.sun.jini to net.jini in the early days. Since 'renaming' is
partly incompatible, it is a good opportunity to look over these kind
of changes at the same time.


On Wed, Oct 13, 2010 at 11:27 PM, Christopher Dolan
<christopher.dolan@avid.com> 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?

Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java

I  live here; http://tinyurl.com/2qq9er
I  work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug

View raw message