Excuse me for talking to myself :-) the loader I spoke of is part of java.rmi.*. the CVM should work with RMI. It runs on linux and Vxworks. So I'm guessing this loader could be used to get some of even the core classes. That would require some experimentation. I can check this out a little. What are you using for Dachstein development. I have slink1.1 I have been using. I have suSE 7.3 and redhat/valinux 6.2.x.
Glenn "Glenn A. Thompson" wrote: > Whoops! > > Hey I miss spoke about the codebase. The vm does not have the codebase as a command >line parameter. An RMI server uses the codebase property as a means to > annotate serialized objects as to where to get the class clode for it. I'm sure >this can be adapted somehow. I'm not sure how tied to rmi/jini it is but I'm > pretty sure it can be dealt with. > > Glenn > > "Glenn A. Thompson" wrote: > > > whoops I sent this to Charles only > > > > "Glenn A. Thompson" wrote: > > > > > Hi folks: > > > > > > I want to weigh in on this whole java thread. > > > I write all my applications in java now. The AWT is the massive portion of > > > the java runtime. > > > The standard jre may be a good place to start but a bad place to end. > > > As Charles has stated the original Java (I forget the name) was for imbedded > > > processing in consumer devices. That is how I became interested in java. It > > > was quickly hi-jacked (pardon the term) by the internet community. > > > > > > For the long term look at Java micro edition (J2ME), C virtual machine (CVM), > > > and Foundation Profile. There are docs on java.sun.com. I think I remember > > > someone mentioned using java1.x. I strongly advise against it. Java 2 is > > > very mature contrary to the beliefs of some folks. Java 1 should have been > > > killed off by now. > > > > > > As for using standard distributions, one lean approach is to use the class > > > loader to do your work. One feature of java that is often overlooked is the > > > ability to load the classes over the network as needed on a class by class > > > basis. This is used in jini/RMI applications extensively. If you haven't > > > checked into Jini; Do it. It is a really cool architecture. In fact it could > > > be the basis for what you propose to do with java. (Licensing could become an > > > issue. Sun is trying to control it very carefully.) You could put the VM and > > > some base classes on a floppy and then load classes from an internal secure > > > web server right into process space. Java has a built in ability to load > > > classes from a web server. You could provide most if not all the classes in > > > the form of a jar file available on the network via http. The jini toolkit > > > comes with a simple http server that can serv up jar files rather easily. > > > Good for testing. All you have to do is set the codebase of the VM at > > > startup. Or if your are really hard core you can write your own class loader > > > or loaders to do just about anything. Boxes that run java will have to be in > > > the 64-128 MB range to work well. > > > > > > I'm a little over booked but I will help if you can identify specific things > > > you want done. I'm more of a server side java guy so AWT/Swing work is not > > > where I would want to help. > > > > > > Anyway, thats my two cents worth > > > > > > Glenn Thompson > > > > > > Charles Steinkuehler wrote: > > > > > > > > > Is there interest in massive applications in general? > > > > > > > > > > Massive but not rediculous. Perl and java are useful but > > > > > large. A LEAF box with them gets closer and closer to > > > > > being a full distro, minus the x-windows. Certainly > > > > > the user would need a cdrom based LEAF. I'd like to > > > > > see java2, but only the jre. God only knows how well > > > > > that'll work on a crippled Linux box :) > > > > > > > > I'd like to see how small this could get as well. Java was initially > > > > intended to run on embedded systems, but got co-opted for internet use due > > > > to it's "run anywhere" nature. Ideally, I'd like to see something small > > > > enough to be included by default on all releases, even floppies. In the > > > > "good old days", you could run a forth interpreter in a couple of K...it > > > > seems like a run-time virtual machine *should* be able to fit on a floppy, > > > > especially since we've already got the glibc libraries to do most of the > > > > "grunt work". > > > > > > > > My goal with a JRE/interpreter/virtual machine would be to make *really > > > > small*, yet powerful programs, enabling things like a comlex package > > > > manager, configuration system, web configuration/status magaer, etc. The > > > > programs would be edited & compiled on a development system, and only the > > > > binary or "byte-code" would actually be required. The point of useing a > > > > virtual environment like Java would be to save space overall...you have to > > > > add the size of the run-time interpreter, but you can do powerful things > > > > with small amounts of code. > > > > > > > > Java seems like a good choice, if the basic JRE can be made small enough, > > > > but it's not the only choice. The existing ash shell is a good example of > > > > one possibility, but it's lacking a bit of power/flexability. There are > > > > many other scripting languages that are possible candidates. > > > > > > > > Charles Steinkuehler > > > > http://lrp.steinkuehler.net > > > > http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) > > > > > > > > _______________________________________________ > > > > Leaf-user mailing list > > > > [EMAIL PROTECTED] > > > > https://lists.sourceforge.net/lists/listinfo/leaf-user > > > > ------------------------------------------------------------------------ > > > > Subject: Re: [Leaf-user] DCD & java ??? > > Date: Tue, 05 Feb 2002 12:29:44 -0500 > > From: "Glenn A. Thompson" <[EMAIL PROTECTED]> > > Reply-To: [EMAIL PROTECTED] > > Organization: Central Digital Resources > > To: Charles Steinkuehler <[EMAIL PROTECTED]> > > References: <[EMAIL PROTECTED]> ><[EMAIL PROTECTED]> <095c01c1ae5e$40bb2550$4101220a@csteinathlon> > > > > Hi folks: > > > > I want to weigh in on this whole java thread. > > I write all my applications in java now. The AWT is the massive portion of > > the java runtime. > > The standard jre may be a good place to start but a bad place to end. > > As Charles has stated the original Java (I forget the name) was for imbedded > > processing in consumer devices. That is how I became interested in java. It > > was quickly hi-jacked (pardon the term) by the internet community. > > > > For the long term look at Java micro edition (J2ME), C virtual machine (CVM), > > and Foundation Profile. There are docs on java.sun.com. I think I remember > > someone mentioned using java1.x. I strongly advise against it. Java 2 is > > very mature contrary to the beliefs of some folks. Java 1 should have been > > killed off by now. > > > > As for using standard distributions, one lean approach is to use the class > > loader to do your work. One feature of java that is often overlooked is the > > ability to load the classes over the network as needed on a class by class > > basis. This is used in jini/RMI applications extensively. If you haven't > > checked into Jini; Do it. It is a really cool architecture. In fact it could > > be the basis for what you propose to do with java. (Licensing could become an > > issue. Sun is trying to control it very carefully.) You could put the VM and > > some base classes on a floppy and then load classes from an internal secure > > web server right into process space. Java has a built in ability to load > > classes from a web server. You could provide most if not all the classes in > > the form of a jar file available on the network via http. The jini toolkit > > comes with a simple http server that can serv up jar files rather easily. > > Good for testing. All you have to do is set the codebase of the VM at > > startup. Or if your are really hard core you can write your own class loader > > or loaders to do just about anything. Boxes that run java will have to be in > > the 64-128 MB range to work well. > > > > I'm a little over booked but I will help if you can identify specific things > > you want done. I'm more of a server side java guy so AWT/Swing work is not > > where I would want to help. > > > > Anyway, thats my two cents worth > > > > Glenn Thompson > > > > Charles Steinkuehler wrote: > > > > > > > Is there interest in massive applications in general? > > > > > > > > Massive but not rediculous. Perl and java are useful but > > > > large. A LEAF box with them gets closer and closer to > > > > being a full distro, minus the x-windows. Certainly > > > > the user would need a cdrom based LEAF. I'd like to > > > > see java2, but only the jre. God only knows how well > > > > that'll work on a crippled Linux box :) > > > > > > I'd like to see how small this could get as well. Java was initially > > > intended to run on embedded systems, but got co-opted for internet use due > > > to it's "run anywhere" nature. Ideally, I'd like to see something small > > > enough to be included by default on all releases, even floppies. In the > > > "good old days", you could run a forth interpreter in a couple of K...it > > > seems like a run-time virtual machine *should* be able to fit on a floppy, > > > especially since we've already got the glibc libraries to do most of the > > > "grunt work". > > > > > > My goal with a JRE/interpreter/virtual machine would be to make *really > > > small*, yet powerful programs, enabling things like a comlex package > > > manager, configuration system, web configuration/status magaer, etc. The > > > programs would be edited & compiled on a development system, and only the > > > binary or "byte-code" would actually be required. The point of useing a > > > virtual environment like Java would be to save space overall...you have to > > > add the size of the run-time interpreter, but you can do powerful things > > > with small amounts of code. > > > > > > Java seems like a good choice, if the basic JRE can be made small enough, > > > but it's not the only choice. The existing ash shell is a good example of > > > one possibility, but it's lacking a bit of power/flexability. There are > > > many other scripting languages that are possible candidates. > > > > > > Charles Steinkuehler > > > http://lrp.steinkuehler.net > > > http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) > > > > > > _______________________________________________ > > > Leaf-user mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/leaf-user > > _______________________________________________ > Leaf-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/leaf-user _______________________________________________ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
