Innovation API
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/jdk1.3/jre/lib/i386 -Ljava invoke.c it give me errors. 1. Is it -ljava or -Ljava? Both give me different errors. 2.-ljava as shown in the URL give me errors like usr/java/jdk1.3/jre/lib/i386/libjava.so : undefined JVM_StartThread. What is this mean? 3. The example can be run in jdk1.3? Thank you. With Regards soonho
Re: JRE as part of Linux
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 and keep it running, so that when > > the user starts an Java application java is already there and start time is > > shortened. One of the reasons lots of users avoid java is because even the > > simplest application loads several times slower than its naive ecuivalent. > > I know about the kernel module that invokes JRE when you exec a java .class > > file(with appropriate +x permission). But it doesn't keep JVM is not resident. > > We have the same problem with just about all of the non-native/interpreted > code run under Linux (i.e., Perl, Python, etc). I think something like > that would severely impact performance of the kernel. > > But something like that would be cool for an embedded application, like > for a hardware appliance. I thought there was a JVM available as a kernel module? (KissVM?) And don't you think that running a JVM as part of a Linux kernel is a waste of resources? Why not the kernel on top of the JVM? I thought that's what the JOS project is aiming for... Ciao, Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Innovation API
> "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 soonho> gcc -I/usr/java/jdk1.3/include -I/usr/java/jdk1.3/include/linux soonho> -L/-I/usr/java/jdk1.3/jre/lib/i386 -Ljava invoke.c soonho> it give me errors. soonho> 1. Is it -ljava or -Ljava? Both give me different errors. It's -ljvm. Our J2SDK includes a script "j2sdk-config" which will give you the right values for your installation. E.g. % j2sdk-config --cflags -D_REENTRANT -D_GNU_SOURCE -I/usr/lib/j2sdk1.3/include -I/usr/lib/j2sdk1.3/include/linux % j2sdk-config --libs -L/usr/lib/j2re1.3/lib/i386/client -ljvm -lpthread BTW, there's an Invocation API example in our FAQ http://www.blackdown.org/java-linux/docs/support/faq-release/examples/invocation-in-C++/ Juergen -- Juergen Kreileder, Blackdown Java-Linux Team http://www.blackdown.org/java-linux.html JVM'01: http://www.usenix.org/events/jvm01/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JRE as part of Linux
> "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 >> > embedding I mean starting it at system boot or the first time >> > it's needed and keep it running, so that when the user starts >> > an Java application java is already there and start time is >> > shortened. One of the reasons lots of users avoid java is >> > because even the simplest application loads several times >> > slower than its naive ecuivalent. I know about the kernel >> > module that invokes JRE when you exec a java .class file(with >> > appropriate +x permission). But it doesn't keep JVM is not >> > resident. >> >> We have the same problem with just about all of the >> non-native/interpreted code run under Linux (i.e., Perl, >> Python, etc). I think something like that would severely >> impact performance of the kernel. Nathan> It definitely wouldn't be welcome by the kernel team.:-). Nathan> I think what you're looking for is an application server Nathan> that can be started early (perhaps by a Linux startup Nathan> script) and handle requests for classes to load and Nathan> run. There are a lot of challenges to doing this well, and Nathan> nearly impossible when dealing with GUI apps... but it's Nathan> possible if you make enough simplifying assumptions :-). 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/ Juergen -- Juergen Kreileder, Blackdown Java-Linux Team http://www.blackdown.org/java-linux.html JVM'01: http://www.usenix.org/events/jvm01/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JRE as part of Linux
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 story with an open source kernel. -- Brett http://www.chapelperilous.net/~bmccoy/ --- "In my opinion, Richard Stallman wouldn't recognise terrorism if it came up and bit him on his Internet." -- Ross M. Greenberg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JRE as part of Linux
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 java because of licencing problems, but on the other hand i think it would be really interresting to integrate java and linux. cu, br1 |- | subnet | network for media, art and experiment |- | http://www.subnet.at/ |- Yavor Kolarov wrote: > > Hello > > 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 starts an Java application java is already there and start time is > shortened. One of the reasons lots of users avoid java is because even the > simplest application loads several times slower than its naive ecuivalent. > I know about the kernel module that invokes JRE when you exec a java .class > file(with appropriate +x permission). But it doesn't keep JVM is not resident. > > fYavor > > -- > 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
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 starts an Java application java is already there and start time is > shortened. One of the reasons lots of users avoid java is because even the > simplest application loads several times slower than its naive ecuivalent. > I know about the kernel module that invokes JRE when you exec a java .class > file(with appropriate +x permission). But it doesn't keep JVM is not resident. There are some very good reasons to keep as much out of the kernel as possible. But, there is no reason this kind of thing can't be done in user-space. I have reason to believe (a combination of a few different resources) that we'll be seeing a lot of effort made in this direction by Sun in upcoming releases (it may end up being post 1.4, but it's definately under consideration). If you think about this, what you really want is to be able to share things between JVM's, and then let the OS cache that (or keep one VM running). What might be shared in a VM? Classfile bytes in memory. The JIT'ed version of those classes. The VM libraries themselves are already cached, of course - but if we were to have a system to cache even just java.* and javax.* classes (and their JIT equivalents), we'll have a *much* faster startup time. Sun may not have bothered, but pretty soon they're going to be compared to .NET. And Microsofts implementation will have a fast startup time & cache / share all this stuff, because that's what they do. (Compare IE load times vs Netscape. Remember the complaints that it was because IE is half in memory all the time? The answer, of course, is 'who cares?' - it still starts in 50%/20%/10% of the time) Not quite pure speculation on my part, but close. ;) Paul -- Paul Mclachlan ([EMAIL PROTECTED]) Software Engineer, Java Tools. NuMega Lab, Compuware corp. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JRE as part of Linux
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 Linux. And GNU is working on it's own Java implementation (Japhar + Classpath). Maybe we'll see such a integration when those projects are usable. Ciao, Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Does -Xrunhprof work correctly with Hotspot? Or does -green turn HotSpot off?
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 HotSpot. I was hoping that one of the JVM experts might respond to your question. Nathan Meyers wrote an article on profiling an provides a tool for assisting in the analysis. He also covers this in his book. I found both very helpful and been able to use his tool to help me analyze my results. Unfortunately, I did not keep the URL but it should be in the archives. Cynthia Jeness Barnet Wagman wrote: Orson Alvarez wrote: Hi Barnet, Have you received any responses to this query? I received the same error with: java version "1.3.0rc1" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0rc1-b17) Java HotSpot(TM) Client VM (build 1.3.0rc1-b17, mixed mode) I looked up the problem on the JDC bug parade and they say it's fixed due to the fix for bug 4379126. However, that bug has been taken off the bug parade listing "due to security reasons". Additionally, the entry for this bug states that the bug is "closed,fixed" in a "non-public release". I looked for pre-release versions on JDC and found nothing. Some of the workarounds were to use blackdown and now I see your posting. Very discouraging to say the least. Fraid not. And I haven't found any documentation on using the profiler, other than what we get from '$java3 -Xrunhprof:help' On top of all this I downloaded the "fcs" version and RH's rpm won't install it because it thinks the "rc1" version is newer. Frustrating... At any rate let me know if you hear anything. Thanks, O I've given up using rpms for Java precisely for this reason. With tarball installations, its easy to have multiple versions on one system (I have at least four at present). Good luck.
Re: JRE as part of Linux
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]
Re: JRE as part of Linux
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 down. So I have to cut and paste this into this mail: === Subject: [JOS-Kernel] kissme JVM + linux kernel Reply-To: [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] X-Mailman-Version: 1.1 Precedence: bulk List-Id: Nuts and Bolts X-BeenThere: [EMAIL PROTECTED] X-UIDL: a2ea29a7c367bb5b1187cc448e0ace9c Status: RO X-Status: O I've managed to compile my kissme JVM as a kernel module and load it into the Linux kernel. This took me 3 days, I only made changes necessary to get it to run a hello world program, there is a lot of other broken stuff. My aim with doing this was to get a workable "kernel+JVM" implementation running. I don't want to debate the merits/demerits of using Linux as a kernel. Next I plan to neaten up the code a bit, probably get garbage collection working, and implement linux kernel threads as native java threads. Interesting stuff that can be explored from here: Use the linux frame buffer to start writing window managers, 2D apis for video. Use the device drivers to write network stacks, file systems. Resurrect some kind of virtual terminal and establish a shell. Anyone who is interested in testing / hacking, or just wants to ask questions please mail me. John Leuner === Ciao, Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JRE as part of Linux
> "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.com/10xmore/ Brett> But I'm sure they have done it under license and NDA. It's Brett> a different story with an open source kernel. I don't think you have to modify the kernel to achieve this. Juergen -- Juergen Kreileder, Blackdown Java-Linux Team http://www.blackdown.org/java-linux.html JVM'01: http://www.usenix.org/events/jvm01/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Does -Xrunhprof work correctly with Hotspot? Or does -green turn HotSpot off?
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 Linux and that this is required to > generate profiling with HotSpot. I was hoping that one of the JVM > experts might respond to your question. Hotspot caused lots of problems with JVMPI, there were something in the range of 5 or 6 unique bugs (some 'doesn't work', some 'crashes', etc) logged against 1.3, I expect, mostly by companies producing products that rely upon JVMPI. I know that Sun was under a lot of pressue from these companies to fix this ASAP - if I'd been in their situation (I nearly was) I'd have been screaming my head off, too. Short answer: wait for 1.3.1 to make it to beta / early access - at the moment it's only available within Sun and a few companies Sun allows to access such things. Most of these bugs have been fixed in that (already). Until then, turn off hotspot if you want to do this kind of thing. Paul -- Paul Mclachlan ([EMAIL PROTECTED]) Software Engineer, Java Tools. NuMega Lab, Compuware corp. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Does -Xrunhprof work correctly with Hotspot? Or does -green turn HotSpot off?
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 required to > generate profiling with HotSpot. I was hoping that one of the JVM > experts might respond to your question. > > Nathan Meyers wrote an article on profiling an provides a tool for > assisting in the analysis. He also covers this in his book. I found > both very helpful and been able to use his tool to help me analyze my > results. Unfortunately, I did not keep the URL but it should be in > the archives. The article's here: http://developer.java.sun.com/developer/technicalArticles/GUI/perfanal/ Linux is one of the few environments in which profiling is even possible with JDK1.3, and even then only with the -classic (green threads) JVM. The tool discussed in the article processes the hprof cpu=samples results into something much more useful than the raw data, and presents it through a Swing-based interface. Article and code available without buying the book :-). Nathan > > > Cynthia Jeness > > Barnet Wagman wrote: > >> Orson Alvarez wrote: >> >> > Hi Barnet, >> > >> > Have you received any responses to this query? I received the same >> > error >> > with: >> > >> > java version "1.3.0rc1" >> > Java(TM) 2 Runtime Environment, Standard Edition (build >> > 1.3.0rc1-b17) >> > Java HotSpot(TM) Client VM (build 1.3.0rc1-b17, mixed mode) >> > >> > I looked up the problem on the JDC bug parade and they say it's >> > fixed >> > due to the fix for bug 4379126. However, that bug has been taken >> > off the >> > bug parade listing "due to security reasons". Additionally, the >> > entry >> > for this bug states that the bug is "closed,fixed" in a "non-public >> > >> > release". I looked for pre-release versions on JDC and found >> > nothing. >> > Some of the workarounds were to use blackdown and now I see your >> > posting. Very discouraging to say the least. >> > >> >> Fraid not. And I haven't found any documentation on using the >> profiler, other than what we get from '$java3 -Xrunhprof:help' >> >> > >> > On top of all this I downloaded the "fcs" version and RH's rpm >> > won't >> > install it because it thinks the "rc1" version is newer. >> > Frustrating... >> > >> > At any rate let me know if you hear anything. >> > >> > Thanks, >> > O >> >> I've given up using rpms for Java precisely for this reason. With >> tarball installations, its easy to have multiple versions on one >> system (I have at least four at present). >> >> Good luck. > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
XML Parser for Java Version 3.1.1 Release is now available
--<<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 Schema implementations but these are considered experimental, as the specifications themselves are still subject to change. XML4J-3_1_1 contains a number of optimizations designed to improve performance as compared with XML4J-3_1_0. It is also more robust with regard to thread safety. In all other respects, XML4J-3_1_1 behaves like XML4J-3_1_0. Download http://alphaworks.ibm.com/tech/xml4j?open&l=xmllst04,t=gr,p=XML4J --<<0>>-- developerWorks Japan - XML Zone http://www.alphaworks.ibm.com/aw.nsf/html/,t-gr,p=Japan-XML Go to the developerWorks XML Zone to find articles, white-papers, and tutorials written in Japanese. Here are new articles just released: >From text to byte code - Data binding from XML to Java, Part 3 http://www.jp.ibm.com/developerworks/xml/010119/j_data-binding3.html?open&l=xmllst04,t=gr,p=dbind e-Business, XML, Web Serveses, UDDI and B2B http://www.jp.ibm.com/developerworks/webservices/010119/b2b.html?open&l=xmllst04,t=gr,p=UDDI --<<0>>-- How SOAP works - The Web services (r)evolution, Part 3 This article provides an explanation of how SOAP works, including information about its on-the-wire protocol and how messages are processed. It also explains how objects can be passed by value between Web services, and touches on performance and security issues. Complete Article http://www-106.ibm.com/developerworks/library/ws-peer3/index.html?open&l=xmllst04,t=gr,p=SOAP --<<0>>-- The missing link Will ebXML bring true global B2B? The United Nation and the OASIS group have joined together as unlikely allies in the ongoing turf war over B2B standards. Offering a new set of XML-based specification, ebXML makes the bold promise to enable a single global electronic marketplace. Complete Article http://www-106.ibm.com/developerworks/library/ws-ebxml.html?open&l=xmllst04,t=gr,p=ebXML --<<0>>-- WSDL processing with XSLT This article shows ways of using Extensible Stylesheet Language for Transforms (XSLT) to process WSDL in various ways. Familiarity with XSLT and Resource Description Framework (RDF) are required. Resources introducing XSLT are provided. Complete Article http://www-106.ibm.com/developerworks/library/ws-trans/index.html?open&l=xmllst04,t=gr,p=XSLT --<<0>>-- Applying Web services to the application service provider environment This article offers a brief introduction to the architectural principles underlying Web services, as well as some of the technologies that support them. This article primarily presents an example of how Web services can be applied to an application service provider environment. Complete Article http://www-106.ibm.com/developerworks/library/ws-wsasp/?open&l=xmllst04,t=gr,p=WebServices --<<0>>-- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
