Subject:
|
Re: Something else is needed, I think...
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Wed, 5 May 1999 17:26:47 GMT
|
Original-From:
|
John A. Tamplin <jat@liveonthenet.+ihatespam+com>
|
Viewed:
|
1118 times
|
| |
|
|
On Wed, 5 May 1999, Sren Hilmer wrote:
> That is right, but this is mainly enforced by the class library, which
> offcourse will have to be way different for the RCX. What I was getting at was
> that we do not need to implement the whole java bytecode instruction set, but
> could do with a subset. And yes there also are no threads in JavaCard, which we
> obviously need.
You could certainly throw some sort of "unsupported" exception when you see
a d* bytecode, but the biggest issues aren't implementing 64-bit ints and
floats but rather garbage collection and threading. JC doesn't require
either, but some implementations have GC. Both will require support from
the underlying OS.
While you can certainly get by without GC, you are writing very different
code. For example, the String class is defined as immutable and every
operation that modifies it generates a new object. It is hard to imagine
how a JVM that potentially runs for a very long time in the RCX could do
without GC.
> Yep, that was what I was talking about. In JavaCard they have efectively split
> the verification/resolving/compression of the classes away from the executing
> device (the smartcard). I think a similar approach could be usefull for the RCX
> environment.
The only downside to that is that the host computer must have an accurate
idea of what classes have already been loaded so it can link to them. Ie,
I would like to be able to download RCX.FancySensorInterpreter and than
have several applets use the same class.
> > Which ones are these? I am using the JC2.0 which is implemented by the
> > iButton with Java.
>
> I have been using:
> a)JavaCard 1.0 implemented on Schlumberger Cyberflex 8K cards.
> b)JavaCard 2.0 implemented on the iButton
> c)JavaCard 2.0 implemented on Gemplus GemXpresso card
> d)JavaCard 2.0 implemented on DeLaRue GalactIC card
> e)JavaCard 2.0 SUN ref. implementation (maybe this one doesn't count)
What are Sun's license terms for their reference implementation?
> The iButton and the GemXpresso is by far the most sofisticated environments
> ,iButton has a garbage collector and GemXpresso has a 32 bit RISC processor
> supporting 32 bit int's and a way to encode APDU's automatically into function
> calls. Offcourse these are proprietary features which you can only use if you
> know you do not need to move to another card.
The iButton also has 32-bit ints.
John A. Tamplin Traveller Information Services
jat@LiveOnTheNet.COM 2104 West Ferry Way
256/705-7007 - FAX 256/705-7100 Huntsville, AL 35801
--
Did you check the web site first?: http://www.crynwr.com/lego-robotics
|
|
Message is in Reply To:
 | | Re: Something else is needed, I think...
|
| (...) already (...) smartcards). (...) That is right, but this is mainly enforced by the class library, which offcourse will have to be way different for the RCX. What I was getting at was that we do not need to implement the whole java bytecode (...) (25 years ago, 5-May-99, to lugnet.robotics)
|
67 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
