Re:
Yes, I have problems getting unsubscribed myself. Please remove me from mailinglist. my add. [EMAIL PROTECTED] or [EMAIL PROTECTED] Thanks. On Mon, 02 Nov 1998, [EMAIL PROTECTED] wrote: >You have not been removed, I couldn't find your name on the list. > >If this wasn't your intention or you are having problems getting yourself >unsubscribed, reply to this mail now (quoting it entirely (for diagnostic >purposes), and of course adding any comments you see fit). > >Transcript of unsubscription request follows: >-- >>From [EMAIL PROTECTED] Mon Nov 2 04:09:01 1998 >>Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by shell.ncm.com >(8.8.5/8.7.5) with SMTP id EAA30840 for <[EMAIL PROTECTED]>; Mon, >2 Nov 1998 04:09:00 -0500 >>Received: from tid.uio.no (actually tid.uio.no [129.240.84.18]) by pat.uio.no with >SMTP (PP); Mon, 2 Nov 1998 10:09:02 +0100 >>Received: from fyspc-elg054.uio.no (fyspc-elg054.uio.no [129.240.84.154]) by >tid.uio.no ; Mon, 2 Nov 1998 10:09:01 +0100 (MET) >>From: Ravindran Nagarajah <[EMAIL PROTECTED]> >>To: [EMAIL PROTECTED] >>Date: Mon, 2 Nov 1998 10:08:20 +0100 >>X-Mailer: KMail [version 0.7.9] >>Content-Type: text/plain >>MIME-Version: 1.0 >>Message-Id: <[EMAIL PROTECTED]> >>Content-Transfer-Encoding: 8bit >> >>Remove me from mailinglist. >> >>
Re: Newbie mySQL MkLinux and JDBC
What is your problem ? Compiling MySQL out of the box or Compiling a JDBC driver ? Why are trying to compile the JDBC driver? You should not need to compile it. The JDBC driver that I have come across have been precompiled. Therefore you should just install it on your system and set your CLASSPATH to refer to the zip or jar file accordingly. e.g. CLASSPATH=...:/usr/local/mysql/jdbc-driver-for-mysql.zip:... export CLASSPATH __ Reply Separator _ Subject: Newbie mySQL MkLinux and JDBC Author: dtbrown ([EMAIL PROTECTED]) at lon-mime Date:31/10/98 02:04 I'm a newbie, and I'm trying to install a JDBC drivable database engine on my MkLinux (DR3) machine. MySQL should do the trick, and I have configured the files without any trouble, but the compile fails. Is there anyone out there who has experience with this installation??? Thanks! DTB
Announcing JDK 1.1.7_v1a with Native Threads!
Hi, Here is our final port of JDK 1.1.7 with Native Threads! Both Scott and I have signed Steve Byrne's License to get 1.2 sources and will start its port soon. Here are the key parts of the release note (sorry for the length). Thanks, Your Blackdown JDK PPC Porters: Scott Hutinger and Kevin B. Hendricks New in this Port * This is our final port of Sun's JDK 1.1.7 final. - Native Threads support is HERE! - enable by: export THREADS_FLAG=native - please give a special thanks to Phill Edwards of the Blackdown Java-Linux team for creating the Native Threads port. Great job Phill! - fix for image scaling problem - fix for hanging stdout and stderr (green_threads) - fix for kernel accept() bug, caused slow Java Web Server - turn-off by: export JDK_NO_KERNEL_FIX=true Also a special thanks goes to Juergen Kreileder for almost all of the work to get the 1.1.6 diffs to work on 1.1.7 with no regressions! And thanks, of course, go to the Blackdown Porters in general for all of their valuable work in porting the JDK to Linux. Native Threads vs Green Threads --- This release includes both green and native threads. Green threads are user based theads that have been part of the JDK since its inception. Green threads are very stable, have a lower memory footprint, and involve much lower overhead for creation and context switching. Native threads are linux threads (one-to-one implementation of pthreads) and are kernel based. Each thread is basically a clone of the its parent process and therefore has a higher overhead for context switching and creation and a larger memory footprint. Because they are processes, the number of threads is limited by the number of processes/tasks built into the Linux kernel. You will have to recompile your kernel to handle larger number of threads. So why use native threads? Native threads deal better with some JNI native C programs than green_threads because you do not have to make all io non-blocking and therefore do not have to redefine all of the system calls related to io. But the main reason to use native threads is that on multi-processor systems, native threads can be easily split among processors greatly improving performance while green_threads can not. Although on single processor systems, green threads will probably be faster for most programs. Native Threads Requirements --- As a result of Phill Edwards hard work, we now have native threads support for the Linux JDK ports. The native threads port itself should be considered beta quality (or better). To make use of it you MUST upgrade to the following packages: - glibc (1m) (the very latest glibc from Gary Thomas with thread fixes) - X11R6.3 (1s) (the X11R6.3 (1r) rpms rebuilt with -D_RENTRANT - David Gatwood's latest MkLinux kernel/server pair or Paul's latest 2.1.24 kernel or Paul's latest 2.1.125 kernel All of these packages are available from the following mirror site: ftp://ftp.mklinux.apple.com/pub/contrib/JDK/ Note: The Metrowerks JIT has not been tested with the Native Threads port. If you run into problems, please try disabling it to see if the problem goes away an then either file a bug report on the JIT or the native threads. * * NOTE: In keeping with the Metrowerks binary license, the * * Metrowerks JIT is not longer shipped with the JDK and * * therefore is NOT installed by default. To use the JIT* * with the JDK please download the Metrowerks JIT binary* * archive and follow the instructions in the README.* * * This port is statically linked with Motif 2.1. * This port was developed under Sun's non-commercial license agreement. The home website is still: http://business.tyler.wm.edu/mklinux We hope you enjoy the numerous improvements available in JDK 117. We will continue to work to both improve the port and fix bugs. Thanks, Your MkLinux / Linux PowerPC JDK Porting Team Scott Hutinger and Kevin B. Hendricks -- Kevin B. Hendricks Associate Professor, Operations & Information Technology School of Business, College of William & Mary Williamsburg, VA 23187, [EMAIL PROTECTED] http://business.tyler.wm.edu
Re: Announcing JDK 1.1.7_v1a with Native Threads!
cool! Good work!
JFC Compilation still bothersome
Still having problems compiling
import com.sun.java.swing.*;
public class test extends JFrame{
public test(){
this.setSize(300,300);
this.setVisible(true);
}//end constructor
public static void main(String args[]){
new test();
}//end main
}//end class
ERROR:
test.java:2: Package com.sun.java.swing not found in import.
import com.sun.java.swing.*;
^
test.java:3: Superclass JFrame of class test not found.
public class test extends JFrame{
^
2 errors
I have tried using
import javax.java.*;
as well as having added swingall.jar and motif.jar?
I appreciate the help this far,
any more ideas?
Steve
Re: JFC Compilation still bothersome
No. Swing 1.0.3 should have the older com.sun.java.swing which is
correct.
I dont think the order of the swing and JDK jar file in the CLASSPATH
will make any difference, but perhaps you should put the `period'
`dot' at the front of your CLASSPATH .
Do you have somethin in your ~/.bashrc or equiv login sheel that is
redefining the CLASSPATH?
Pete
__ Reply Separator _
Subject: JFC Compilation still bothersome
Author: sgee ([EMAIL PROTECTED]) at lon-mime
Date:02/11/98 15:52
Still having problems compiling
import com.sun.java.swing.*;
public class test extends JFrame{
public test(){
this.setSize(300,300);
this.setVisible(true);
}//end constructor
public static void main(String args[]){
new test();
}//end main
}//end class
ERROR:
test.java:2: Package com.sun.java.swing not found in import.
import com.sun.java.swing.*;
^
test.java:3: Superclass JFrame of class test not found.
public class test extends JFrame{
^
2 errors
I have tried using
import javax.java.*;
as well as having added swingall.jar and motif.jar?
I appreciate the help this far,
any more ideas?
Steve
Re: JFC Compiling problems?
What is the compilation error ?
__ Reply Separator _
Subject: JFC Compiling problems?
Author: sgee ([EMAIL PROTECTED]) at lon-mime
Date:30/10/98 19:35
Any reason why I can run ". runnit" from the SwingSet directory, but can't
get this to compile?
import com.sun.java.swing.*;
public class test extends JFrame{
public test(){
this.setSize(300,300);
this.setVisible(true);
}//end constructor
public static void main(String args[]){
new test();
}//end main
}//end class
SysVariables
JAVA_HOME="/usr/local/jdk1.1.6"
CLASSPATH="/usr/local/jdk1.1.6/lib/classes.zip:/usr/local/swing-1.0.3/swing
.jar:."
PATH=$PATH":/usr/local/jdk1.1.6/bin"
Any ideas on what happens?
Sun to deliver JDK 1.2 for Linux
Hi everyone, I just read the following news about Sun's plans about Java for Linux: http://biz.yahoo.com/bw/981102/sun_micros_3.html I guess you would be interested as well. Bye now, - _/ _/_/ Jauvane Cavalcante de Oliveira _/ _/ _/ University of Ottawa _/ _/ _/ _/_/ School of Information Technology & Engineering _/ _/ _/ _/ Multimedia Communications Research Laboratory _/ _/ _/_/ _/ Phone:1(613)562-5800 Ext.6248/6243 FAX:562-5175 _/_/_/ _/ _/_/ Canada http://www2.mcrlab.uottawa.ca/~jauvane - |Bolsista da CAPES - Brasilia/Brasil| -
Re: Sun to deliver JDK 1.2 for Linux
The similar, but not the same article at: http://www.infoworld.com/cgi-bin/displayStory.pl?98112.ecsunjava2.htm Comments, please? > Hi everyone, > > I just read the following news about Sun's plans about Java for Linux: > http://biz.yahoo.com/bw/981102/sun_micros_3.html > I guess you would be interested as well. > > Bye now, > > - > _/ _/_/ Jauvane Cavalcante de Oliveira > _/ _/ _/ University of Ottawa >_/ _/ _/ _/_/ School of Information Technology & Engineering > _/ _/ _/ _/ Multimedia Communications Research Laboratory > _/ _/ _/_/ _/ Phone:1(613)562-5800 Ext.6248/6243 FAX:562-5175 > _/_/_/ _/ _/_/ Canadahttp://www2.mcrlab.uottawa.ca/~jauvane > - > |Bolsista da CAPES - Brasilia/Brasil| > - -- Andrew
RMI anyone?!
Is anyone working with RMI so far? I'm launching into a project where I'll try to connect Sanfrancisco to a legacy database (UniData). While UniData does provide ODBC it's too slow and, gulp, read-only. I welcome any and all commentary with open arms and squinted eyes!! Andrew -- Andrew McLaughlin Manager, Applications Software Development People 1st Technology Group, Inc. http://www.people-1st.com 714/668-7151
Syntax error in checkVersions script
I found a small syntax error in the checkVersions script that is
distributed with jdk 1.1.6.v5 (i386-libc). Below is a diff of the
small change I made to fix the problem:
bash# diff -c checkVersions.orig checkVersions
*** checkVersions.orig Mon Nov 2 11:18:24 1998
--- checkVersions Mon Nov 2 11:18:52 1998
***
*** 103,110
# 5.4.33 & 1.9.6 seem to do it too
if isGreaterOrEqual "$libdlVers" 1.9.6 ||
!{isGreaterOrEqual "$libcVers" 1.5.44 &&
! isGreaterOrEqual "$libdlVers" 1.9.9}
then
# supplied libraries are not needed
return 1
--- 103,110
# 5.4.33 & 1.9.6 seem to do it too
if isGreaterOrEqual "$libdlVers" 1.9.6 ||
!{ isGreaterOrEqual "$libcVers" 1.5.44 &&
! isGreaterOrEqual "$libdlVers" 1.9.9 }
then
# supplied libraries are not needed
return 1
Thanks to the porting team for all of their work!
Sean
=== Friends don't let friends use DOS... ===
Sean Starkey [EMAIL PROTECTED] WWW: http://rmi.net/~starkey ICQ: 4863014
Check out Universe! - http://rmi.net/~starkey/Universe
Re: JFC Compiling problems?
Did you try:
java SwingSet
Worked for me...
Andrew
[EMAIL PROTECTED] wrote:
> What is the compilation error ?
>
> __ Reply Separator _
> Subject: JFC Compiling problems?
> Author: sgee ([EMAIL PROTECTED]) at lon-mime
> Date:30/10/98 19:35
>
> Any reason why I can run ". runnit" from the SwingSet directory, but can't
> get this to compile?
>
> import com.sun.java.swing.*;
>
> public class test extends JFrame{
>
> public test(){
> this.setSize(300,300);
> this.setVisible(true);
> }//end constructor
>
> public static void main(String args[]){
> new test();
> }//end main
>
> }//end class
>
>
> SysVariables
> JAVA_HOME="/usr/local/jdk1.1.6"
> CLASSPATH="/usr/local/jdk1.1.6/lib/classes.zip:/usr/local/swing-1.0.3/swing
> .jar:."
> PATH=$PATH":/usr/local/jdk1.1.6/bin"
>
> Any ideas on what happens?
>
--
Andrew McLaughlin
Manager, Applications Software Development
People 1st Technology Group, Inc.
http://www.people-1st.com
714/668-7151
Re: RMI anyone?!
Andrew McLaughlin wrote: > > Is anyone working with RMI so far? I'm launching into a project where I'll try to > connect Sanfrancisco to a legacy database (UniData). While UniData does provide ODBC > it's too slow and, gulp, read-only. > > I welcome any and all commentary with open arms and squinted eyes!! > I'm using RMI in a project integrating a legacy RPC system with Java clients. It works very well and I do not see any significant performance degradation compared to regular RPC connections. If you decide to use JNI to interface directly to your legacy API, try very hard to centralize the API into a single JNI call (ioctl-like). It is very tedious and error-prone to develop JNI interface calls. It took +50 lines of the ugliest C code per each argument/call. -- Diego Pons Pharos Consulting LLC
Alpha port?
[ Please CC me your reply! ] Hello, I just got a DEC Alpha 21164 box. I'm running Debian on it. I went to the ports page but the port from "Uncle George" is not accessible (permission denied error). Can anybody point me to where I might find the Alpha version, appropriate diffs to compile it, etc, etc. I would really like to get it working on Alpha but can't seem to find the Alpha version anywhere! Thanks, John -- John Goerzen Linux, Unix consulting & programming [EMAIL PROTECTED] | Developer, Debian GNU/Linux (Free powerful OS upgrade) www.debian.org | + Visit the Air Capital Linux Users Group on the web at http://www.aclug.org
Java crypt
Hi, what is the situation of cryptography apis for java for european reseident? At java.sun.com is forbidden the download for non-US resident and I didn't see any class for java in the usual european sites for cryptography. Thanks Fulco Muriglio
Re: Java crypt
Do a search for cryptix java. It is an encryption library written entirely in java (native methods for windows and a few others). As far as I know it can be downloaded from sites in the UK. It includes blowfish, des, des3, idea and morecan't remember their main url though - I think development has stopped :( but the mailing list continues to spew messages. __ Kenny Freeman <[EMAIL PROTECTED]> "a population that gives up its freedoms in the name of order will ultimately end up losing both." On Mon, 2 Nov 1998 [EMAIL PROTECTED] wrote: > Hi, >what is the situation of cryptography apis for java > for european reseident? > At java.sun.com is forbidden the download for non-US resident > and I didn't see any class for java in the usual european sites > for cryptography. > > Thanks > Fulco Muriglio >
[Fwd: Final Release of NetBeans Developer 2.0 available now]
Download is damn slow. Andrew Original Message Subject: Final Release of NetBeans Developer 2.0 available now Date: Mon, 2 Nov 1998 14:30:48 -0600 From: NetBeans <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Dear NetBeans user, It's available ! The much anticipated final release of NetBeans Developer 2.0 is available for download from the NetBeans website. This release includes many many bugfixes, new functionality, and a completely new User's Guide. The User's Guide is included in HTML format in the software, a separate pdf distribution is available on the downloads page. In addition to the standard installation formats - nbdev200.exe for Windows 95/98/NT, nbdev200.sh for Unix, and nbdev200.class for *any* platform with a 1.1 JVM - this release is also available in a new installation format. The Linux Red Hat Package Manager (rpm) distribution is ideal for shared, multi-user installations on Linux (Red Hat, Caldera and SUSE) systems. As with the Beta releases, NetBeans Developer 2.0 is free for educational and non-commercial use. For commercial development, it is available at a special introductory price of $145. Download the evaluation version of NetBeans Developer 2.0 free from http://www.netbeans.com/register.html, or purchase from http://www.netbeans.com/order.html Please note you require a 1.1.x Sun-compatible JVM installed on your system *before* installing NetBeans Developer 2.0. On platforms where available, 1.1.5 is the minimum requirement, 1.1.7A is strongly recommended. The latest JDK is available for download from http://java.sun.com/products/jdk/1.1/ For Linux platforms, 1.1.6 from http://www.blackdown.org/ is required, NetBeans Developer does not run well with other available Linux VMs. Technical Support If you are having any problems with NetBeans Developer, please make use of these online resources : - Newsgroups : the NetBeans support team, and the NetBeans community world wide contribute to this public forum, making it an invaluable knowledge base. See http://www.netbeans.com/newsgroups.html for details of configuring your newsreader to read the NetBeans newsgroups. - the FAQ : please check the FAQ, which covers all common problems with installation, startup, and running NetBeans. This list is updated regularly as new issues come to light. http://www.netbeans.com/faq.html - Virtual Machines : Check you are using a supported JVM. Known, working VMs are listed at http://www.netbeans.com/jvms.html If you wish to contact technical support, please make use of the online Support Request form. While all support requests will be responded to, by purchasing NetBeans Developer you ensure priority support. Support Request : http://www.netbeans.com/developer/support_request.html Happy coding! The NetBeans Team [EMAIL PROTECTED] http://www.netbeans.com/ === You have received this e-mail as a result of your registration on the NetBeans website. To unsubscribe send a reply to this e-mail with the word "unsubscribe" in the SUBJECT of the message.
Re: RMI anyone?!
Hi Diego, I'm a little dense in this area, can you break down the components? I'm thinking that I'll have to write my own software on the server side to be able to select data as well as do the normal I/O. While UniData does have a C adapter so that I can access the data files from Unix I'm not sure what else that I would have to write to complete the chain. Is JNI (Java Network Interface)? Just guessing. That's a new one for me. Am I on the right track? Thanks, Andrew (learning Java for one week so far) Diego Pons wrote: > Andrew McLaughlin wrote: > > > > Is anyone working with RMI so far? I'm launching into a project where I'll try to > > connect Sanfrancisco to a legacy database (UniData). While UniData does provide >ODBC > > it's too slow and, gulp, read-only. > > > > I welcome any and all commentary with open arms and squinted eyes!! > > > > I'm using RMI in a project integrating a legacy RPC system with Java clients. > It works very well and I do not see any significant performance degradation > compared to regular RPC connections. > > If you decide to use JNI to interface directly to your legacy API, try very > hard to centralize the API into a single JNI call (ioctl-like). It is very > tedious and error-prone to develop JNI interface calls. > It took +50 lines of the ugliest C code per each argument/call. > > -- > Diego Pons Pharos Consulting LLC -- Andrew McLaughlin Manager, Applications Software Development People 1st Technology Group, Inc. http://www.people-1st.com 714/668-7151
Re: RMI anyone?!
JNI stands for Java Native Interface. It allows a Java program to access C & C++ methods. By using established C-to-Fortran bindings, you can also interface Java to Fortran using JNI. JNI will work for your purposes. Basically, you declare all of the C functions that you want to call as 'native' methods in Java. Then, you run 'javap', which parses your Java code and creates C "stubs" for all of the native methods (a stub is just a simple function in C that Java knows how to connect to). You then fill out these "stubs" to call the actual C routines that you intend to use. There are some things that need to be pointed out concerning the C stubs. Any data declared in Java that will be used in the C programs must be copied to local C variables (JNI provides functions that retrieve data from the JVM). To store values in the JVM from C code, you must likewise copy the local C variables to Java (again, using functions provided by JNI). The reason that variables need to be copied (as opposed to being used directly) is that Sun has declared in the JNI specification that the JVM can, at its will, move variables in memory (supposedly, the forthcoming HotSpot JVM will move memory in order to reduce memory contention between threads). If a C program were accessing data in the JVM directly, the pointer referring to the data would thus be out of date if the data had been moved by the JVM. This should get you the funtionality you require. JNI also specifies ways of throwing and catching Java exceptions, as well as ways of declaring new memory and garbage collecting old memory in the JVM. However, this functionality is rarely required, and adds significantly to the complexity of JNI programs. I hope this helps! -dan [EMAIL PROTECTED] Andrew McLaughlin wrote: > Hi Diego, > > I'm a little dense in this area, can you break down the components? I'm thinking >that I'll > have to write my own software on the server side to be able to select data as well >as do > the normal I/O. While UniData does have a C adapter so that I can access the data >files > from Unix I'm not sure what else that I would have to write to complete the chain. > > Is JNI (Java Network Interface)? Just guessing. That's a new one for me. > > Am I on the right track? > > Thanks, > Andrew (learning Java for one week so far) > > Diego Pons wrote: > > > Andrew McLaughlin wrote: > > > > > > Is anyone working with RMI so far? I'm launching into a project where I'll try to > > > connect Sanfrancisco to a legacy database (UniData). While UniData does provide >ODBC > > > it's too slow and, gulp, read-only. > > > > > > I welcome any and all commentary with open arms and squinted eyes!! > > > > > > > I'm using RMI in a project integrating a legacy RPC system with Java clients. > > It works very well and I do not see any significant performance degradation > > compared to regular RPC connections. > > > > If you decide to use JNI to interface directly to your legacy API, try very > > hard to centralize the API into a single JNI call (ioctl-like). It is very > > tedious and error-prone to develop JNI interface calls. > > It took +50 lines of the ugliest C code per each argument/call. > > > > -- > > Diego Pons Pharos Consulting LLC
Re: Problems on Sparc; redhat 5.1
Red Hat 5.1 on Sparc uses glibc, while the JDK-port for sparclinux is built using libc-5 (which was distributed with Red Hat 4.x). I was working on a glibc-port (http://www.sesuadra.org/~jdk), but since JDK 1.2 is due to be out soon, I think it is better to work on a JDK 1.2 port for sparclinux glibc. - Johan Nothing vanishes without a trace
Re: RMI anyone?!
Andrew McLaughlin wrote: > > Hi Diego, > > I'm a little dense in this area, can you break down the components? I'm thinking >that I'll > have to write my own software on the server side to be able to select data as well >as do > the normal I/O. While UniData does have a C adapter so that I can access the data >files > from Unix I'm not sure what else that I would have to write to complete the chain. > > Is JNI (Java Network Interface)? Just guessing. That's a new one for me. > I'll try to be less terse this time. First, RMI is a great solution, much simpler to code than say RPC's for developing client/server interfaces. The only complication is that to support legacy systems not written in Java, you will need to create a (non-portable) bridge using JNI (see Dan Kirkpatrick's response to you). JNI allows you to interface with the C language, having thus access to the underlying operating system or application interfaces in C. As D.K. says, in JNI you have to map Java classes to C structures on the output arguments, and C to Java on the input arguments, all the while checking for errors at each step. This is a lot easier to say than to do. Most errors will cause the JVM to dump a (most enigmatic) core. Given this difficulty, I suggest to minimize the number of JNI functions. One way is to create a mega-call in JNI where the parameters are a command and a related argument list as strings, in a way similar to ioctl() calls. A typical API would then be handled in this way: my_jni_call(..., OPEN_CMD, arg, NULL) my_jni_call(..., READ_CMD, arg, argsz) my_jni_call(..., WRITE_CMD, arg, argsz) etc, etc. While this goes against elegancy in design, it will add to the robustness of the product by eliminating error-prone Java<->C mapping code. Unfortunately, this came to me only after writing about 3000 lines of the interface code. I suggest reading "Core Java, Volume II", by Horstmann and Cornell for both RMI and JNI examples and references. -- Diego Pons Pharos Consulting LLC
Re: RMI anyone?!
I concur, in general, about the cryptic errors that occur with JNI coding. I tend not to put everything within a single function call, but I do follow the KISS principle (Keep It Simple, Stupid). May I also suggest the book, "essential JNI: Java Native Interface" (sic on capitalization), by Rob Gordon. This is an excellent (no, authoritative) book on the subject of JNI. It is very well written. Following the KISS principle, you'll probably only need to read the first 2 or 3 chapters. There are other native interfaces available, as well. Netscape's JVM has their own native interface, developed before JNI was available. However, Netscape has deprecated this interface in favor of JNI. Microsoft's JVM uses something called RNI (Runtime Native Interface), and does *not* support JNI (you can, however, use Sun's Java Plug-In, which encapsulates Sun's JVM inside an Active-X control). Microsoft will likely never support JNI. This is, in fact, the source of Sun's accusations against Microsoft for not supplying a JVM that is compliant with the Java standard. Why does Microsoft do this? WFC, Microsoft's Java interface to MFC, makes extensive use of native calls (as you might expect). In order to make WFC faster than it would otherwise be, RNI allows native code to get the address of Java variables directly (which, of course, would not work if data is moved in memory, as the JNI specification allows). To support JNI, Microsoft would have to cripple (in terms of speed, anyway) the WFC, something Microsoft is not likely to do. We have built a bridge between RNI and JNI for our internal use (we provide Java toolkits for data visualization). This way, our native code and our Java code remains intact. Our bridge maps the RNI stubs to call the JNI stubs, and provides the JNI data access functions in the event that the JNI is not available. However, we do not offer this as a product (yet). If there is sufficient interest, we could probably be coaxed into developing this into an actual product. Please e-mail me if you require this functionality. I hope this helps. Native interfaces have been the source of a lot of headaches for Java developers. I repeat my earlier advice: KISS. -dan [EMAIL PROTECTED] Diego Pons wrote: > > I'll try to be less terse this time. > First, RMI is a great solution, much simpler to code than say RPC's > for developing client/server interfaces. The only complication is that > to support legacy systems not written in Java, you will need to create > a (non-portable) bridge using JNI (see Dan Kirkpatrick's response to you). > > JNI allows you to interface with the C language, having thus access to > the underlying operating system or application interfaces in C. > As D.K. says, in JNI you have to map Java classes to C structures on > the output arguments, and C to Java on the input arguments, all the while > checking for errors at each step. This is a lot easier to say than to do. > Most errors will cause the JVM to dump a (most enigmatic) core. > > Given this difficulty, I suggest to minimize the number of JNI functions. > One way is to create a mega-call in JNI where the parameters are a command > and a related argument list as strings, in a way similar to ioctl() calls. > A typical API would then be handled in this way: > > my_jni_call(..., OPEN_CMD, arg, NULL) > my_jni_call(..., READ_CMD, arg, argsz) > my_jni_call(..., WRITE_CMD, arg, argsz) > etc, etc. > > While this goes against elegancy in design, it will add to the robustness > of the product by eliminating error-prone Java<->C mapping code. > Unfortunately, this came to me only after writing about 3000 lines of > the interface code. > > I suggest reading "Core Java, Volume II", by Horstmann and Cornell for > both RMI and JNI examples and references. > > -- > Diego Pons Pharos Consulting LLC
Interest in a JIT on Linux
Hi, I've been seeing a lot of articles like the following recently, and as a Linux user who happens to work for IBM in the Research division, I've been wondering if some of the technology we have here could be useful to the Java on Linux effort. More specifically, I was thinking that I might be able to get a "research" effort going to port IBM's Intel JVM with its JIT (we have a pretty good one) to Linux. I couldn't tell whether the 1.2 announcement from Sun meant that there was going to be a reasonable JIT on Linux with 1.2. I don't want to do anything that would throw a wrench in the work that you are doing, which I think is very important. Also, if we did a JIT port here, we'd give it away (probably on our AlphaWorks web site), but I very much doubt that we could Open Source it. I'd be very interested in your opinions on whether such an effort would be useful, or would be redundant with the work that you or others are doing. Thanks, - Jim Russell http://editorials.freshmeat.net/ian981017/ http://www.infoworld.com/cgi-bin/displayStory.pl?98112.ecsunjava2.htm
Re: Interest in a JIT on Linux
> user who happens to work for IBM in the Research division, I've been wondering > if some of the technology we have here could be useful to the Java on Linux > effort. More specifically, I was thinking that I might be able to get a > "research" effort going to port IBM's Intel JVM with its JIT (we have a pretty > good one) to Linux. Well, there is the TYA JIT ftp://gonzalez.cyberus.ca/pub/Linux/java/ It certainly *seems* fast, but I am curious if there are any benchmarks for it. M.
Re: Interest in a JIT on Linux
At 03:40 PM 11/2/98 -0800, [EMAIL PROTECTED] wrote: >> user who happens to work for IBM in the Research division, I've been wondering >> if some of the technology we have here could be useful to the Java on Linux >> effort. More specifically, I was thinking that I might be able to get a >> "research" effort going to port IBM's Intel JVM with its JIT (we have a pretty >> good one) to Linux. > > >Well, there is the TYA JIT ftp://gonzalez.cyberus.ca/pub/Linux/java/ >It certainly *seems* fast, but I am curious if there are any >benchmarks for it. > >M. If he speaks of the JIT used for OS/2 on Intel. It performs very nicely. I was amazed at the difference between the performance of Java on OS/2 and the same on Linux, Win95 and Mac. To be fair, I haven't tried the TYA JIT for Linux. Douglas Toltzman Oak Street Software, Inc.
