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-unsubscr...@incubator.apache.org
For additional commands, e-mail
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 wrote:
> River imported packages of code from the original Sun grant under the
> name 'com.sun.whatever'.
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
Hello,
the Etch community voted on and has approved a proposal to release Apache Etch
1.1.
A vote on the etch-dev@ list already resulted in three +1 from Incubator PMC
members:
- Doug Cutting
- Martijn Dashorst
- Gavin McDonald
The proposal for the release was:
http://mail-archives.apache.org/m
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 "Ri
>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 rel
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
