Re: Fwd: Re: JRE as part of Linux
Yavor Kolarov wrote: > > There are some additional problems. > > If we have a wrapper starting all programs it has to be able to: > - open news windows and frames on a specific X terminal. ( User A running > Java application on localhost:0.0 and user B on localhost:1.0) > This raises the question: > Is it possible to choose(under Linux) on which X terminal to draw graphics? This is one of the biggest problems in implementing an app server that can handle arbitrary programs -- and why real app servers work in highly constrained environments like servlets or EJB. The problem is that the connection to the X display happens when the AWT native library is first loaded. It's a single connection that is used through the life of the JVM. As currently structured, the AWT won't let you associate different objects with different X connections. It would take some work (possibly deep architectural rework) on the AWT to do what you're asking. Nathan > > - for terminal apps it should be possible to do I/O on different ttys. This > should be easier to solve since it only requires redirection of two streams. > > Yavor > > On Friday 19 January 2001 19:34, Yavor Kolarov wrote: > > Thanks to everyone who replied! > > > > It is clear that JVM can't be part of the kernel. Because of three main > > reasons: > > 1. Java is not GPL'ed > > 2. the more code in the kernel the worse. Java is too big and not so > > stable. > > > > Here is one possible design: > > > > 1. At boot time a wrapper is started in the user space as root. It may be > > written in Java with some native code if needed. > > Running the wrapper as root raises a serious security problem [1]. > > > > 2. When we want to start a java program we make a request to the wrapper. > > It loads/reloads the class from the requested a .class file in the user's > > CLASSPATH and calls its Main(String args[]) in a new thread. Here there are > > two problems: > > - if the class is loaded and then changed what we need to reload it [2]. > > - if we reload the class and what happens to another application which > > uses an old version ov the class? [3] > > - we have to solve the problem of different CLASSPATHs of different > > applications.[4] > > > > [1] This can be solved with a good SecurityManager which checks all that > > the kernel checks when running user applications: file permissions, ports < > > 1024. The alternative is have a C wrapper which fork(), chuid() - now user > > security applies and runs java. I have to say that I don't have experience > > with JNI. Is there a really cheap way to start JVM from C or add a thread > > to running JVM? > > > > [2] Maybe ClassLoader.findClass(String) or . loadClass(String) can do the > > trick? > > > > [3] and [4] remain open questions > > > > Of course there are surely more problems. These were the only I see but I > > don't know the internals of the JVM. > > > > Also thanks for pointing me to kissme(http://kissme.sourceforge.net/). It > > is an VM with an interesting feature - persistence: > > > > "Supports an extension to the JVM allowing persistent java, which means > > that the JVM allows in-memory data structures to automagically persist to > > permanent storage" > > > > "The persistence abstraction allows the creation and manipulation of data > > in a manner that is independent of its lifetime thereby integrating the > > database view of information with the programming language view." > > > > There is also a link to another persistent Java project - > > PJama(http://www.dcs.glasgow.ac.uk/pjava/) > > > > However I didn't see in the feature list something like JVM shared between > > applications. > > > > Yavor > > --- > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JRE as part of Linux
Yavor Kolarov wrote: > > Thanks to everyone who replied! > > It is clear that JVM can't be part of the kernel. Because of three main > reasons: > 1. Java is not GPL'ed > 2. the more code in the kernel the worse. Java is too big and not so stable. > You don't want different people sharing the jvm because of security issues. Past incidents have shown that sun isn't very security concious with the jvm. What is really needed is a pre-started jvm. When you start up a java process, the jvm will fork, and the child will su to you and proceed as normal. I don't know exactly what the jvm is doing when it is taking all that time starting up so I don't know how useful this would be. -- Joseph Shraibman [EMAIL PROTECTED] Increase signal to noise ratio. http://www.targabot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Re: JRE as part of Linux
you know, it would probably make a whole lot more sense to integrate the jvm with something like gnome or kde rather than with the operating system itself. that way you skip the various xdisplay problems (since you'll necessarily have an x environment associated with your session) and you don't have suid problems (since it should only be for one user). admittedly, this wouldn't help much for running remote clients, or with running text-based apps without an x environment... still, the time that most people notice slow startup times is when they're trying to start up gui apps in java, and it would handle that case. just a thought. -allen [EMAIL PROTECTED] On Tue, Jan 23, 2001, 14:11, Nathan Meyers <[EMAIL PROTECTED]> wrote >Yavor Kolarov wrote: >> >> There are some additional problems. >> >> If we have a wrapper starting all programs it has to be able to: >> - open news windows and frames on a specific X terminal. ( User A running >> Java application on localhost:0.0 and user B on localhost:1.0) >> This raises the question: >> Is it possible to choose(under Linux) on which X terminal to draw graphics? > >This is one of the biggest problems in implementing an app server that >can handle arbitrary programs -- and why real app servers work in highly >constrained environments like servlets or EJB. > >The problem is that the connection to the X display happens when the AWT >native library is first loaded. It's a single connection that is used >through the life of the JVM. As currently structured, the AWT won't let >you associate different objects with different X connections. It would >take some work (possibly deep architectural rework) on the AWT to do >what you're asking. > >Nathan > > >> >> - for terminal apps it should be possible to do I/O on different ttys. This >> should be easier to solve since it only requires redirection of two streams. >> >> Yavor >> >> On Friday 19 January 2001 19:34, Yavor Kolarov wrote: >> > Thanks to everyone who replied! >> > >> > It is clear that JVM can't be part of the kernel. Because of three main >> > reasons: >> > 1. Java is not GPL'ed >> > 2. the more code in the kernel the worse. Java is too big and not so >> > stable. >> > >> > Here is one possible design: >> > >> > 1. At boot time a wrapper is started in the user space as root. It may be >> > written in Java with some native code if needed. >> > Running the wrapper as root raises a serious security problem [1]. >> > >> > 2. When we want to start a java program we make a request to the wrapper. >> > It loads/reloads the class from the requested a .class file in the user's >> > CLASSPATH and calls its Main(String args[]) in a new thread. Here there are >> > two problems: >> > - if the class is loaded and then changed what we need to reload it [2]. >> > - if we reload the class and what happens to another application which >> > uses an old version ov the class? [3] >> > - we have to solve the problem of different CLASSPATHs of different >> > applications.[4] >> > >> > [1] This can be solved with a good SecurityManager which checks all that >> > the kernel checks when running user applications: file permissions, ports < >> > 1024. The alternative is have a C wrapper which fork(), chuid() - now user >> > security applies and runs java. I have to say that I don't have experience >> > with JNI. Is there a really cheap way to start JVM from C or add a thread >> > to running JVM? >> > >> > [2] Maybe ClassLoader.findClass(String) or . loadClass(String) can do the >> > trick? >> > >> > [3] and [4] remain open questions >> > >> > Of course there are surely more problems. These were the only I see but I >> > don't know the internals of the JVM. >> > >> > Also thanks for pointing me to kissme(http://kissme.sourceforge.net/). It >> > is an VM with an interesting feature - persistence: >> > >> > "Supports an extension to the JVM allowing persistent java, which means >> > that the JVM allows in-memory data structures to automagically persist to >> > permanent storage" >> > >> > "The persistence abstraction allows the creation and manipulation of data >> > in a manner that is independent of its lifetime thereby integrating the >> > database view of information with the programming language view." >> > >> > There is also a link to another persistent Java project - >> > PJama(http://www.dcs.glasgow.ac.uk/pjava/) >> > >> > However I didn't see in the feature list something like JVM shared between >> > applications. >> > >> > Yavor >> >> --- >> >> -- >> To UNSUBSCRIBE, email to [EMAIL PROTECTED] >> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > >-- >To UNSUBSCRIBE, email to [EMAIL PROTECTED] >with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -
Re: Fwd: Re: JRE as part of Linux
allen petersen wrote: > > you know, it would probably make a whole lot more sense to integrate the jvm > with something like gnome or kde rather than with the operating system itself. > that way you skip the various xdisplay problems (since you'll necessarily have > an x environment associated with your session) and you don't have suid problems > (since it should only be for one user). admittedly, this wouldn't help much > for running remote clients, or with running text-based apps without an x > environment... still, the time that most people notice slow startup times is > when they're trying to start up gui apps in java, and it would handle that > case. > > just a thought. And an excellent one at that. The desktops have evolved into providers of significant services... adding a Java service fits, and solves some big problems. It will take some thought to do it well - to integrate with the desktops' object model in the most effective and natural way - but doing so should provide a solution to some of the other problems you mentioned. Nathan > > -allen > [EMAIL PROTECTED] > > On Tue, Jan 23, 2001, 14:11, Nathan Meyers <[EMAIL PROTECTED]> wrote > >Yavor Kolarov wrote: > >> > >> There are some additional problems. > >> > >> If we have a wrapper starting all programs it has to be able to: > >> - open news windows and frames on a specific X terminal. ( User A running > >> Java application on localhost:0.0 and user B on localhost:1.0) > >> This raises the question: > >> Is it possible to choose(under Linux) on which X terminal to draw graphics? > > > >This is one of the biggest problems in implementing an app server that > >can handle arbitrary programs -- and why real app servers work in highly > >constrained environments like servlets or EJB. > > > >The problem is that the connection to the X display happens when the AWT > >native library is first loaded. It's a single connection that is used > >through the life of the JVM. As currently structured, the AWT won't let > >you associate different objects with different X connections. It would > >take some work (possibly deep architectural rework) on the AWT to do > >what you're asking. > > > >Nathan > > > > > >> > >> - for terminal apps it should be possible to do I/O on different ttys. This > >> should be easier to solve since it only requires redirection of two > streams. > >> > >> Yavor > >> > >> On Friday 19 January 2001 19:34, Yavor Kolarov wrote: > >> > Thanks to everyone who replied! > >> > > >> > It is clear that JVM can't be part of the kernel. Because of three main > >> > reasons: > >> > 1. Java is not GPL'ed > >> > 2. the more code in the kernel the worse. Java is too big and not so > >> > stable. > >> > > >> > Here is one possible design: > >> > > >> > 1. At boot time a wrapper is started in the user space as root. It may be > >> > written in Java with some native code if needed. > >> > Running the wrapper as root raises a serious security problem [1]. > >> > > >> > 2. When we want to start a java program we make a request to the wrapper. > >> > It loads/reloads the class from the requested a .class file in the user's > >> > CLASSPATH and calls its Main(String args[]) in a new thread. Here there > are > >> > two problems: > >> > - if the class is loaded and then changed what we need to reload it > [2]. > >> > - if we reload the class and what happens to another application > which > >> > uses an old version ov the class? [3] > >> > - we have to solve the problem of different CLASSPATHs of different > >> > applications.[4] > >> > > >> > [1] This can be solved with a good SecurityManager which checks all that > >> > the kernel checks when running user applications: file permissions, ports > < > >> > 1024. The alternative is have a C wrapper which fork(), chuid() - now > user > >> > security applies and runs java. I have to say that I don't have > experience > >> > with JNI. Is there a really cheap way to start JVM from C or add a thread > >> > to running JVM? > >> > > >> > [2] Maybe ClassLoader.findClass(String) or . loadClass(String) can do the > >> > trick? > >> > > >> > [3] and [4] remain open questions > >> > > >> > Of course there are surely more problems. These were the only I see but I > >> > don't know the internals of the JVM. > >> > > >> > Also thanks for pointing me to kissme(http://kissme.sourceforge.net/). It > >> > is an VM with an interesting feature - persistence: > >> > > >> > "Supports an extension to the JVM allowing persistent java, which means > >> > that the JVM allows in-memory data structures to automagically persist to > >> > permanent storage" > >> > > >> > "The persistence abstraction allows the creation and manipulation of data > >> > in a manner that is independent of its lifetime thereby integrating the > >> > database view of information with the programming language view." > >> > > >> > There is also a link to another persistent Java project - > >> > PJama(http://www.dcs.glasgow.ac.uk/pjava/)
