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
