Subject:
|
Re: interest in JVM porting effort
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Fri, 7 May 1999 17:51:15 GMT
|
Original-From:
|
John A. Tamplin <jat@/NoMoreSpam/liveonthenet.com>
|
Viewed:
|
1396 times
|
| |
|
|
On Fri, 7 May 1999, Eric Lind wrote:
> Aaah, good points. Do we have a preliminary list of packages that we'll need?
> Actually, it's easier to pick things that aren't needed and then complement
> it. java.awt is right out, as is java.applet. The same thing can be said for
> java.beans, java.sql, java.txt, java.math, java.util, java.security, and all of
> the javax's. java.rmi could prove useful, although probably overkill for the
> RCX, and java.net might be nice later on, but, again, not needed now. This
> leaves us with java.lang (and some of its subpackages) and java.io. That seems
> considerably less daunting than what I first thought. Of course, we can pick
> and choose the actual classes and interfaces from these packages.
Actually, there are some things in java.math that should be there. I would
expect we would have two sets of classes -- those which are built into the
JVM port (ie, those required for operation like Object, Thread, etc) and
those which can be loaded separately. While the JVM wouldn't have the
bytecode verifier, it would be able to download additional classes and
link them in (using early binding with the understanding that you may have
to remove classes and reload them if you change the interface to
superclasses). This is the way the JavaCard API works -- the linking is
done on the host using a database of entry points, which would be generated
as part of the build process.
java.rmi is a real hog in terms of space, since you have to bring in all
the serialization stuff. I also think java.io is too heavyweight for our
needs, since the display/button interface is too limited to justify streams
and we are better off creating a datagram protocol for the IR link.
That said, I don't think it is terribly important to decide on the actual
set of classes up front. We will implement the ones that have to be there
for the language to work, and then add others as we have need for them.
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 has 1 Reply:
 | | Re: interest in JVM porting effort
|
| I was merely ruminating on packages that might provide interesting interfaces/classes, and packages that we can toss out of hand. I wasn't trying to imply (although my post did seem that way) that we should implement ALL of java.io, just that parts (...) (26 years ago, 7-May-99, to lugnet.robotics)
|
Message is in Reply To:
| | Re: interest in JVM porting effort
|
| Aaah, good points. Do we have a preliminary list of packages that we'll need? Actually, it's easier to pick things that aren't needed and then complement it. java.awt is right out, as is java.applet. The same thing can be said for java.beans, (...) (26 years ago, 7-May-99, to lugnet.robotics)
|
13 Messages in This Thread:
  
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
Active threads in Robotics
|
|
|
|
|
|
