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 <[email protected]> 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:[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? >> > >
