I was a big participant in the small-device movement for Jini back in the
day. I agree with Greg. Jini cannot be all things.
Sean
On Fri, Mar 27, 2009 at 9:23 AM, Greg Trasuk <tras...@stratuscom.com> wrote:
>
> I say, forget small devices. Jini is network infrastructure for service
> oriented architectures. The mention of small devices is the root of
> Jini's adoption problems in the first place ("Jini? that has something
> to do with discovering printers, right?"). Let's not make that mistake
> again!
>
>
> Cheers,
>
> Greg.
>
> On Fri, 2009-03-27 at 09:58, Peter Firmstone wrote:
> > I agree with Jonathan, Dennis and Jim, however I think Patrick has
> > raised a good point.
> >
> > Retrotranslator allows you to use new Java l.5 language features which
> > require compiling on jdk 1.5 or later, the class files compiled by Jdk
> > 1.5 or later once Retrotranslator has altered them, will run on jre 1.4
> > or even jre 1.3 since Retrotranslator packages additional compatibility
> > classes into the jar file, but only those required. The question is
> > then; what are the memory limitations of JavaME 1.4.2 CDC Devices?
> >
> > It would be no longer possible to compile with jdk 1.4 however still
> > possible to run on jre 1.4. It also means that once we drop support
> > for jre 1.4 we have all the performance benefits of the new concurrency
> > libraries with the latest JRE.
> >
> > We might also (at some later date, I think it's ambitious) be able to
> > use the Retrotranslator JIT class compiler to translate classes from
> > code repositories on the fly for earlier jre's participating with later
> > versions in a heterogeneous environment, while allowing the later jre's
> > to make use of newer library performance advantages without sacrificing
> > compatibility.
> >
> > I had a look at Java PhoneME Advanced J2ME CDC 1.4.2:
> >
> >
> http://wiki.java.net/bin/view/Mobileandembedded/PhoneMEAdvancedGSGWinMobile
> >
> > There's an optional setting there to set the Device Emulator RAM
> > size to 256MB
> >
> > Then on http://www.8mobile.org/blog/?cat=2 :
> >
> > An Early Access release of the new Java Platform Micro Edition Software
> > Development Kit 3.0 is available for download. This SDK supports CLDC,
> > CDC, and Blu-ray Disc Java (BDJ) development. Emulation is a major
> > focus: on-device deployment, on-device debugging, integration with
> > devices running Windows Mobile and integration with third-party
> > emulators are just a few of the new features in this preview
> >
> > Windows Mobile 6.0 platform installed on a target device with
> > network connectivity, 32-bit RISC based microprocessor, and minimum 64
> > MB RAM.
> >
> > Ricoh Photocopiers also have J2ME CDC, they actually may be able to
> > perform some very useful functions with River?
> >
> > Anyone on the list have more experience with Small Devices? Do we need
> > to decide what the minimum J2ME CDC device requirements are? Do we pick
> > a Sun J2ME CDC emulator and test on that?
> >
> > Perhaps there is a Subset of Java 1.5 features we can use? If we can
> > determine a compact subset, agree upon it and post it on the Rivers
> > Developers page, we might be able to have the best of both worlds?
> >
> > Cheers,
> >
> > Peter.
> >
> >
> >
> > Jonathan Costers 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
> > >>>
> > >>>
> > >>
> > >
> > >
> --
> Greg Trasuk, President
> StratusCom Manufacturing Systems Inc. - We use information technology to
> solve business problems on your plant floor.
> http://stratuscom.com
>
>
