Hi all,
I currently using jdk1.3 in my RedHat 6.1. I am
testing the invoke.c example in the following URL:
http://www.java.sun.com/docs/books/tutorial/native1.1/invoking/invo.html
But when compile using
gcc -I/usr/java/jdk1.3/include
-I/usr/java/jdk1.3/include/linux -L/-I/usr/java/jdk
Hi!
On Don, 18 Jan 2001 Brett W. McCoy wrote:
> On Thu, 18 Jan 2001, Yavor Kolarov wrote:
>
> > Recently an interesting question crossed my mind - is there a project for
> > "emedding" JRE as part of Linux system. By embedding I mean starting it at
> > system boot or the first time it's needed a
> "soonho" == soonho <[EMAIL PROTECTED]> writes:
soonho> I currently using jdk1.3 in my RedHat 6.1. I am testing
soonho> the invoke.c example in the following URL:
soonho> http://www.java.sun.com/docs/books/tutorial/native1.1/invoking/invo.html
soonho> But when compile using
> "Nathan" == Nathan Meyers <[EMAIL PROTECTED]> writes:
Nathan> "Brett W. McCoy" wrote:
>>
>> On Thu, 18 Jan 2001, Yavor Kolarov wrote:
>>
>> > Recently an interesting question crossed my mind - is there a
>> > project for "emedding" JRE as part of Linux system. By
On 19 Jan 2001, Juergen Kreileder wrote:
> Yes, a "simplified" implementation isn't too hard but a complete
> implementation isn't trivial.
> BTW, SCO has done this for Solaris and UnixWare:
> http://www.sco.com/10xmore/
But I'm sure they have done it under license and NDA. It's a different
sto
hello!
i also thought of a similar thing - would'nt it be cool to have java
wrappers around the linux kernel and the system calls - so that you can
access them in java? also a java shell would be nice (java instead of
shell-scripts!).
i understand the reluctance of the linux community to use jav
At 21:58 01 Jan 2001 +0200, Yavor Kolarov wrote:
> Recently an interesting question crossed my mind - is there a project for
> "emedding" JRE as part of Linux system. By embedding I mean starting it at
> system boot or the first time it's needed and keep it running, so that when
> the user sta
Hi!
On Fre, 19 Jan 2001 Bruno Randolf wrote:
> i understand the reluctance of the linux community to use java because
> of licencing problems, but on the other hand i think it would be really
> interresting to integrate java and linux.
Don't forget that the GNU utils are a huge part of Li
You can generate the profiling information by specifying "-classic"., but
you probably already know this. I am also somewhat puzzled
by closing the bug and the associated explanation. My take was that
"raw-monitor" was not suppored in Linux and that this is required to generate
profiling with
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 spac
Hi!
On Fre, 19 Jan 2001 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.
Sorry, the JOS mailing is
> "Brett" == Brett W McCoy <[EMAIL PROTECTED]> writes:
Brett> On 19 Jan 2001, Juergen Kreileder wrote:
>> Yes, a "simplified" implementation isn't too hard but a complete
>> implementation isn't trivial.
>> BTW, SCO has done this for Solaris and UnixWare:
>> http://www.sco
At 10:58 01 Jan 2001 -0500, Cynthia Jeness wrote:
> You can generate the profiling information by specifying "-classic".,
> but you probably already know this.I am also somewhat puzzled by
> closing the bug and the associated explanation. My take was that
> "raw-monitor" was not suppored in
Cynthia Jeness wrote:
> You can generate the profiling information by specifying "-classic".,
> but you probably already know this.I am also somewhat puzzled by
> closing the bug and the associated explanation. My take was that
> "raw-monitor" was not suppored in Linux and that this is requi
--<<0>>--
XML Parser for Java Version 3.1.1 Release (XML4J-3_1_1) is now available
This release contains public and stable support of the DOM Level 1, and SAX
Level 1 specifications. It also contains implementations of the DOM Level
2, SAX Level 2 implementations, and partial April 7 W3C Schem
15 matches
Mail list logo