river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Hobbs <tvho...@googlemail.com>
Subject Re: Java package names
Date Thu, 14 Oct 2010 11:17:53 GMT
That's a good point.  We can mark those classes as deprecated for the
2.1.3 release that Peter suggested could be done in November.  The
3.0.0 release (sometime next year, I assume) can then do the actual
deprecation.

On Thu, Oct 14, 2010 at 11:33 AM, Patricia Shanahan <pats@acm.org> wrote:
> 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: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?
>>
>
>

Mime
View raw message