I wanna get webaccess
hello everyone, Now I am porting pjava to linux.r there someone can mail java webaccess to me,since I cannot download it. thanks very much best regards kevin N I@R é[h«Ú)îÆ·ª¹ë-«ÚnVÚ0àÂ+ajËç-¡û§²æìr¸y:è¹¹^ íiËdj¹[§$v'¢¸
Re: Problems with SuperMojo - it is AWFUL
My comments on SuperMojo: I tried it on Windows and Linux and it was AWFUL in both environments. I purchased it because Penumbra offered a 30 day free trial. It was so bad that I decided to return it the day after I received the CD. To make a long story short: I left voice mails and email with various Penumbra mailboxes, all trying to get an RMA number. After two weeks with no response, I returned the package and told my credit card company to decline the charge. The worst support I've ever seen. A really poor product. Two great things which go great together. Kevin At 10:29 PM 6/19/98 -0500, John Collins wrote: >Has anyone gotten SuperMojo to work? I've got RedHat 5.0, jdk1.1.5v7. >Lots of other Java stuff works. The two things that aren't working are >SuperMojo (brand new, version 1.3) and Together/J (also brand new, >version 2.0). In both, they start up and some things work, but I can't >initiate a new project. SuperMojo puts up a 0X0 window that, when >stretched out, is empty and unresponsive, and won't respond to window >manager close requests. Together/J puts up a huge, undecorated window in >a different virtual screen (below and to the right) from the one I'm >working in. It also has no contents and is unresponsive. > >Any experiences or ideas? Thanks. > >John Collins > ----- S. Kevin Hester For PGP Public Key, see: [EMAIL PROTECTED] http://www.interstice.com/~kevinh "Castigat ridendo mores"
Re: JWS slowness with 1.1.6v2
>THE PROBLEM: On two of the three machines I >> can't get version 1.1 of the Java Web Server to respond reliably. I have >> to submit each request multiple times - it seems almost like JWS is only >> handling every other TCP connection. >> >This is a reported bug. >Check out >http://www.blackdown.org/cgi-bin/jdk/pending?id=3;user=guest > >If _very_ curious about the machine that you say is working. >Obvious question is, what's the difference... >(ld.so seems a popular one - I've got 1.9.5-5) Based on your excellent bug report I now realize why the third machine works fine: I was accessing the server LOCALLY - remote accesses are the problem. ----- S. Kevin Hester For PGP Public Key, see: [EMAIL PROTECTED] http://www.interstice.com/~kevinh "Castigat ridendo mores"
Re: Regexp utility classes..
I haven't tried these -- but here's a link to an existing package (that uses perl5-style regexps): http://www.win.net/~stevesoft/pat/
JavaSignals now available
JavaSignals is a free library to allow Java programs to catch OS signals by registering SignalListeners. Source and binaries are included. There is a small amount of native code which currently supports Linux. The native code could be easily ported to other UNIX flavors or the PC. See: http://interstice.com/~kevinh/projects/javasignals/index.html Please contribute any improvements which you make. - S. Kevin Hester For PGP Public Key, see: [EMAIL PROTECTED] http://www.interstice.com/~kevinh "Castigat ridendo mores"
Re: NETBEANS INSTALL
Hi, Syed,
To paraphrase Jerry McGuire:
"Show us the CLASSPATH."
Best Regards,
KR
Syed Mubin wrote:
> ...
> Hi,
>
> I'm trying to install Netbeans nbdv20b3.sh on JDK1.1.6 but
> not sucessful.I also have installed SWING1.0.3 the SwingSet example is
> working fine but when i wrote a simple program it shows the following
> errors.
>
> -
> CLASSPATH SET
> ...
> ERRORS SHOWN
>
> SimpleSwing.java:3: '{' expected.
> interface com.sun.java.swing.*;
> ^
> SimpleSwing.java:7: Superclass JApplet of nested class com. SimpleSwing
> not found.
> public class SimpleSwing extends JApplet
> ^
> 2 errors
>
>
> Is it compulsory to have swing installed for working netbeans?
>
> Please help
>
> Syed Mubeen
Re: Swing: Can't find class ClassName
Since your class is inside a package, you'd need to refer to it this way:
java JFCBook.Chapter2.BasicFrame
(or get rid of the qualifying package name before compiling it)
Separately, do you have SWING_HOME set? (This may not be necessary under
Linux, but on Solaris and WinXX it is.)
William Tchen wrote:
> I include the example file that I want to compile here:
>
> package JFCBook.Chapter2;
>
> import com.sun.java.swing.*;
>
> public class BasicFrame {
> public static void main(String[] args) {
> JFrame f = new JFrame("Simple Frame");
> f.setSize(250, 200);
> f.setVisible(true);
> }
> }
>
> When I compile this file, there is no error message. But when I run it using
> 'java BasicFrame'
> it says 'Can't find class BasicFrame'. Have you ever experience this before?
> Thanks for time.
> William Tchen
Hi, there
Hi, all, I am new to Linux and I'm glad to find out there is a Java port on Linux. I would like to contribute a bit by writing some C programs. However, I don't know the inside of Java so I will need your help. Please write me if I can be of any help. Thanks. -- K
Re: Java app without X installed
With that kind of attitude...heck...you could work for Microsoft. > > Exercise patience and courtesy in your replies. You too were a beginner > > once. > > Yes. And I didn't ask for help before exhausting the other options, if I asked > for help at all. >
Minor WM in jdk1.1.6v1
I am using jdk1.1.6v1 on the K Desktop Environment and have run across a small bug. It always displays AWTapp as the window caption for every java window. I would apreciate if you might address this in future versions. WHile this is not a major bug it is anoying. Thx Kevin Fitch ps I think that you are doing great wirk w/ this port. 1.1.6v1 combined w/ tya is just as fast as my regular apps!! -- Kevin Fitch [EMAIL PROTECTED] --Windoze95 ... a 32 bit graphical front end to a 16 bit patch on an 8 bit operating system written for a 4 bit processor by a 2 bit company without 1 bit of decency =B-)
JWS slowness with 1.1.6v2
I've worked on this problem for a while and I still can't find a solution. Has anyone encountered the following problem? Do you have a fix? I'm using JDK 1.1.6v2 on my upgraded RedHat 5.0 distribution. I can run many Java programs with no problem. In fact, I have three machines each running in this configuration. THE PROBLEM: On two of the three machines I can't get version 1.1 of the Java Web Server to respond reliably. I have to submit each request multiple times - it seems almost like JWS is only handling every other TCP connection. The third machine runs great. If I try Apache on the troublesome machines - it runs fine. I've compared the library versions with ldconfig -D and the libraries all seem to be the same. Any ideas? I'm desperate. If you are in the bay area I can even buy sushi. ;-) Kevin ----- S. Kevin Hester For PGP Public Key, see: [EMAIL PROTECTED] http://www.interstice.com/~kevinh "Castigat ridendo mores"
RE: serial port program
In all fairness, I should point out that I only wrote the wrappers to make RXTX work with JavaComm and many others have enhanced the implementation I created. Just go to the listed web page - it is now very easy to control Linux serial ports from Java. All of the code has been rolled into the standard RXTX distribution. -Original Message- From: Alastair Broom [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 30, 1998 6:21 AM To: Steve Delahunty Cc: jinranlin; [EMAIL PROTECTED] Subject: RE: serial port program On Wed, 30 Dec 1998, Steve Delahunty wrote: > It would sure be nice to have basic serial port functionality > ... > > -Original Message- > Subject: serial port program > > I need to make a program to control RS232 port, does anybody know how to do > it using java? > Theres the "Java Communications API 2.0" http://java.sun.com/products/javacomm/ But there are only versions for Solaris and Windows - it needs a native library to actually talk to the ports. The comm faq http://java.sun.com/products/javacomm/javadocs/CommAPI_FAQ.txt includes this: Q: Is there a linux version of the Java communications API? A: We do not provide a linux implementation. But Kevin Hester has written Java communications API drivers for linux and uses our CommPort driver loading scheme to load his own gnu.io.RXTXCommDriver class. He gave us permission to disclose his web page: http://www.interstice.com/kevinh/linuxcomm.html See also http://www.javaworld.com/javaworld/jw-09-1998/jw-09-indepth.html for a story about getting java to be a boot loader for an old PDP-8 by pretending to be a 100 baud tape streamer... (includes code examples using the javax.comm api mentioned above) Hope some of this helps... -- Alastair Broom Valley Technology, Edinburgh, Bonnie Scotland [EMAIL PROTECTED]
Re: JavaLinux for servlets
> I would certainly not use Java for CGI. libapache-mod-perl, FastCGI, etc. if necessary. I'd definitely encourage anyone to use servlets with wild abandon. So easy and clean - I haven't had to write CGI cruft in over a year. In exchange for servlets I have a logical/maintainable tree of server side classes. Kevin
JDK 1.2 - Licensing in the real world...
Hi folks, It seems like some people here haven't been through the typical license negotiation process. Apparently Steve went through the nontrivial step of working out a license agreement with Sun. The terms he acquired for the Linux port do not allow distribution until the JCK tests pass. He alluded that in hindsight it might have been better to not accept that clause of the contract, but hindsight is hindsight. Once the port works it will no longer be an issue. Wrt. IBM being able to distribute a non JCK compliant release: It is not a technical issue of the number of engineers involved. It is a matter of the contract which IBM independently negotiated. Wrt those that say that the standard 1.2 source agreement could be used to make a freely distributable JDK. I suspect this is not true. The standard distribution of JDK source comes as a "research" license - you can't distribute changes based on a research license easily. If you want to upgrade to a commercial license, then you are back to discussing royalties with Sun and JCK tests by third parties. If you care about this - read the very extensive license at the www.sun.com sourceware sight. I think Steve and the folks who are working on 1.2 have done us a wonderful service. Kevin -Original Message- From: Brett W. McCoy [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 24, 1999 12:52 PM To: Uli Luckas Cc: [EMAIL PROTECTED] Subject: Re: Sun's License for Java 2 On Wed, 24 Feb 1999, Uli Luckas wrote: > Why can IBM publish an 'almost' ready java 2 VM and why can't the linux > porters? But how many people does IBM have working on the porting effort versus the number of people working on hte Linux port? And how many people at IBM are working on their port as a paying job versus a porting effort being worked on in addition to someone's paying job. I think that's an unfair comparison. Brett W. McCoy http://www.lan2wan.com/~bmccoy --- Ban the bomb. Save the world for conventional warfare. - BEGIN GEEK CODE BLOCK - Version: 3.12 GAT dpu s:-- a C UL$ P+ L+++ E W++ N- o K- w--- O@ M-@ !V PS+++ PE Y+ PGP- t++ 5- X+ R+@ tv b+++ DI+++ D+ e>++ h+ r++ y -- END GEEK CODE BLOCK -- -- 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: Slow loading on AMD Elan 486
The 1.1.7v1a JDK runs great on my AMD DX4-100 w/32Mb RAM. Since one can get something roughly 20x as fast as my machine for $500 these days, I'm not sure I understand why agonizing over the JDK's performance on a 486/33 is worthwhile. Linux itself, of course, will run great even on a 386/25 with 8Mb (I did this for a long time). But the JDK, particularly JDK 1.2 (a/k/a Java2), has a bit more bulk to it. JDK 1.2 for Linux arrives tomorrow (Thurs.), apparently. I can assure you it won't run well on a 486/33 -- but for a few bucks worth of hardware, you'll have a great JDK on a great OS. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Slow loading on AMD Elan 486
My apologies to the list for my apparently misguided remarks re. buying new hardware. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
open, read, ioctl calls in java?
I am working on a java wrapper for a linux library that uses files to open(), read(), and issue ioctl() calls to a device. I assume I can open() and read() the device file as I would any standard file in java. Is this correct? What about the ioctl() calls? Can I do these in java wthout using JNI? If I use jni, I have seen references that certain system calls (open(), read(), etc.) cannot be used in the native code, due to green thread issues. Is this still the case? Is there anyway I will be able to make the ioctl calls? Ideally, I'll open(), read() and close() the file from java, but how will I do the ioctl()? Thanks for any suggestions, -- Kevin White, Software Engineer Envision Telephony [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
examples of creating a new object in jni?
I am having a tough time piecing together the (lack of) documentation on using native code to actually allocate (and call the constructor of) a new object. Can someone please point me to an example? I have a java class that needs to be constructed by some native code. It will take 4 parameters in the constructor, so I'd like to see a sample with multiple paramters. I've been reading the JNI tutorial at sun, but they don't have an example of this, and I've been looking through the actual JNI spec but of course, that's like reading a dictionary to try to learn grammar... Any pointers or suggestions are helpful and appreciated. -- Kevin White, Software Engineer Envision Telephony [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
null layout?
I have a frame in which I would like to use no layout manager so that I
can directly position elements where I want them.
I use the following code, in the constructor of a class that descends
from Frame:
setSize(600,380);
setLayout(null);
Label label=new Label("Hi there");
label.setBounds(10,10,200,20);
add(label);
Is there anything wrong with this? This is what I do on other platforms
and works fine. However, unless I use a layout manager, I cannot see
this label show up on the window.
--
Kevin White, Software Engineer
Envision Telephony
[EMAIL PROTECTED]
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
It's finished!
Well, the code anyway. I have now finished the first version of a java class wrapper for the linux joystick driver, written a java gui test program, and it works! ... er, At least it works on my system, with my jdk, on my distribution, with my joystick, so I'd like to make it available for others to test. But, as this is my first linux programming project, I have no clue how to build appropriate makefile for: 1- gotta build the native .c file into a shared library 2- build the java files into a jar 3- need to install the .so created in step 1 into an appropriate directory. (In the LD_LIBRARY_PATH?) 4- put the .jar file in an appropriate directory in the classpath. 5- How do I put an appropriate "license" on it so it can be used freely? I'd like changes to come back to me, so I can be the maintainer of the thing, but want people to use or improve it, and make it useful. So,I think there should be: make clean make configure - do I need this? maybe to find out where the linux jni includes are? make - to build the so, and the jar files make install - to install the stuff appropriately Should I write the doc in javadoc since it's just a set of classes for an api? Or in a readme? Both? Where do I include the license descriptions? Is there a "template" or sample license file somewhere that I can use? I appreciate any help in this, since I've never attempted this stuff, and have never done makefiles, shell scripts, etc. Where do I start? Thanks, -- Kevin White, Software Engineer Envision Telephony [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JDK 1.2 pre-v1: Missing shared library
RTFM The workaround was posted many messages ago -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
My big stupid mistake
Ok, I'm really stupid. Please don't flame me for how stupid I was. I was writing a Makefile and testing it. In the make file I have: #make a directory we can use for jarring things up mkdir jar #copy the com/kevinsworld/. directory structure cp -r com jar cd jar #don't want java files in the jar, just class files rm com/kevinsworld/linux/devices/*.java #create the jar jar -c0vf com cd .. rm -r jar First problem: the cd apparently doesn't work in the make file, so it actually removed my java source files from where I really, _really_ didn't want them removed. Oh, where is linux's undelete feature! (You know, the "gotta protect the morons" feature...). So, how do I "cd" in a makefile? Jar only works correctly if you're in the directory of what you want to jar. i.e.: if I am in jar and say "jar -c0vf jar/com" it puts the files in the jar as if they were in package jar/com/kevinsworld/... rather than com/kevinsworld/... So, how do I cd in a makefile? Second problem. I was stupid and didn't think to copy my source files elsewhere. This is a relatively small project I was just working on and hadn't backed up yet. (I already admitted to stupidity). Can I disassemble my java .class files to get something to work from to recreate the source? Thanks for any help, The Moron -- Kevin White, Software Engineer Envision Telephony [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: My big stupid mistake - Thanks!
Thanks to all the pointers. I decided to get jad as the decompiler to use, and it worked great. I still have to test all the class files after compiling them from what it creates, but going through the source, jad sure did a good job. Also thanks for the pointers on the Makefile problems I had. Kevin White [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Thanks everyone
Thanks to everyone's help the last several days on jni programming with linux, help with Makefile suggestions, and even helping me with stupid errors, I was able to get my first linux project released (development release, of course). Just thought I'd thank everyone on this list for their help. If you're interested, it's a java wrapper over the linux joystick driver. It's available through www.kevinsworld.com. Thanks again! -- Kevin White, Software Engineer Envision Telephony [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JNI - gcc compiler options
Shoban Jeyaraj wrote: > I am new to Linux, and recently, our company has decided to do some projects > on Linux using Java. The project involves JNI. I'd like to know how I should > go about creating the shared libraries that Java is going to interface with. > > I have created the header files using javah. I have also implemented those > function declarations on a .c file. I'd like to know a sample 'cc' command > with the switches to compile the .c file to produce a shared library that > could be used by Java. > I have written a very simple JNI program with a very simple Makefile that you can take a look at. It is not very feature rich with compiler options other than basic compilation and creating the shared library. You can download it from www.kevinsworld.com, it's the JavaJoystick api. Hope it helps, -- Kevin White, Software Engineer Envision Telephony [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
JavaSignals 1.0 released - fixes RMI bug
Hi gang, Over the past few months I've received a number of emails about javasignals - and many folks found an annoying bug related to breaking RMI. I've just received a fix for this bug from Bernhard Bablok ([EMAIL PROTECTED]). Unfortunately, I didn't keep a list of who wanted the fix. ;-) I decided that since this is a Java tool to support handling linux signals, that this would be an appropriate place for a brief notice about the fix. http://interstice.com/~kevinh/projects/javasignals/index.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Java CommAPI for Linux
Hi, I've written a set of free Java drivers for the new CommAPI from Sun. These drivers allow you to access your Linux serial port from Java. The drivers are built on top of the existing RXTX library. For more information see the Java Comm for Linux page: http://www.interstice.com/~kevinh/linuxcomm.html Please send me any feedback you have. Kevin PS: Karl, could you include this in the 3rd party section on your web page. - S. Kevin Hester For PGP Public Key, see: [EMAIL PROTECTED] http://www.interstice.com/~kevinh "Castigat ridendo mores"
Re: Java wrappers
You can use JNI (the Java Native Interface) to accomplish this.
a) your C/C++ functions have to be packaged in a shared library (which
you'd already anticipated)
b) the entry point for your C/C++ code has to use a Java
package-and-class-specific "mangled" name -- e.g., if your Java wrapper
class is "Wrapper" and that class is in package "Enclosure", you might have
a Java class such as:
package Enclosure;
public class Wrapper {
public Wrapper() {
// ...
}
// (only) declare in Java; implement in C/C++ code
public native String[] getKernelStuff();
}
which would result in a C function name for getKernelStuff() that includes
both the package and class names:
#include
JNIEXPORT jobjectArray JNICALL Java_Enclosure_Wrapper_getKernelStuff
(JNIEnv *env, jobject theObj) {
// ...
}
You can pass Java data types to your C code, and xfer/convert Java/C data
types in both directions.
Build your C/C++ code as a shared library, then load that library via Java
using the System.loadLibrary("shortLibName") function, as in:
public class TestTheWrapper {
public static void main(String[] argv) {
// this actually loads libWrap.so
// (name is platform neutral -- pre/suffixes
// are added implicitly
System.loadLibrary("Wrap");
Enclosure.Wrapper w = new Enclosure.Wrapper();
w.getKernelStuff();
}
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Errors from Freebuilder
Hi: I'm trying to run Freebuilder and get the following error: java.lang.NoClassDefFoundError: com/sun/java/swing/JMenuBar at org.freebuilder.system.ideengine.IdeEngine.(IdeEngine.java) at org.freebuilder.Main.(Main.java) at org.freebuilder.Main.main(Main.java) It appears that none of the swing classes are part of the classes.zip file (java for linux 1.1.7B). Is this a current limitation of the Linux JDK? Thanks, Kevin Mooneyham -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: javacomm
The Sun comm API stuff is at: http://java.sun.com/products/javacomm/index.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Hashtable iteration insanity. Is it a bug?
The docs are a bit confusing. entrySet() returns a Set containing all of the mappings between keys and values. I think the method that you want is values() which returns a Collection of all of the values that you have put into the Hashtable. You can then create an Iterator for the returned Collection. Kevin Dimitris Vyzovitis wrote: > > I think that there is something wrong with the iterators of > Hashtables. > > Perhaps it is my misconception, but shouldn't I get an iterator that > returns the objects present in a map when I request an iterator over > its entry set? > > To be more specific, assume the following example (in jpython for the > sake of convenience): > >>> import java > >>> ht = java.util.Hashtable() > >>> ht.put( 'a', 'b' ) > >>> it = ht.entrySet().iterator() > >>> n = it.next() > >>> n > a=b > >>> n.getClass() > > > However, keySet().iterator() returns an iterator that allows me to > access the real key-Objects!!! > > As it is obvious, the iterator returns objects that belong to a class > that is not editable. > Shouldn't it return the objects that I have put it? > That is, reading the specs in the documentation, I expect to receive > functionality similar to the functionality of an Enumeration over the > Hashtable elements (plus some thread-safety for my iteration, which is > the only real reason to use an Iterator and not an Enumeration). > > Is this a bug or my misconception? > If this isn't really a bug, I think then the documentation is totally > screwed up and we receive a totally useless Iterator object!!! > > Thanx in advance. > > -- dimitris [mailto:[EMAIL PROTECTED]] > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
problem running JDK 1.1.7 on alpha
Hello, When I attempt to invoke java I get the following error: ./../bin/alpha_21164a/green_threads/java: error in loading shared libraries: ./../lib/alpha_21164a/green_threads/libjava_dl.so: undefined symbol: _dl_default_scope I am running an alpha Linux system using RedHat 6.0. Has anybody run into this one before? -Kevin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Compiling shared objects for JNI
How does one compile/link the shared object for JNI modules.
Here is an example the shows the problems I am having. I follow the steps
in the Tutorial; namely:
1) Create Java code (HelloWorld.java)
2) Compile
3) Create header for stubs (HelloWorld.h)
4) Create C/C++ code (HelloWorld.C)
5) Compile/link with jni.h
6) Set LD_LIBRARY_PATH
7) Execute
I end up with the following error message when I try to execute:
Exception in thread "main" java.lang.UnsatisfiedLinkError:
/home/klmcw/src/Java/JNI/libhwrld.so: /home/klmcw/src/Java/JNI/libhwrld.so:
ELF file's phentsize not the expected size
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(Compiled Code)
at java.lang.ClassLoader.loadLibrary(Compiled Code)
at java.lang.Runtime.loadLibrary0(Compiled Code)
at java.lang.System.loadLibrary(Compiled Code)
at HelloWorld.(HelloWorld.java:15)
What is this ELF file phentsize error about? Any ideas? Thanks in advance.
I have included the source below just in case.
Kevin
-+-+-+-+-+-+-+-+-+-+-+-CUT-+-+-+-+-+-+-+-+-+-+-+-
HelloWorld.java
class HelloWorld {
String s = null;
public HelloWorld() {
s = HelloWorldAux();
}
public native String HelloWorldAux();
public String toString() {
return this.s;
}
static {
System.loadLibrary("hwrld");
}
static public int main(String[] args) {
try {
HelloWorld hw = new HelloWorld();
System.out.println(hw.toString());
} finally {
return 0;
}
}
}
-+-+-+-+-+-+-+-+-+-+-+-CUT-+-+-+-+-+-+-+-+-+-+-+-
HelloWorld.C
#include "HelloWorld.h"
JNIEXPORT jstring JNICALL
Java_HelloWorld_HelloWorldAux(JNIEnv *jenv, jobject jobj)
{
static char hw[] = "Hello, World!";
return jenv->NewStringUTF(hw);
}
-+-+-+-+-+-+-+-+-+-+-+-CUT-+-+-+-+-+-+-+-+-+-+-+-
Makefile
INCLUDES=-I/opt/web/jdk1.2/include -I/opt/web/jdk1.2/include/linux
CXXFLAGS=-c -fpic -O2 $(INCLUDES)
all: libhwrld.so
libhwrld.so: HelloWorld.C HelloWorld.h
g++ $(CXXFLAGS) $< -o $@
HelloWorld.h: HelloWorld.class
javah -jni HelloWorld
HelloWorld.class: HelloWorld.java
javac -O HelloWorld.java
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Problem with Java3D
Hello all, I'm getting the following error when running any of the Java3D sample apps: $ appletviewer HelloUniverse.html An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4a237556 Function name=_mesa_initialize_context Library=/usr/lib/libGL.so.1 Current Java thread: at javax.media.j3d.Canvas3D.createContext(Native Method) at javax.media.j3d.Renderer.doWork(Renderer.java:475) at javax.media.j3d.J3dThread.run(J3dThread.java:256) Dynamic libraries: ... 4a205000-4a3c3000 r-xp 03:08 583142 /usr/lib/libGL.so.1.2.350 4a3c3000-4a3cb000 rw-p 001bd000 03:08 583142 /usr/lib/libGL.so.1.2.350 4a3d9000-4a3e1000 r-xp 03:08 583136 /usr/lib/libMesaOS.so.3.5.350 4a3e1000-4a3e2000 rw-p 7000 03:08 583136 /usr/lib/libMesaOS.so.3.5.350 ... This happens whether I use java, appletviewer or the Java Plug-In. This output is not enough for me to go on, so I'n not sure where to look next. Any thoughts? My setup: Progeny Debian Linux 1.0 (all outstanding updates applied) JDK 1.3.1 (from Sun) XFree86 4.0.3 Mesa 3.5 Java3D 1.2.1_01-fcs I've installed Mesa 3.5 myself, since there was no Debian package that worked. Thanks, Kevin An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4a237556 Function name=_mesa_initialize_context Library=/usr/lib/libGL.so.1 Current Java thread: at javax.media.j3d.Canvas3D.createContext(Native Method) at javax.media.j3d.Renderer.doWork(Renderer.java:475) at javax.media.j3d.J3dThread.run(J3dThread.java:256) Dynamic libraries: 08048000-0804c000 r-xp 03:08 713111 /usr/java/jdk1.3.1/bin/i386/native_threads/java 0804c000-0804d000 rw-p 3000 03:08 713111 /usr/java/jdk1.3.1/bin/i386/native_threads/java 4000-40015000 r-xp 03:06 22183 /lib/ld-2.2.2.so 40015000-40016000 rw-p 00014000 03:06 22183 /lib/ld-2.2.2.so 40017000-40018000 r--p 03:08 696329 /usr/lib/locale/en_US/LC_IDENTIFICATION 40018000-40019000 r--p 03:08 696328 /usr/lib/locale/en_US/LC_MEASUREMENT 40019000-4001a000 r--p 03:08 696327 /usr/lib/locale/en_US/LC_TELEPHONE 4001a000-4001b000 r--p 03:08 696326 /usr/lib/locale/en_US/LC_ADDRESS 4001b000-4001c000 r--p 03:08 696325 /usr/lib/locale/en_US/LC_NAME 4001c000-4001d000 r--p 03:08 696324 /usr/lib/locale/en_US/LC_PAPER 4001d000-4001e000 r--p 03:08 16230 /usr/lib/locale/en_US/LC_MESSAGES/SYS_LC_MESSAGES 4001e000-4001f000 r--p 03:08 696323 /usr/lib/locale/en_US/LC_MONETARY 4001f000-4002 r--p 03:08 696321 /usr/lib/locale/en_US/LC_TIME 4002-40021000 r--p 03:08 696320 /usr/lib/locale/en_US/LC_NUMERIC 40022000-4003 r-xp 03:06 22202 /lib/libpthread-0.9.so 4003-40038000 rw-p d000 03:06 22202 /lib/libpthread-0.9.so 40038000-40041000 r-xp 03:08 632054 /usr/java/jdk1.3.1/jre/lib/i386/native_threads/libhpi.so 40041000-40042000 rw-p 8000 03:08 632054 /usr/java/jdk1.3.1/jre/lib/i386/native_threads/libhpi.so 40042000-402a9000 r-xp 03:08 632841 /usr/java/jdk1.3.1/jre/lib/i386/client/libjvm.so 402a9000-4040f000 rw-p 00266000 03:08 632841 /usr/java/jdk1.3.1/jre/lib/i386/client/libjvm.so 40426000-40429000 r-xp 03:06 22189 /lib/libdl-2.2.2.so 40429000-4042a000 rw-p 2000 03:06 22189 /lib/libdl-2.2.2.so 4042b000-40534000 r-xp 03:06 22186 /lib/libc-2.2.2.so 40534000-4053a000 rw-p 00108000 03:06 22186 /lib/libc-2.2.2.so 4053e000-4054f000 r-xp 03:06 22191 /lib/libnsl-2.2.2.so 4054f000-40551000 rw-p 0001 03:06 22191 /lib/libnsl-2.2.2.so 40553000-40574000 r-xp 03:06 22190 /lib/libm-2.2.2.so 40574000-40575000 rw-p 0002 03:06 22190 /lib/libm-2.2.2.so 40575000-405a9000 r-xp 03:08 583059 /usr/lib/libstdc++-2-libc6.1-1-2.9.0.so 405a9000-405b5000 rw-p 00033000 03:08 583059 /usr/lib/libstdc++-2-libc6.1-1-2.9.0.so 405b7000-405c8000 r-xp 03:08 632844 /usr/java/jdk1.3.1/jre/lib/i386/libverify.so 405c8000-405ca000 rw-p 0001 03:08 632844 /usr/java/jdk1.3.1/jre/lib/i386/libverify.so 405ca000-405eb000 r-xp 03:08 632845 /usr/java/jdk1.3.1/jre/lib/i386/libjava.so 405eb000-405ed000 rw-p 0002 03:08 632845 /usr/java/jdk1.3.1/jre/lib/i386/libjava.so 405ee000-40602000 r-xp 03:08 632846 /usr/java/jdk1.3.1/jre/lib/i386/libzip.so 40602000-40605000 rw-p 00013000 03:08 632846 /usr/java/jdk1.3.1/jre/lib/i386/libzip.so 40605000-4131e000 r--s 03:08 730098 /usr/java/jdk1.3.1/jre/lib/rt.jar 4134b000-415f r--s 03:08 730099 /usr/java/jdk1.3.1/jre/lib/i18n.jar 415f-41606000 r--s 03:08 729753 /usr/java/jdk1.3.1/jre/lib/sunrsasign.jar 436ae000-436af000 r-xp 00
Re: Problem with Java3D
Is there maybe an incompatability between Mesa 3.5's libraries and the version that was used to compile Java3D 1.2.1_01-fcs? Is there any way for me to get a copy of the source of Java3D? Kevin Kevin Birch wrote: > Hello all, > > I'm getting the following error when running any of the Java3D sample > apps: > > $ appletviewer HelloUniverse.html > > An unexpected exception has been detected in native code outside the VM. > Unexpected Signal : 11 occurred at PC=0x4a237556 > Function name=_mesa_initialize_context > Library=/usr/lib/libGL.so.1 > > Current Java thread: > at javax.media.j3d.Canvas3D.createContext(Native Method) > at javax.media.j3d.Renderer.doWork(Renderer.java:475) > at javax.media.j3d.J3dThread.run(J3dThread.java:256) > > Dynamic libraries: > ... > 4a205000-4a3c3000 r-xp 03:08 583142 /usr/lib/libGL.so.1.2.350 > 4a3c3000-4a3cb000 rw-p 001bd000 03:08 583142 /usr/lib/libGL.so.1.2.350 > 4a3d9000-4a3e1000 r-xp 03:08 583136 > /usr/lib/libMesaOS.so.3.5.350 > 4a3e1000-4a3e2000 rw-p 7000 03:08 583136 > /usr/lib/libMesaOS.so.3.5.350 > > ... > > This happens whether I use java, appletviewer or the Java Plug-In. This > output is not enough for me to go on, so I'n not sure where to look > next. Any thoughts? > > My setup: > Progeny Debian Linux 1.0 (all outstanding updates applied) > JDK 1.3.1 (from Sun) > XFree86 4.0.3 > Mesa 3.5 > Java3D 1.2.1_01-fcs > > I've installed Mesa 3.5 myself, since there was no Debian package that > worked. > > Thanks, > Kevin > > > > > > > > >An unexpected exception has been detected in native code outside the VM. >Unexpected Signal : 11 occurred at PC=0x4a237556 >Function name=_mesa_initialize_context >Library=/usr/lib/libGL.so.1 > >Current Java thread: > at javax.media.j3d.Canvas3D.createContext(Native Method) > at javax.media.j3d.Renderer.doWork(Renderer.java:475) > at javax.media.j3d.J3dThread.run(J3dThread.java:256) > >Dynamic libraries: >08048000-0804c000 r-xp 03:08 713111 >/usr/java/jdk1.3.1/bin/i386/native_threads/java >0804c000-0804d000 rw-p 3000 03:08 713111 >/usr/java/jdk1.3.1/bin/i386/native_threads/java >4000-40015000 r-xp 03:06 22183 /lib/ld-2.2.2.so >40015000-40016000 rw-p 00014000 03:06 22183 /lib/ld-2.2.2.so >40017000-40018000 r--p 03:08 696329 >/usr/lib/locale/en_US/LC_IDENTIFICATION >40018000-40019000 r--p 03:08 696328 /usr/lib/locale/en_US/LC_MEASUREMENT >40019000-4001a000 r--p 03:08 696327 /usr/lib/locale/en_US/LC_TELEPHONE >4001a000-4001b000 r--p 03:08 696326 /usr/lib/locale/en_US/LC_ADDRESS >4001b000-4001c000 r--p 03:08 696325 /usr/lib/locale/en_US/LC_NAME >4001c000-4001d000 r--p 03:08 696324 /usr/lib/locale/en_US/LC_PAPER >4001d000-4001e000 r--p 03:08 16230 >/usr/lib/locale/en_US/LC_MESSAGES/SYS_LC_MESSAGES >4001e000-4001f000 r--p 03:08 696323 /usr/lib/locale/en_US/LC_MONETARY >4001f000-4002 r--p 03:08 696321 /usr/lib/locale/en_US/LC_TIME >4002-40021000 r--p 03:08 696320 /usr/lib/locale/en_US/LC_NUMERIC >40022000-4003 r-xp 03:06 22202 /lib/libpthread-0.9.so >4003-40038000 rw-p d000 03:06 22202 /lib/libpthread-0.9.so >40038000-40041000 r-xp 03:08 632054 >/usr/java/jdk1.3.1/jre/lib/i386/native_threads/libhpi.so >40041000-40042000 rw-p 8000 03:08 632054 >/usr/java/jdk1.3.1/jre/lib/i386/native_threads/libhpi.so >40042000-402a9000 r-xp 03:08 632841 >/usr/java/jdk1.3.1/jre/lib/i386/client/libjvm.so >402a9000-4040f000 rw-p 00266000 03:08 632841 >/usr/java/jdk1.3.1/jre/lib/i386/client/libjvm.so >40426000-40429000 r-xp 03:06 22189 /lib/libdl-2.2.2.so >40429000-4042a000 rw-p 2000 03:06 22189 /lib/libdl-2.2.2.so >4042b000-40534000 r-xp 03:06 22186 /lib/libc-2.2.2.so >40534000-4053a000 rw-p 00108000 03:06 22186 /lib/libc-2.2.2.so >4053e000-4054f000 r-xp 03:06 22191 /lib/libnsl-2.2.2.so >4054f000-40551000 rw-p 0001 03:06 22191 /lib/libnsl-2.2.2.so >40553000-40574000 r-xp 03:06 22190 /lib/libm-2.2.2.so >40574000-40575000 rw-p 0002 03:06 22190 /lib/libm-2.2.2.so >40575000-405a9000 r-xp 03:08 583059 >/usr/lib/libstdc++-2-libc6.1-1-2.9.0.so >405a9000-405b5000 rw-p 00033000 03:08 583059 >/usr/lib/libstdc++-2-libc6.1-1-2.9.0.so >405b7000-405c8000 r-xp 03:08 632844 >/usr/java/jdk1.3.1/jre/lib/i386/libverify.so >405c
Problem with external process on Linux using Runtime.exec() andoutput, input and error streams.
I've encountered a problem in using Runtime.exec() and the
outputStream and inputStreams with Java on Linux. Apologies in advance
for the very long message, but I've done a lot of analysis on this to
narrow the problem, make it reproducible, try it under varying
environments, etc. This message is probably best viewed using a
monospaced font. Any help or clues that can be offered will be greatly
appreciated.
The summary of the problem is that I am trying to start an external
process using Runtime.exec() and then attach to this process's stdin,
stdout and stderr using Process.getInputStream,
Process.getOutputStream and Process.getErrorStream. I wish to keep the
process alive, and to continually be able to shovel input into the
stdin stream and to capture the output on stdout and stderr
streams. The complication here is that one or more of the pipes seem
to be closing prematurely causing the child process to go away and the
master to begin throwing IOexceptions.
I've included test code which will demonstrate the problem I'm
describing. The test code consists of a single java source file
(ProcessMaster.java) and a short Perl script (ProcessSlave.pl). This
test code is at the very bottom of this message.
The slave process (Perl script) simply does blocking line reads on
stdin. It then checks for some special-case tokens (write an end
marker, flush a stream, or exit), and acts on them if it sees them,
otherwise it writes the line it saw back out on stdout and stderr with
a leading tag to identify the stream.
The master starts the slave process and gets the process's stdin,
stdout and stderr streams. Then, it pumps a multi-line command into
the slave's stdin. Using a pair of threads, we wait for output on both
the stdout and stderr of the slave, and we continue reading output
until either we see an end marker or hit the end of the stream,
thereby exiting the thread.
I will describe the configurations I've used and provide some detail
into what I've discovered on the varying configurations in a
bit. First, let me describe the error I'm seeing.
The noticeable symptom of the problem is seeing an IOException thrown
by the master (beware - line numbers may be skewed a couple from the
test code):
java.io.IOException: Bad file descriptor
at java.io.FileOutputStream.writeBytes(Native Method)
at java.io.FileOutputStream.write(FileOutputStream.java:212)
at
java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:72)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:130)
at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:245)
at java.io.BufferedWriter.flush(BufferedWriter.java:233)
at ProcessMaster.runCommand(ProcessMaster.java:115)
at ProcessMaster.main(ProcessMaster.java:217)
I believe this to be an aftereffect - there's nothing to debug here:
the pipe we had to the slave's stdin has gone away, so trying to flush
a command we just wrote to the outputStream's BufferedWriter throws
this exception. No surprises here. (Note - using IBM's java 1.3.0
implementation, the exception thrown is an Illegal seek rather than
Bad File Descriptor. Still, it's thrown in the same place in the code).
The reason the pipe's broken and I get the exception above is that the
slave process has gone away! But why? To help with that, I've attached
an strace to the slave process while the master is blocking for input
asking for the delay in milliseconds that it should insert in some
places.
The slave strace shows me a couple scenarios, both of which would result
in
the slave exiting. The mystery that has me stumped is why either of
these eventualities are happening in the first place.
First case is the slave getting a null on stdin. Presumably this
happens when the pipe between the slave's stdin and the master has
gone away. Here's an strace that shows this:
16:04:24.858985 read(0, "Four score...\nwrite [ STDERR, \'{"..., 4096) =
104
16:04:26.272951 fstat64(1, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
16:04:26.273061 mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x401e2000
16:04:26.273142 write(1, "SLAVE STDOUT> Four score...\n", 28) = 28
16:04:26.273396 write(2, "SLAVE STDERR> Four score...\n", 28) = 28
16:04:26.273592 write(2, "{END#1}\n", 8) = 8
16:04:26.273687 write(1, "{END#1}\n", 8) = 8
16:04:26.273774 read(0, "It was a dark and stormy night.\n"..., 4096) =
122
16:04:27.364158 write(1, "SLAVE STDOUT> It was a dark and "..., 46) = 46
16:04:27.364232 write(2, "SLAVE STDERR> It was a dark and "..., 46) = 46
16:04:27.364338 write(2, "{END#2}\n", 8) = 8
16:04:27.364396 write(1, "{END#2}\n", 8) = 8
16:04:27.364454 read(0, "", 4096) = 0
16:04:27.365131 rt_sigprocmask(SIG_SETMASK, [QUIT RT_0], NULL, 8) = 0
16:04:27.365397 munmap(0x401e2000, 4096) = 0
16:04:27.365448 _exit(0)
Second case is the slave getting broken pipe(s) on stderr or
stdout. The strace below shows only one attempt to write to a broken
Re: Bug # 4123598 reintroduced in j2se1.4?
Nissyen wrote: > I have recently tried the new sun j2se distro, and I found that a bug which had > been closed in jdk1.2fcs seems to have reared its ugly head again. Specifically > bug 4123598 > (http://developer.java.sun.com/developer/bugParade/bugs/4123598.html). After > trying to interactively place a window it just places it at the upper left hand > side of the screen. > Has anyone else had this problem? > Chris #4102292, which is still open, is related. see: http://search.java.sun.com/Search/java?qt=4123598&col=obug&rf=0 If you think a more specific/focused (new) bug should be filed, you may want to follow up with Sun: http://java.sun.com/cgi-bin/bugreport.cgi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JDK 1.1.6v2
Please try the glibc test version jdk116_v3 which has a set resizable fix (and a vanishing frame fix). We test with a variety of Window Managers. Some use fvwm2, some use KDE 1.0, some use KDE Beta 4 (myself), AfterStep, MWM, etc. Some problem exist only under some window managers. We are working on tracking them down and fixing those inconsistencies. I hope this helps. Kevin B. Hendricks Blackdown JDK Porting Team [EMAIL PROTECTED] -- 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: JDK problem with findClass in native code
Please submit a full bug report to the http://www.blackdown.org/java-linux.html jitterbug Bug Database including the simplest sample code that shows the problem (both java and c) and we (the porters) would be happy to look into it for you. The simpler the code the better. By the way, I am not sure if this helps but jdk116 will return a Class Not Found Error message even when it finds the class but the there was an exception thrown in the method of the class. This error message should really be much better worded. Try invoking the java_g interpreter with the -tm (or was that -t) trace method option and look for exceptions being throuwn during the class init. Sorry, I can't be more help. Please submit a full bug report with sample code and we will see if we can fix it. Thanks, Kevin B. Hendricks Blackdown JDK Porting Team [EMAIL PROTECTED] -- 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: SIGSEGV 11 in JDK 1.1.6 4a!!!
Hi, Did you by any chance read the release that Karl posted that announced the JDK116_v4a? It talks about seg-faults and points people to the FAQ which has lots of things to try to help sort out old/new/incompatible system shared libraries. The FAQ talks about ld.so 1.9.9 and some problems it seems to be causing. There are some simple solutions (try removing the system shared library copies from jdk116_v4a/lib/xxx/green_threads) so that your own system libraries are used in place of those). Please read the FAQ, and if it doesn't help solve your problems, re-post to the list. Thanks Kevin Hendricks Blackdown JDK Porting Team [EMAIL PROTECTED] -- 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
JDK 116 V4a Issue Resolutions, Please READ!
JDK 116 v4a Issue Resolutions: Please READ! There have been a large number of reported problems with JDSK 116 v4a that are caused by incompatible system shared libraries in one way or another. Problems like these are really why a Linux distribution standard is desperately needed (IMHO). In an attempt to prevent the Jitterbug Database from overflowing with problems that are distribution dependent and easily fixed, here are some things to Please try before submitting a bug report: PROBLEM: SegFaults FIX: The system shared libraries that are shipped with the JDK are in some way incompatible with the shared libraries in your distribution. To fix this problem simply remove the system shared libraries that came with the JDK so that the system shared libraries of your own system are used. - remove libc and libdl from $JAVA_HOME/lib/XXX/green_threads/ where XXX is your archictecture PROBLEM: font problems with messages like: Warning: Name: textfield Class: XmTextField Character 'x' not supported in font. Discarded. FIX: There seems to be a problem with Motif loading and finding the libraries that deal with Locale issues on some distributions. To work around this issue make sure libBrokenLocale.so is found and linked to first (a Motif issue?) by doing the following: LD_PRELOAD=/usr/lib/libBrokenLocale.so java _name_of_class_file If this fixes your problem, you can edit your $JAVA_HOME/bin/.java_wrapper so that this is done automatically. PROBLEM: SO_LINGER, MULTICAST Socket error, bad parameter FIX: This was my fault. I was trying to improve socket performance and accidentally left some code in that I should have reverted. The problem is known and a fix will appear in the next release. If you roll your own from source, please contact me directly and I will post a patch for you. If you don't, and this is a "show stopper!" for you, I am sure we can make a development release available to hold you until the next release, or you can revert back to v2 or v3. We are working on coming up with a better solution to all of these problems. If we don't include system shared libraries in the JDK, then we get hundreds of reports of SEGFAULTS on startup from people whose systems are not up to date. If we do include them, we run the risk of having system incompatibilities like the ones we are seeing now. Our previous solution was to ship the key system shared librtaries with the JDK, knowing that people could easily remove them if incompatitibilities arose. We are now working on an install script that will automatically check these libraries and then "do the right thing". Also, Metro Link has nicely donated updated copies of its RedHat Motif to be used by the porting team for releases. This will hopefully clear up the font / textfield related problems in the future. I hope this information helps. Thanks for your support and sorry for any inconvenience. Kevin B. Hendricks Blackdown Java Porting Team [EMAIL PROTECTED] ------ Kevin B. Hendricks Associate Professor of Operations and Information Technology School of Business, College of William & Mary, 307 Tyler Hall, P.O.Box 8795, Williamsburg, VA 23187-8795 (757) 221-1702, [EMAIL PROTECTED]; http://business.tyler.wm.edu
Re: SEGV from iostream in native method on Linux, FreeBSD, not Windoze
Hi,
I tried your example code and it did not seg-fault. I received an
unsatisfied link error. Upon closer examination, the test.h file generated
by javah did not seem to be correct (i.e. it did not match your declaration
or parameter list in hello.C
Using nm on libhello.so showed this to be the case (some C++ name mangling?)
I simply copied the declaration from hello.C and replaced the appropriate
part of test.h with the correct (i.e. matching) declaration
Then my unsatified link error went away and everything worked fine.
There seems to be some trouble with javah and C++. I am not sure exactly
what is up.
Anyway, here are my slightly modified pieces of code:
The java code:
class Test
{
public native void display();
static { System.loadLibrary("hello"); }
public static void main(String[] args)
{
Test t = new Test();
t.display();
}
}
The C++ code:
/* hello.C */
#include
#include "Test.h"
#include
JNIEXPORT void JNICALL
Java_Test_display(JNIEnv *env, jobject obj)
{
cout << "Hello world!\n" << endl;
return;
}
/*
[user@ravel native]$ g++ -Wall -shared -fPIC
-I/usr/local/jdk1.1.6/include -I/usr/local/jdk1.1.6/include/genunix -o
libhello.so hello.C
---
[user@ravel native]$ LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH java test > err
2>&1
*/
And finally the "fixed" Test.h header file which you can compare to the one
generated by javah.
/* DO NOT EDIT THIS FILE - it is machine generated */
#include
/* Header for class Test */
#ifndef _Included_Test
#define _Included_Test
#pragma pack(4)
typedef struct ClassTest {
char PAD; /* ANSI C requires structures to have a least one member */
} ClassTest;
HandleTo(Test);
#pragma pack()
#ifdef __cplusplus
extern "C" {
#endif
JNIEXPORT void JNICALL Java_Test_display(JNIEnv *env, jobject obj);
#ifdef __cplusplus
}
#endif
#endif
I hope this helps.
I don't know why this is happening. If this solution makes "no sense" to
you please submit an official bug report to the Blackdown Jitterbug bug
database.
Kevin
Blackdown JDK Poriting Team
--
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
Metrowerks is releasing its JIT source code for Linux
Hi, In case any of you are interested. Metrowerks today announced it would provide its source code to its JIT compiler under a non-commercial source license very similar to that used by Sun's JDK source. This version runs on LinuxPPC and MkLinux right now (it also includes 68k support). Many of the Blackdown porters have volunteered to make ports to the other Linux Platforms. If interested, check out http://www.metrowerks.com (look in the upper left hand corner under News). Thanks, Kevin -- 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: Swing menu problem
Hi, The offset menu problem has been fixed in v4a (and v3). If you are still seeing it with v4a, please let me know what window manager you are using. Juergen Kreileder, one of the Blackdown porters, has done lots of testing on this issue (and other awt related issues with window managers) and here is what he posted to the porting list recently: >I'm aware of that problem (although I can't reproduce it with NetBeans >but with appletviewer using v4a/v5 and lesstif). > >Here's the latest report on window managers: >kwm, icewm, fvwm2, fvwm2-plus: OK > >scwm, fvwm95: frame changes location after unmap/remap > (setResizable()) > >fvwm: frame changes location after unmap/remap > some problem with repeatedly pressing the 'move +1+1' button > in the noresize example from bug #144 > >ctwm: the offset problem with appletviewer > changing the menu bar breaks the window's layout temporarily > >wmaker: the offset problem with appletviewer >changing the menu bar increases the frame's height by 1 > >olwm, olvwm: changing the menu bar breaks the window's layout > and can result in a segmentation violation Are you by any chance using WindowMaker? Please let me know which window manager shows the offset menu problem, and we will try to fix it in our next release. The sheer number of window managers and the fact that they are all not of equal quality or perform ops in the same way, results in lots of problems under awt. Kevin -- 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
ATTENTION: Java and SEGFAULTS
Hi, I will try this one last time. If you are getting seg-faults when using either java or javac upon startup they are caused by incompatible shared libraries (99 times out of 100). Before submitting a bug report try the following: - remove libdl.so and libc.so from $JAVA_HOME/lib/xxx/green_threads/ where xxx is your machine architecture (i.e. i386, ppc, i586, etc) Kevin -- 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: How long will it take to port 1.1.7 ?
Hi, Sun has messed up its non-commercial source distribution once again! I received my e-mail to grab the 1.1.7 source archive and the name they sent to me was simply not found. I asked the other porters and the same thing has held true for everyone who has tried to download anything! Sun made this exact smae mistake last time (with 1.1.6). This is getting really frustrating! To top it off, Sun gives no contact e-mail address, only a fax number for licenses. So it is next to impossible to inform them they f'd up again. If anyone works for Sun or has appropriate contact there, will you please ask them to check their non-commercial source distribution system again. None of the names they are sending out have been created yet! As for how long it will take to port 1.1.7? This will depend on how many changes were made to the source from 1.1.6. Most of our diffs should apply directly but we will have to apply them by hand to each file to make sure that our patch does not mess up a new fix added by Sun. Also the awt stuff seems to change alot each time and actually requires a whole bunch of patches to make it work right under a wide variety of window managers. So once Sun actually fixes their process and gets us the source code and assuming a reasonble number of changes (not a massive overhaul) we should have something in two weeks or so (BUT THIS IS IN NO WAY A PROMISE), just an estimate. This all assumes Sun will fix their still broken process! Kevin -- 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
Announcing: Sun JDK 1.1.7 V1 Port to Linux on PowerPC
Announcing: JDK 1.1.7 for MkLinux, Linux-PMac, and LinuxPPC New in this Port * This is our v1 port of Sun's JDK 1.1.7 final. - includes numerous bug fixes direct from Sun - fix for kernel accept() bug, caused slow Java Web Server - turn-off by: export JDK_NO_KERNEL_FIX=true Also Newly Available on this Site - * HotJava Browser 1.1.5 * Sun's Java Demos * Metrowerks JIT Compiler dated 981013 - fixes bug with link errors when JNI native code used - fixes bug with LSUB L2D sequence register allocation errors - now released under Metrowerks Non-Commercial License Special thanks goes to Juergen Kreileder (Blackdown x86 Porting Team) 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 all flavors of Linux. * * 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 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 Blackdown Java-Linux JDK Porting Team for PowerPC Kevin B. Hendricks [EMAIL PROTECTED]
Re: mklinux versions
Hi, If you are asking about MkLinux on PowerPC then that port is very much alive and in sync with the x86 ports (we build from one unified diff). Our current release is jdk 117 v1 and the Metrowerks JIT compiler is also available. The home page for MkLinux on ppc for jdk releated activities is: http://business.tyler.wm.edu/mklinux/ If you are asking about mklinux on intel, unfortunately I know nothing about it. I hope this helps. Let me know if you have any questions. Kevin -- 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
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
Sun and Linux
To answer your question: - Sun has licensed the 1.2 source under a special license to Steve Byrne who in-turn sub-licenses the source to us allowing us to get access to the 1.2 source early (in late October, early November) - Sun has provided 2 engineers that joined the Blackdown porting effort who did alot of the initial 1.2 port to Linux and who have/will answer techincal questions for us (a huge improvement over our previous situation!) - Sun has provided a JIT binary to Blackdown that works with x86 (the other cpus must come up with something on their own, luckily the PPC has access to Metrowerks JIT source) - Sun has provided Steve with the JCK so that we can finally tests the JDK and make sure it passes all of Sun's tests - Sun (via the 2 engineers) will be able to incorpaorate our patches/changes back into the source tree that will lighten the load of future upgrades. - Sun has provided Steve with a Sparc machine with which to help the Sparc port along. None of this was available under the previous non-commercial license. As far as I am concerned, I am very happy with Sun's support for Linux. My biggest fear was that Sun would take over complete control of the JDK port and only support the Sparc and x86 cpus leaving the PPC and Alpha out in the cold. They did not do this which makes me very happy. The engineers who have joined the team have ben very helpful answering questions and without them, the PPC port of 1.2 would still be non-existant. Because of this, JDK 1.2 is running well on PPC right now (with admittedly some bugs yet to iron out) which also makes me very happy. I hope this clarifies things somewhat. Kevin Blackdown Porting Team (for PPC) -- 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
Singal use in Native Threads jdk
Hi, I am not sure if this is the cuase of your problem, but the natiuve_threads jdk uses the signals to communicate between threads including SIGUSR1, SIGUSR2 (used by linuxthreads), SIGSTOP, SIGCONT (used to stop threads to allow garbage collection thread to run, and SIGUNUSED which is used by threads to interrupt one another (to allow java interrupts). So there is alot of signal activity going on in the native_threads port. Also note, the java thread stack dump may not be reporting signal names (numbers) properly so what you are seeing might really be one of these signals. I hope this info helps. Please let me know if you need more info. Kevin Blackdown Porting Team (for PPC). -- 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: problems with jdk117 on linux ppc, please help.
Hi, I am running Paul's 2.1.125 kernel on my G3 system and I ran your test code on my system and it worked perfectly: Here is the output of the compile and run: [root@kbhend local]# javac Test.java [root@kbhend local]# java Test OK I think this is a library conflict. After you used rpm to upgrade to glibc version 1m, did you perform a complete shutdown and restart? Doing an ldconfig is not enough to flush the contents of the shared library cache for libraries that are currently being used (like glibc) by other programs. (I have found this out the hard way!) You will get the seg-fault you describe with the old glibc installed from R4. Please try the following: rpm -Uvh glibc*1m* (you might have to try rpm --force -ivh glibc*1m*) shutdown -r now Once it gets back up, check what rpm -q glibc returns. If should be the 1m version. Then retry your sample program. It should work. It works fine on my system. If it still fails, e-mail me directly and we can see what other libraries differ between your linuxppc machine and mine. I hope this helps. Kevin (Blackdown porting team for PPC). -- 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: problems with jdk117 on linux ppc, please help.
Hi, Did my suggestion about reinstalling glibc 1m and doing a complete shutdown and then reboot, fix your seg-fault problem? Please let me know if I can move your jdk bug-report to the completed directory. Thanks, Kevin -- 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: v2-test KeyEvent bug, Other Bug fixes coming!
Sun in 1.1.6 introduced a new way of generating keyTyped events that interferes with the correct generation of KeyPressed events. I have fixed this problem (it appears in Solaris 1.1.6) and added the patch to the code base. The PowerPC JDK just released an updated jdk116_v2a that fixes this problem (and many others, see the list below). So all of these fixes should appear in the v3 release of jdk116 from the x86 camp when Steve comes back and Karl returns from his honeymoon! Here is the list of things fixed in PPC jdk116_v2a that should appear in an upcoming release on x86 / Sparc platforms: - Bad or Missing KeyPressed events are fixed (a Sun bug) - X11Graphics_drawString multi-thread corruption fix (a Sun bug) - List fix to allow removing item 0 (thanks Juergen and Steve) - getlocalhost fix (chis) - workaround for Motif bug that causes seg-faults I am also working on fixing the blocking on STDIN ready thread problem. A fix should come soon and sooner if Does anyone know (under Linux) can you set one fd to be blocking (such as stdin) and a dup of that fd to be non-blocking at the same time? According to Steven's Advanced Unix Programming, you can not under most Unixes? Does anyone know the correct answer? Thanks, Kevin B. Hendricks [EMAIL PROTECTED] Linux PPC, JDK port -- 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: jvm support for >1024 fds
A few words to clear this up. > The kernel does support it. The only problem is that the JVM is using > select(2) when it should use poll(2). No, this is not correct. The 1.1.7 JDK for glibc uses poll and not select (I know because I rewrote it to use poll). The problem is that glibc 2.0.7 replaces calls to poll with calls to select since sub 2.0 kernels did not support poll. Look at the glibc 2.0.7 (2.0.6) source rpm and you can find the code that converts a call to poll to a syscall to select. If you are using a 2.2 or 2.1.xxx kernel, you might try rewriting that code in glibc to make it use poll (i.e. stop the conversion to select) Another solution is try the upcoming glibc 2.1 version. You can check the source to see if they do a real poll (i.e. don't convert it to select). Note, libc5 versions of the JDK, do use select because of a lack of a poll function. I hope this clears things up. Kevin Hendricks Blackdown porting team (now back to JDK 1.2 debugging!)
Re: jvm support for >1024 fds
Hi, > On some OSes, poll() has >turned out to be a performance dog compared to select(). If anyone >listening has the configuration and time to try Kevin's suggested test: >it would be worthwhile to hack together a little benchmark to ascertain >whether poll() will give us another reason to complain about Java >performance. Given that select must look through all of the fds+1 that you are selecting over and poll does not, a true "poll" should work much much faster for larger sets of fds. This is the reason the kernel 2.X series is moving to "poll" and away from select. In fact, inside the 2.1.XXX kernel code (and I assume 2.2*) select is actually implemented in a poll-like manner. I do believe, poll is correct for the present and future of the JVN, select is okay for small sets of fds, but a true poll should be faster and allow for future expansion better. I hope this helps. Kevin -- Kevin B. Hendricks Associate Professor of Operations and Information Technology School of Business, College of William & Mary, 307 Tyler Hall, P.O.Box 8795, Williamsburg, VA 23187-8795 (757) 221-1702, [EMAIL PROTECTED]; http://business.tyler.wm.edu
JDK 1.2 TimeTable Not Possible Yet, Status Report
Hi, In an attempt to stop the flood of "when will jdk 1.2 be out", here is a short status report: The JDK 1.2 runs "reasonably well" under native threads for x86, PPC and Sparc. Work on other processors is continuing. BUT there are problems that need to be resolved before we can ship. The most pressing concern is a non-obvious problem in native threading (or linuxthreads?) which causes hangs on single processor machines and seg-faults on SMP machines. This prevents the JCK from completing which in turn prevents us from shipping it. We are attacking the problem in 2 ways. Dr. Phill Edwards, the author of the 1.1.7 native threads is now looking at it (1.2 and 1.1.7 use different native_threads implementations). Others are porting/fixing green_threads to work on JDK 1.2. If we can pass the JCK under green_threads we can ship and fix the native threads in a later release or visa-versa. So we can't actually quote a delivery date. As Steve pointed out, we *must* pass the JCK *before* we can ship anything!. Until these problems are solved, we simply can't get the JCK to run to completion without hanging. We are *all* working on the problem and hope to come up with a solution soon, but we simply can not promise any one date. Please be patient. Also, please remember, we are all volunteers with other "real" jobs that must come first. We are doing our best. Kevin Blackdown Porting Team! ------ 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
Another JDK 1.2 Status Report
Hi, I thought I would pass along some good news. The porters ran with plan B and so we now have a working green_threads version that can and does run the JCK to completion without hanging on both x86 and ppc. We still have to find and fix all of the errors reported by the JCK, but at least now we can actually run it. We still can't quote a date, but now at least we are moving forward again and can hopefully pass the JCK under green_threads and worry about finding and fixing the native_threads (linuxthreads?) problems after our initial releases. Sorry, I can't provide more info, but rest assured we are all working hard to get this thing out the door as soon as possible. I am sure Steve Byrne will let the list and the world know when he is ready with the x86 release with the other platforms to follow along soon after. Kevin Blackdown Porting Team for PPC -- 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:RMI on Linux, Class Not Found Error Message
This may or may not be the cuase of your problem but it sure sounds like it. The error message "class not found" on jdk116 should really say: class not found...error in class initializition? It seems for security purposes, 1.1.6 will report class not found and abort if there are any exceptions during the initialization of the class (or any classes the initialization uses). The exception is actually generated by 1.1.5 also but 1.1.5 continues on and processes. 1.1.6 does not. To check if this is your problem (again it may not be..), I use the trace methods command line option to java_g and look for exceptions being thrown during the class intialization someplace (this generates alot of stuff so you may want to redirect it to a file for later searching). i.e java_g -tm CLASSNAME I hope this helps. Kevin H. -- 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
Still more upcoming bug fixes for the jdk for v3
Hi all, While Karl and Steve are out of town, I wanted to let you all know there has still been some action fixing bugs in the jdk. All of these bug fixes are undergoing testing and should appear in the next x86 release (given there are no problems). Here is what is fixed so far: - blocking on stdin, stdout, and stderror that causes ready threads not to run (a Sun bug) - deadlocks happening in the finalizer thread with various other threads holding locks (a Sun bug). This fixes hangs in startup of NetBeans 2.0 Beta and FreeBuilder - X11 Graphics drawstring cross thread corruption (a Sun bug) - Missing or incorrect KeyPressed events (a Sun bug) - Workaround for Motif bug that causes various seg-faults (a motif bug) - List fix to allow deletion of item 0 - getlocalhost fix - fix for JNI native call problems (affects PowerPC port only) We on the powerpc side have already made a number of fixes available in a v2a release. We are planning a v2b release to include the remainder of them. As soon as Steve, and Karl get back and more testing is done, I am sure most if not all of these bug fixes will make in into v3 for x86 and Sparc. Please let me know if you have any questions reguarding this fixes/bugs. Thanks, Kevin B. Hendricks Linux PowerPC JDK Porting Team [EMAIL PROTECTED] -- 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
Announcing JDK 1.1.6 V3 for MkLinux, Linux PMac, Linux PowerPC
Hi, Your Linux PowerPC JDK Porting Team is pleased to announce JDK 1.1.6 Version 3 for Linux on PowerPC. This release is available from our website and should soon be available on our mirrors: http://business.tyler.wm.edu/mklinux/index.html or for slower connections that don't like java on web pages try http://business.tyler.wm.edu/mklinux/main.html (We have recently had DNS troubles. If you have a problem replace business.tyler.wm.edu with 128.239.101.49) New in this Release --- * This is our v3 port of Sun's JDK 1.1.6 final. - Bad or Missing KeyPressed events are fixed (a Sun bug) - X11GraphicsdrawString multi-thread corruption fix (a Sun bug) - List fix to allow removing item 0 - getlocalhost fix - workaround for Motif bug that causes seg-faults - fix to prevent hanging graphics under fast graphics updates (ala CM3) - turn-on by: export JDK_IO_FIX=true - turn-off by: unset JDK_IO_FIX - fix to allow real non-blocking io on stdin, stderr, stdout (a Sun bug) - fix for Finalizer thread caused deadlocks (a Sun bug) - fix for JNI problems with egcs -O2 - fix for frame borders / sizing (a Sun bug) - fix for offset menus when using Swing - fix for non-resizable frames (a Sun bug) - fix for signal names in java stack/thread dump Also available on this site are: - Metrowerks supplied JIT for Linux PowerPC - HotJava Browser 1.1.4 - Swing 1.0.3 Have Fun! Kevin --- This system is powered by the Mercere mailing list suite --- http://www.oeil.qc.ca/Mercere/ -- Kevin B. Hendricks Associate Professor of Operations and Information Technology School of Business, College of William & Mary, 307 Tyler Hall, P.O.Box 8795, Williamsburg, VA 23187-8795 (757) 221-1702, [EMAIL PROTECTED]; http://business.tyler.wm.edu
Re: Socket connect timeout (user threads and blocking)
Hi, Just to clarify a few things. There is very little difference in performance between a user based green_threads implementation and a kernel threads (native) implementation (except for scheduling rules) on single processor systems. If done well, user based threads can even be faster than kernel based (native) threads on single processor systems due to the need to set and restore a smaller context (less overhead during switching). The v3 version of jdk116 uses non-blocking io for all io system calls including stdin (that was one of the fixes for v3). So user threads do not (should not!) block on io and the entire user based thread package does not stop. This works as follows: A call is made to an read from an fd (which has already been set to be non-blocking). It will return errno equal to EAGAIN immediately if no data is ready to be read. That user thread will then enter a waiting list and yield to the next thread. It will stay that way until a sigio comes in. The signal handler does a select() to determine which of the waiting threads are ready to run (i.e. their file descriptor is ready for io) and that thread is awakened. I hope this description helps. Although the green threads model catches alot of flack, it it not that much different from a user-based pthreads implementation. Sun just needs to fine tune it abit more "some might say a lot!". Hopefully a native threads version will come soon (a few people are working on it), but don't expect a big performance boost on uni-processor machines. Please let me know if I haven't explained this well. I hope this helps. Kevin Linux PPC JDK porting team [EMAIL PROTECTED] ------ 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:long delay in reading from atm socket...
Hi, I think your bug is related to Bug #97 in the jitterbug. Please give it a read. If so, we have just fixed that bug (which should greatly improve our vmark results!). Tests are being done now to make sure we haven't broken anything else when fixing this. So hold on and v4 should fix this (if time is improtant, you might want to ask the x86 porters for a pre-v4 build just to see if it does indeed fix you problem (one is available for linux ppc now). I hope this helps. Kevin LinuxPPC, MkLinux JDK Porting Team [EMAIL PROTECTED] -- 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:3rd JDK for Linux/Intel available (OpenGroup)
Hi, You asked about benchmarks. One of the x86 porters from Blackdown named Juergen Kreileder tested both the upcoming Blackdown jdk116_v4 against the OSF Opengroup's jdk116_v1 (native threads) and Netscape-4.06-glibc on a Dual PPro 233MHz system. Here are his results: ---cut--- Blackdown OSF Netscape-4.06-glibc Caffeinemark 3:448 387175 + TYA 1.0:943 886 Volano Mark 1: 598 I couldn't get OSF + vmark working, it always fails with 40 connections so far. Creating room number 3 ... thread creation failed java.lang.OutOfMemoryError at COM.volano.x.ł(Unknown Source) at COM.volano.b.(Unknown Source) at COM.volano.Mark.ů(Unknown Source) at COM.volano.Mark.main(Unknown Source) ---cut--- So our green_threads implementation is actually faster than their native threads routine right now (which I expected given the overhead of context switches with kernel based threads), but this is just their first release which means they will improve! If the earlier thread was correct about the OSF having the swing offset menu problem, then they used our diffs to generate their port (at least as a beginning basis). That is a bug I introduced by mistake and was not fixed until V3. Given their product is heavily based on the hard work of the Blackdown team, you would think they would share their diffs. Unfortunately, they have refused all requests to share diffs. So much for being the OpenGroup (IMHO). Kevin B. Hendricks Linux PowerPC / MkLinux JDK Porting Team [EMAIL PROTECTED] ps. By the way, our v4 should come out soon with a couple of importqant bug fixes and more to come! -- 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
My reply to Bug 112 (now in known bugs)
Hi, Did you receive my reply to Bug 112 (now in known bugs)? Is this the same error that caused you earlier error message? Thanks, Kevin -- 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
Announcing JDK 1.1.6 V4a for MkLinux, Linux PMac, Linux PowerPC
Hi, Your Linux PowerPC JDK Porting Team is pleased to announce JDK 1.1.6 Version 4a for Linux on PowerPC. This release is available from our website and should soon be available on our mirrors: http://business.tyler.wm.edu/mklinux/index.html or for slower connections that don't like java on web pages try http://business.tyler.wm.edu/mklinux/main.html (We have recently had DNS troubles. If you have a problem replace business.tyler.wm.edu with 128.239.101.49) New in this Release --- * This is our v4a port of Sun's JDK 1.1.6 final. - fix for removes from choice list (a Sun bug) - new fix for set frames non-resizable - fix for mwm based window manager frame positioning - fix for disappearing frames problem (a Sun bug) - fix for open sockets causing poor GUI performance - fix for kernel accept() bug, which caused slow Java Web Server - turn-off by: export JDK_NO_KERNEL_FIX=true - fix for button 1 modifier value - improvements in russion font properties - fix for CET to be Central European Time - etc. Also available on this site are: - Metrowerks supplied JIT for Linux PowerPC - HotJava Browser 1.1.4 - Swing 1.0.3 Have Fun! Kevin --- This system is powered by the Mercere mailing list suite --- http://www.oeil.qc.ca/Mercere/
Re: finalize() problems
Hi, Sun has some serious problems in the 1.1.X series with finalization. Basically the finalizer thread can hold locks and threads waiting to be finalized can hold locks and can be waiting for finalization. Obviously, this can easily result in deadlocks (the finalizer needs to wait to obtain a lock while the thread holding that lock is waiting to obtain a finalization queue lock). Sun knows that this is a serious problem, but to fix it given the way finalization is done under 1.1.X is not easy and so they decided to only include a fix in 1.2 (which we don't have access to yet). To prevent the deadlocks, in jdk116_v3 and higher, we have not allowed threads to wait in the finalization queue. Instead they just return false. This greatly slows down finalization but does not stop it (and prevents deadlocks!). If the finalizer queue is empty and finalize() is called, the finalization will be done. If you truly want your application to work well on *all* java platforms, please don't use the finalize() call to do almost anything! (even loading a class can be a problem since there is a class loading lock). At least until 1.2 is out and everybody is using it on all platforms. Our changes might be causing your problems (but they are fixing others, ie. the deadlocks that prevented many programs from launching at all). If you have a SMALL sample program that illustrates this problem, we would be happy to try and track down the specific problem and try to get all things working. Also, you might want to try checking the return value from finalize() to see if it needs to be called again. If you can generate a small sample java program, please submit it using the Blackdown bug database. Thanks, Kevin Hendricks Blackdown JDK porting team member -- 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
SUN: Please Open Source Javadoc.
(sorry for the spam) I drew up a proposal that asks for SUN to Open Source Javadoc, a basic tool from the JDK. This would be a big help to the entire Java community and an excellent sign of good faith from SUN. http://relativity.yi.org/WebSite/opensource-javadoc/ Kevin -- Kevin A Burton ([EMAIL PROTECTED]) http://relativity.yi.org Message to SUN: "Open Source Java!" "For evil to win is for good men to do nothing." -- -- To subscribe:[EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Archives and Other: <http://java.apache.org/main/mail.html> Problems?: [EMAIL PROTECTED]
Re: Sun's Java as OSS?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andreas Rueckert <[EMAIL PROTECTED]> writes: > Hi! > > http://slashdot.org/article.pl?sid=00/10/25/1331227&mode=flat I may be somewhat synical. But put your money where your mouth is! You talk the talk but can you walk the walk? :) Everyone is saying stuff like 'we are going to OSS X application'. They are doing this for marketing. What they really need to do is say that Java *will* become Free Software (not Open Source) and here is the date. I am not sure I even want SUNs help in the Free Software/Java community. They have screwed a lot of thigns up. I would just rather see Kaffe/GJC/Classpath go their logical directions and not have SUN involved. If they want to make Java Free Software then good but I don't think the community should hold their breath. Kevin - -- Kevin A Burton ([EMAIL PROTECTED], [EMAIL PROTECTED], UIN: 73488596) For evil to win is for good Men to do nothing. - Winston Churchill. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.1 (GNU/Linux) Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt iD8DBQE595NvAwM6xb2dfE0RAhj+AKDKeLHWvcO6H2CBKShoPH6xJTLedQCdEcwm rn908EfB7NZ4SgPj7L1JGlY= =A5AU -END PGP SIGNATURE- ammunition Khaddafi Clinton fissionable explosion SEAL Team 6 kibo Nazi assassination [Hello to all my fans in domestic surveillance] Kennedy SDI Mossad Uzi PLO -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sun's Java as OSS?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andreas Rueckert <[EMAIL PROTECTED]> writes: > Hi! > > On Don, 26 Okt 2000 Kevin A. Burton wrote: > > > > >I am not sure I even want SUNs help in the Free Software/Java community. They > >have screwed a lot of thigns up. I would just rather see Kaffe/GJC/Classpath go > >their logical directions and not have SUN involved. If they want to make Java > >Free Software then good but I don't think the community should hold their breath. > > I wonder how much a GPLed Sun Java would help Classpath. Would it mean that > those who had to take a look at the Sun sources could contribute to the project? > That might mean a lot of new and skilled contributors to the project. Good point... :). If SUN were serious they would violate all those stupid NDAs they asked people to sign. SUN is just another big stupid company IMO. Nothing different than Microsoft/Oracle. If you want bugfixes for Solaris (in some situations) you have to sign an NDA. I would love to see these agreements evaporate! I don't think any of SUNs GPL contributions (if it ever happens) would even help. Their code *sucks* and only really matters to their shipping VMs. All of the code relies on your VM having a specific set of native methods that aren't documented and aren't standard anywhere. Maybe some of the 100% Java code could be taken an merged with Classpath but I certainly don't think anyone would use SUNs code as is. Kevin - -- Kevin A Burton ([EMAIL PROTECTED], [EMAIL PROTECTED], UIN: 73488596) ~/.signature: No such file or directory -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.1 (GNU/Linux) Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt iD8DBQE5+Oj2AwM6xb2dfE0RAuWbAJ91wbNuhZZwlNwEpVEiZL0oxo+SFQCePYYD KU4Une+s1FOgv3VGoQl/MCA= =4sJQ -END PGP SIGNATURE- Ortega kibo DES cracking security Honduras domestic disruption AK-47 explosion cryptographic smuggle Cocaine World Trade Center Peking counter-intelligence -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Vote of 'No Confidence' in SUNs 'guidance' for Java.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OK. As some of you know I am fairly vocal WRT a reliable implementation of Java for the Free Software community (something like GJC, Classpath, Kaffe). I created a poll to get feedback from the Java development community to help make it obvious to SUN that we want Java to be Free Software/Open Source (http://relativity.yi.org/java). The results were excellent. 61.1% wanted Java to become Open Source and another 14.5% wanted SUN to push it through a standards commitee (even though they said they will not do this). I would like to think that this helped push SUN in the right direction with their recent announcement at ApacheCon (http://slashdot.org/article.pl?sid=00/10/25/1331227&mode=thread). What I didn't do at the time was something more firm or revolutionary. Something like a 'line in the sand' that people would not cross when developing Java applications. Something like a 'Vote of No Confidence' in SUNs control of Java. I was thinking that it would be a document that Internet users can sign and will have something the following: - - I will stop using Java in X month(s) if: - Java is not released by SUN under an OSS license. - You do not void NDAs that you have asked Java developers to sign as part of the JCP and misc licensing. - You do not allow community members to participate in the JCP with any requirements. If this does not happen within X timeframe I will move to another language (python) or move to a Free alternative (GJC). then it would say something like we realize that SUN can't talk open about this because of current licensing restrictions and politics but want to ensure that they are going in the right direction and that if they want our support whey have to meet this deadline. - - I am not sure it is an awesome idea but is certainly 'an' idea. :) I guess it would only matter if a large number of Java developers would sign it. Kevin - -- Kevin A. Burton ( [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] ) To fight and conquer in all your battles is not supreme excellence; supreme excellence consists in breaking the enemy's resistance without fighting. - Sun Tzu, 300 B.C. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.1 (GNU/Linux) Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt iD8DBQE5+p8wAwM6xb2dfE0RAho9AKCyHsv5fZpiHPSfinPrKPJTBftmVQCeJnn+ 1uFgucRegSB5amHKXE9QeEo= =+JEp -END PGP SIGNATURE- quiche Qaddafi Cocaine Ft. Bragg domestic disruption radar Uzi plutonium genetic CIA DES Treasury explosion class struggle kibo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: java developer feedback
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Calvin Austin <[EMAIL PROTECTED]> writes: > We are coming to the end of a great year for Java on linux, > hotspot has finally arrived on linux as well > as the optional packages JMF and Java 3D, additional chipset > ports, plugin support for mozilla and netscape to name a just > few achievements. > > In moving forward I would be very interested in areas that > you believe Blackdown and Sun should focus on, in particular > what do you plan to use the linux port for, whether its as > a development machine or rolling out into production. What > would help you become more productive. Which bugs, like > the international keyboard bug are causing problems for you. > > You can email me directly but if you have information that > would be interesting to other developers, like adoption of > linux at your company or school then maybe those could be > sent to the alias as well Honestly. I think that next year will be sink or swim for Java. There are only two paths that I see: - - SUN tightens control or stagnates it (meaning Java still is a proprietary product of SUN) - - SUN works with the community to ensure that Java is Free Software/Open Source. If it is the former, Java is dead. If it is the latter than the future is bright! It is time that SUN makes good with the early promises that they made the community. That is: Freedom from proprietary standards, WORA (Write Once Run Anywhere), and standards. Java has failed to deliver on any of this. All we are asking is that SUN helps Java (which I believe it wants to do) and deliver on promises it has made. You want feedback? The feedback is work with the community or see projects like the GNU Java Compiler take Java and make it an open standard without SUNs help. I don't want to see this happen because cooperation is a Good Thing but I am worried we are headed down that path. :( Anyway... Software control == bad. Open Standards == good. Lets work towards this :) Kevin - -- Kevin A. Burton ( [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] ) Cell: 408-910-6145 URL: http://relativity.yi.org The more you tighten your grip, the more systems will slip through your fingers. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.2 (GNU/Linux) Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt iD8DBQE6DKW8AwM6xb2dfE0RAs6QAJ9BbISXQDcfbXfRawWMpwrROyYYSwCeK5E3 pvQgEwukikaLucGxD6lfW+E= =1SAg -END PGP SIGNATURE- BATF counter-intelligence Ft. Bragg assassination Saddam Hussein munitions SEAL Team 6 Uzi World Trade Center Khaddafi AK-47 DES Honduras NSA Noriega -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Setting JAVA_HOME path on Linux 7.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 "Lambert, Stephen : CO IR" <[EMAIL PROTECTED]> writes: For starters... There is Linux 7.0. You are probably refering to RedHat 7.0 (RedHat != Linux) which is running Linux Kernel 2.2.16 > JAVA_HOME=/usr/local/jdk1.3 > export JAVA_HOME when you launch bash what does 'echo $JAVA_HOME' give you. Also try putting to 'echo IT WORKED" lines in your /etc/bashrc to see if it worked. I use a .bashrc myself and it works fine. > Also, when I shutdown the server, it requires /sbin/./shutdown -h now seems like a PATH problem - -- Kevin A. Burton ( [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] ) Cell: 408-910-6145 URL: http://relativity.yi.org Linux. The *only* Operating System you will ever need. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.2 (GNU/Linux) Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt iD8DBQE6DKZXAwM6xb2dfE0RAhNfAKClDXhyaMsfRzTAaD/B7Ntax9/1ywCgxS9m AfMERBoOqsTg7NwESHqtRLk= =H7z6 -END PGP SIGNATURE- Albanian munitions Semtex class struggle ammunition Uzi PLO Ortega DES North Korea BATF FBI explosion South Africa Mossad -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Session Close
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 "Pablo Trujillo" <[EMAIL PROTECTED]> writes: > I need to execute a procedure when a session closes. Is this possible? How > it is made? Firstoff. :). Java doesn't have procedures... I think you mean a method. Second. What type of Session? Servlet? Kevin - -- Kevin A. Burton ( [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] ) Cell: 408-910-6145 URL: http://relativity.yi.org The unconstitutional government for the corporation, by the corporation must be overthrown! -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.2 (GNU/Linux) Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt iD8DBQE6Ck+mAwM6xb2dfE0RAsiNAJwMGTmuree6Os5HtnoI9AAvW2DLfQCgj2Xk FoFRJOmClJXLD+MGTPl6x2s= =BTm5 -END PGP SIGNATURE- KGB SEAL Team 6 Khaddafi Ft. Meade supercomputer SDI Clinton DES AK-47 Qaddafi Nazi bomb Treasury jihad fissionable
Re: IBM PPC 1.4.1 Question
Hi, You probably want to read the following exchange at ibm.software.java.linux if you own a G4 based machine and check you exact /proc/cpuinfo against the list that IBM provided. I can confirm ... if I recompile kernel/arch/ppc/kernel/setup.c and tell it to lie and report a dual "604e" system instead of a "7455, altivec supported" as the cpu type in /proc/cpuinfo the IBM JDK 1.4.1 with JIT enabled nicely starts up and works. So there is no reason to restrict 74XX pprocessors at all. Here is a summary of what was posted to the newsgroup. > This was the reponse I got back from the ibm.software.java.linux newsgroup. > > > > Re: IBM 1.4.1 PPC Core Dumps > From: > Neil Masson <[EMAIL PROTECTED]> > Reply-To: > [EMAIL PROTECTED] > Date: > Tuesday 10 June 2003 03:32:51 > Groups: > ibm.software.java.linux > > Kevin Hendricks wrote: > > Hi Neil, > > > > /proc/cpuinfo on my machine shows: > > > > processor : 0 > > cpu : 7455, altivec supported > > clock : 999MHz > > revision: 2.1 (pvr 8001 0201) > > bogomips: 996.14 > > > > processor : 1 > > cpu : 7455, altivec supported > > clock : 999MHz > > revision: 2.1 (pvr 8001 0201) > > bogomips: 996.14 > > > > total bogomips : 1992.29 > > machine : PowerMac3,5 > > motherboard : PowerMac3,5 MacRISC2 MacRISC Power Macintosh > > detected as : 69 (PowerMac G4 Silver) > > pmac flags : > > L2 cache: 256K unified > > memory : 768MB > > pmac-generation : NewWorld > > This is a list of supported processors for Linux/PPC: > 604 > 604e > 604r > 604ev > 750 > Power3 (630) > Power3 (630+) > I-star > S-star > Power4 > R64-III (pulsar) > POWER4 (gp) > RS64-III (icestar) > RS64-IV (sstar) > POWER3 (630) > POWER3 (630+) > > Neil > > --- > > > So it looks like IBM is deliberately choosing to not support 74XX (G4) > processors in their latest JIT. I find this hard to belive. > > I posted the following as a response that message: > > > --- > > Re: IBM 1.4.1 PPC Core Dumps > From: > Kevin Hendricks <[EMAIL PROTECTED]> > Date: > Tuesday 10 June 2003 07:57:22 > Groups: > ibm.software.java.linux > > Hi Neil, > > > This is a list of supported processors for Linux/PPC: > > 604 > > 604e > > 604r > > 604ev > > 750 > > Power3 (630) > > Power3 (630+) > > I-star > > S-star > > Power4 > > R64-III (pulsar) > > POWER4 (gp) > > RS64-III (icestar) > > RS64-IV (sstar) > > POWER3 (630) > > POWER3 (630+) > > You are joking right? Why restrict out all 745X > processors for no reason? As I said, the IBM JIT > from 1.3.1 works fine. So does the entire IBM JDK 1.4.1 > if you disable the JIT. > > Was this done on purpose? And if so, for what reason? > What technical justification could there be not supporting > G4 processors if you support the 604 instruction set > and G3 instruction sets and your JIT from 1.3.1 works > fine on this exact same machine? > > Thanks, > > Kevin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What is 1.3.1-02d-FCS version of JRE???
Hi, > Does anyone know what this 02d version is? Where did it come from? > Why is it not available on the Blackdown download mirrors? It is mine. I was a member of Blackdown (and technically still am but I have not contributed anything in a very very long time). I rebuilt JDK 1.3.1 for ppc Linux to update it to gcc 3.2.2 and to replace a glibc private call that no longer exists in curent glibc versions just so that it will keep working for PPC Linux (especially the mozilla plugin). This was required to keep JDK 1.3.1 working well enough to build OpenOffice.org and to run Mozilla. Jack Howarth (I believe) also built Debian specific packages for this version and they were uploaded to Blackdown at one point but never seemed to make it out onto the Blackdown mirrors. The JDK available from the yellowdog ftp site was posted there by me (version 2d) in support of the OpenOffice.org project (also a Sun project). (I am the PPC Linux porting person for OOo and the porting project co-lead there). Since the Blackdown PPC Linux project was so small and I had such a hard time finding anyone to help it along, I finally just pretty much gave up. I have only done the barest minimum to keep the Blackdown JDK 1.3.1 functioning (it has no hotspot or JIT). I simply can not compete with IBM's JDK 1.4.X with fancy JIT available for both Linux ppc 32 and ppc64. I do know there are some people still interested in PPC Linux support so they may have something interesting to add. Hope this helps, Kevin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
