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]
>
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
