I, personally would like to ignore the small device space as "running
Jini" and focus on them doing things like surrogate if they need to
supply code into the environment, or just simple app protocols with
smart proxies or other similar solutions that don't keep newer VM
features from being present in the codebase.
Gregg Wonderly
On Mar 27, 2009, at 8:04 AM, Sean Landis wrote:
+1
If a device is too small to use post 1.4 features, go the surrogate
route.
Sean
On Fri, Mar 27, 2009 at 6:41 AM, Jonathan Costers <
jonathan.cost...@googlemail.com> wrote:
I agree with Dennis and Jim. We should be looking foward, not
backwards.
To add to Jim's point, I believe there are probably more urgent
things to
do
than upgrade the complete River distribution to be using post-1.4
features.
Then again, when introducing new things, we should not limit
ourselves to
1.4.
Best
Jonathan
2009/3/27 Jim Waldo <jim.wa...@sun.com>
I have to agree with Dennis. Most of us are now using 1.6; 1.7 is
underway.
I don't think the small device space should be much of an issue;
most of
those devices won't support a full Jini function anyway, since
they lack
class loading (that's why we did the surrogate architecture).
Going back and upgrading to post-1.4 features throughout can
probably
wait.
But that is no reason not to use them when they make sense in new
code.
Jim Waldo
On Mar 27, 2009, at 7:45 AM, Dennis Reedy wrote:
On Mar 27, 2009, at 720AM, Patrick Wright wrote:
Just because the current River codebase is limited to 1.4 doesnt
mean
new
work should be constrained to that right?
I think one has to be careful with compatibility across small-
device
VMs, which, AFAIK, in some cases are 1.4 compatible (cf. JavaME).
Well, and IMHO, keeping the core of River based on a technology
that is
in
it's EOL transition period (http://java.sun.com/j2se/1.4.2/) for
the
sake
of *possible* use for small device deployments may not be ideal.
Dennis
