You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Benson Margulies <bi...@gmail.com> on 2010/10/12 18:50:44 UTC
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?
Re: Java package names
Posted by James Carman <ja...@carmanconsulting.com>.
On Tue, Oct 12, 2010 at 4:28 PM, Benson Margulies <bi...@gmail.com> wrote:
> From the mentor standpoint, what's important to me is that there is no
> ASF requirement to change those packages. The community can decide to
> do it sooner, later, or not at all. The community can decide to make a
> slew of compatibility wrappers. The community, most importantly, can
> push toward a release with whatever naming it can reach a consensus
> on.
>
I would think that it would be considered "tacky" for us to publish
classes in the com.sun.* packages. It's a bit misleading, IMHO.
Re: Java package names
Posted by James Carman <ja...@carmanconsulting.com>.
On Tue, Oct 12, 2010 at 4:28 PM, Benson Margulies <bi...@gmail.com> wrote:
> From the mentor standpoint, what's important to me is that there is no
> ASF requirement to change those packages. The community can decide to
> do it sooner, later, or not at all. The community can decide to make a
> slew of compatibility wrappers. The community, most importantly, can
> push toward a release with whatever naming it can reach a consensus
> on.
>
I would think that it would be considered "tacky" for us to publish
classes in the com.sun.* packages. It's a bit misleading, IMHO.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Java package names
Posted by Benson Margulies <bi...@gmail.com>.
>From the mentor standpoint, what's important to me is that there is no
ASF requirement to change those packages. The community can decide to
do it sooner, later, or not at all. The community can decide to make a
slew of compatibility wrappers. The community, most importantly, can
push toward a release with whatever naming it can reach a consensus
on.
On Tue, Oct 12, 2010 at 4:09 PM, Christopher Dolan
<ch...@avid.com> 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?
>
Re: Java package names
Posted by Peter Firmstone <ji...@zeus.net.au>.
Hmm, what does imp mean in your Country?
Must be some Unix influence sneaking in.
Sim IJskes - QCG wrote:
> On 10/13/2010 01:14 AM, Peter Firmstone wrote:
>> org.apache.river.imp.*
>
> If we need to shorten the word implementation, please make it impl.
>
> Gr. Sim
>
>
Re: Java package names
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 10/13/2010 01:14 AM, Peter Firmstone wrote:
> org.apache.river.imp.*
If we need to shorten the word implementation, please make it impl.
Gr. Sim
Re: Java package names
Posted by Peter Firmstone <ji...@zeus.net.au>.
Hmm,
How about a compromise:
1. Lets get all tests passing, then release as is.
2. The original intent behind com.sun.* is that it's subject to
change, this should remain.
3. Developers do use the com.sun.* name space.
4. Renaming the entire com.sun.* name space now, might be too much
change too quickly.
A reasonable compromise might be to retain the com.sun.* name space,
however we will advise changes, such as Patricia's TaskManager
refactoring in the Release Notes.
Downstream developers, will have to address changes in the com.sun.*
name space.
As before there is no guarantee the com.sun.* name space won't change.
I use these name spaces when developing new classes:
org.apache.river.api.*
org.apache.river.imp.*
I think we need to break up River's build and make it more Modular, we
can still have a main build script to tests and assembles the release,
that calls the individual builds, but I think we need several minor
builds perhaps broken down into modules like this:
* Jini Platform
* Service API (compiled with Java 1.4, how often do we need to
rebuild them? Almost never.)
* Implementation Libraries
* Reggie
* Mahalo
* Phoenix
* Outrigger
* Mercury
* Norm
* Fiddler
* Test Platform
Then developers will be free to work on one Module, which is an
independent build, each module should contain it's own tests. All tests
can be run weekly on Hudson as an integration test.
If we version the implementation components and they are independent,
then client and services can depend on particular versions, each client
or service can go in their own namespace, to avoid class conflicts:
Example deployment namespace:
Jini Platform & Service API (stable)
______________________________________|______________________________________________
| | | |
| | |
Reggie Outrigger Phoenix *Client *Service
*Proxy Platform Implementation
+ Imp Lib + Imp Lib + Imp Lib + Imp
Lib Classes (not publicly visible)
* Represents client developer applications.
Reggie, Outrigger, Phoenix shown here are Service Implementations, not
their proxy's.
Each private namespace can utilise a different implementation library
version, implementation classes required by the Jini Platform will need
to remain with the Jini Platform.
All implementations cooperate using the common stable api in the Jini
Platform & Service API.
It will be easier to support different platforms, like Java CDC (Java
1.4 subset), using a subset release, this could potentially become our
largest Java client base with internet connected BlueRay Players and
Digital TV's. ServiceUI is a competitive advantage in this environment.
These are just my thoughts, what are yours?
Cheers,
Peter.
Patricia Shanahan wrote:
> 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?
>
>
Re: Java package names
Posted by Peter Firmstone <ji...@zeus.net.au>.
It might be time to get a new mail client, mine keeps rearranging my
ascii, hope this condensed version works:
Example deployment namespace:
Jini Platform & Service API (stable)
_______________________________|______________
| | | | | |
Reggie Phoenix *Client *Service *Proxy Platform Imp
+Imp Lib +Imp Lib +Imp Lib Classes
(no public vis)
* Represents client developer applications.
Reggie, Outrigger, Phoenix shown here are Service Implementations, not
their proxy's.
Each private namespace can utilise a different implementation library
version, implementation classes required by the Jini Platform will need
to remain with the Jini Platform.
All implementations cooperate using the common stable api in the Jini
Platform & Service API.
Cheers,
Peter.
Re: Java package names
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 14-10-10 12:33, Patricia Shanahan 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.
Some remarks:
* a.Thing.class != b.Thing.class
* discipline to maintain svn revision history
* extend and deprecate? final classes?
I prefer big bang conversion.
Gr. Sim
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Java package names
Posted by Tom Hobbs <tv...@googlemail.com>.
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 <pa...@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?
>>
>
>
Re: Java package names
Posted by Patricia Shanahan <pa...@acm.org>.
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?
>
Re: Java package names
Posted by Niclas Hedhman <ni...@hedhman.org>.
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.
Cheers
Niclas
On Wed, Oct 13, 2010 at 11:27 PM, Christopher Dolan
<ch...@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
RE: Java package names
Posted by Christopher Dolan <ch...@avid.com>.
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() {
log(record);
}
});
}
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! :-)
Chris
-----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
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: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?
>
Re: Java package names
Posted by Patricia Shanahan <pa...@acm.org>.
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: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?
>
RE: Java package names
Posted by Christopher Dolan <ch...@avid.com>.
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?
Re: Java package names
Posted by Patricia Shanahan <pa...@acm.org>.
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?
Re: Java package names
Posted by Benson Margulies <bi...@gmail.com>.
>From the mentor standpoint, what's important to me is that there is no
ASF requirement to change those packages. The community can decide to
do it sooner, later, or not at all. The community can decide to make a
slew of compatibility wrappers. The community, most importantly, can
push toward a release with whatever naming it can reach a consensus
on.
On Tue, Oct 12, 2010 at 4:09 PM, Christopher Dolan
<ch...@avid.com> 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?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Java package names
Posted by Christopher Dolan <ch...@avid.com>.
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?
RE: Java package names
Posted by Christopher Dolan <ch...@avid.com>.
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?
Re: Java package names
Posted by Dennis Reedy <de...@gmail.com>.
I would suggest the team moves towards the next 2.x release without any package name changes. The next major release (3.0) should include the change of all com.sun.jini to org.apache.river.
Dennis
On Oct 12, 2010, at 227PM, Gregg Wonderly wrote:
> From a name and branding perspective, removing the use of com.sun, could help people focus on "River" as opposed to "Sun's Jini Implementation". I have several references to com.sun.jini.start. But, I also have my own fork of 2.1 that I'm still using in active deployments. River should be "River".
>
> Gregg Wonderly
>
> On 10/12/2010 12:21 PM, Niclas Hedhman wrote:
>> What Benson is talking about is not com.sun packages in the JDK, but
>> that Jini implementation classes resides in com.sun packages (compared
>> to spec classes residing in net.jini space)
>>
>> They should go as part of a suitable level bump in versioning. The
>> impact on users is reasonably small...
>>
>> Niclas
>>
>> On Wed, Oct 13, 2010 at 1:15 AM, Matthias Wessendorf<ma...@apache.org> wrote:
>>> if you care to be able to run on a different JVM, than it needs to be fixed.
>>>
>>> Generally it's bad to rely on some "private" packages/APIs
>>>
>>> -M
>>>
>>> On Tue, Oct 12, 2010 at 6:50 PM, Benson Margulies<bi...@gmail.com> wrote:
>>>> River imported packages of code from the original Sun grant under the
>>>> name 'com.sun.whatever'.
>>>>
>>>> How important is it to change that?
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> blog: http://matthiaswessendorf.wordpress.com/
>>> sessions: http://www.slideshare.net/mwessendorf
>>> twitter: http://twitter.com/mwessendorf
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>>
>>
>>
>>
>
Re: Java package names
Posted by Gregg Wonderly <gr...@wonderly.org>.
From a name and branding perspective, removing the use of com.sun, could help
people focus on "River" as opposed to "Sun's Jini Implementation". I have
several references to com.sun.jini.start. But, I also have my own fork of 2.1
that I'm still using in active deployments. River should be "River".
Gregg Wonderly
On 10/12/2010 12:21 PM, Niclas Hedhman wrote:
> What Benson is talking about is not com.sun packages in the JDK, but
> that Jini implementation classes resides in com.sun packages (compared
> to spec classes residing in net.jini space)
>
> They should go as part of a suitable level bump in versioning. The
> impact on users is reasonably small...
>
> Niclas
>
> On Wed, Oct 13, 2010 at 1:15 AM, Matthias Wessendorf<ma...@apache.org> wrote:
>> if you care to be able to run on a different JVM, than it needs to be fixed.
>>
>> Generally it's bad to rely on some "private" packages/APIs
>>
>> -M
>>
>> On Tue, Oct 12, 2010 at 6:50 PM, Benson Margulies<bi...@gmail.com> wrote:
>>> River imported packages of code from the original Sun grant under the
>>> name 'com.sun.whatever'.
>>>
>>> How important is it to change that?
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
>
>
Re: Java package names
Posted by Gregg Wonderly <gr...@wonderly.org>.
From a name and branding perspective, removing the use of com.sun, could help
people focus on "River" as opposed to "Sun's Jini Implementation". I have
several references to com.sun.jini.start. But, I also have my own fork of 2.1
that I'm still using in active deployments. River should be "River".
Gregg Wonderly
On 10/12/2010 12:21 PM, Niclas Hedhman wrote:
> What Benson is talking about is not com.sun packages in the JDK, but
> that Jini implementation classes resides in com.sun packages (compared
> to spec classes residing in net.jini space)
>
> They should go as part of a suitable level bump in versioning. The
> impact on users is reasonably small...
>
> Niclas
>
> On Wed, Oct 13, 2010 at 1:15 AM, Matthias Wessendorf<ma...@apache.org> wrote:
>> if you care to be able to run on a different JVM, than it needs to be fixed.
>>
>> Generally it's bad to rely on some "private" packages/APIs
>>
>> -M
>>
>> On Tue, Oct 12, 2010 at 6:50 PM, Benson Margulies<bi...@gmail.com> wrote:
>>> River imported packages of code from the original Sun grant under the
>>> name 'com.sun.whatever'.
>>>
>>> How important is it to change that?
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Java package names
Posted by Niclas Hedhman <ni...@hedhman.org>.
What Benson is talking about is not com.sun packages in the JDK, but
that Jini implementation classes resides in com.sun packages (compared
to spec classes residing in net.jini space)
They should go as part of a suitable level bump in versioning. The
impact on users is reasonably small...
Niclas
On Wed, Oct 13, 2010 at 1:15 AM, Matthias Wessendorf <ma...@apache.org> wrote:
> if you care to be able to run on a different JVM, than it needs to be fixed.
>
> Generally it's bad to rely on some "private" packages/APIs
>
> -M
>
> On Tue, Oct 12, 2010 at 6:50 PM, Benson Margulies <bi...@gmail.com> wrote:
>> River imported packages of code from the original Sun grant under the
>> name 'com.sun.whatever'.
>>
>> How important is it to change that?
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
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
Re: Java package names
Posted by Niclas Hedhman <ni...@hedhman.org>.
What Benson is talking about is not com.sun packages in the JDK, but
that Jini implementation classes resides in com.sun packages (compared
to spec classes residing in net.jini space)
They should go as part of a suitable level bump in versioning. The
impact on users is reasonably small...
Niclas
On Wed, Oct 13, 2010 at 1:15 AM, Matthias Wessendorf <ma...@apache.org> wrote:
> if you care to be able to run on a different JVM, than it needs to be fixed.
>
> Generally it's bad to rely on some "private" packages/APIs
>
> -M
>
> On Tue, Oct 12, 2010 at 6:50 PM, Benson Margulies <bi...@gmail.com> wrote:
>> River imported packages of code from the original Sun grant under the
>> name 'com.sun.whatever'.
>>
>> How important is it to change that?
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Java package names
Posted by Matthias Wessendorf <ma...@apache.org>.
if you care to be able to run on a different JVM, than it needs to be fixed.
Generally it's bad to rely on some "private" packages/APIs
-M
On Tue, Oct 12, 2010 at 6:50 PM, Benson Margulies <bi...@gmail.com> wrote:
> River imported packages of code from the original Sun grant under the
> name 'com.sun.whatever'.
>
> How important is it to change that?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org