Choice component problems

2000-02-03 Thread blake

Has anyone else ever had any problems with Choice components screwing up
the ability to enter events with the keyboard, (Like enter text in a
textfield) without taking focus out of the application first?

Please let me know if you have even noticed it.  And especially if you have
any work-arounds?

This problem is apparently only relevant to linux, FreeBSD's JVM doesn't
have the same problem.

I may just switch everything to FreeBSD if I don't find a fix.

   ~blake



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: Choice component problems

2000-02-03 Thread Ingo Rockel

Hi!
If I remember right, this is a Motif-Problem (It sometime also occurs
under netscape)

Greetings,

Ingo

* **
**  "Linux is like living in a teepee. No Windows, no Gates,   * 
***  Apache in house." Usenet Signature 
 ***
*   Ingo Rockel, EMAIL: [EMAIL PROTECTED] **
**   Homepage: http://inro.da.ru   *


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: Choice component problems

2000-02-03 Thread blake

::cough-WindowMaker-cough:::


At 2:17 AM -0600 2/3/2000, Ingo Rockel wrote:
>Hi!
>If I remember right, this is a Motif-Problem (It sometime also occurs
>under netscape)
>
>Greetings,
>
>   Ingo
>
>* **
>**  "Linux is like living in a teepee. No Windows, no Gates,   *
>***  Apache in house." Usenet Signature 
> ***
>*   Ingo Rockel, EMAIL: [EMAIL PROTECTED] **
>**   Homepage: http://inro.da.ru   *




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: Choice component problems

2000-02-03 Thread Ingo Rockel

On -1 xxx -1, blake wrote:

> ::cough-WindowMaker-cough:::
The JDK uses Motif.

Ingo

* **
**  "Linux is like living in a teepee. No Windows, no Gates,   * 
***  Apache in house." Usenet Signature 
 ***
*   Ingo Rockel, EMAIL: [EMAIL PROTECTED] **
**   Homepage: http://inro.da.ru   *


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: Choice component problems

2000-02-03 Thread blake

I had an feeling I was going to learn something new by posting that :-)

Do you know of a possible work-around?  I really would like to be able to
use Choice boxes without switching to FreeBSD.

At 2:55 AM -0600 2/3/2000, Ingo Rockel wrote:
>On -1 xxx -1, blake wrote:
>
>> ::cough-WindowMaker-cough:::
>The JDK uses Motif.
>
>   Ingo
>
>* **
>**  "Linux is like living in a teepee. No Windows, no Gates,   *
>***  Apache in house." Usenet Signature 
> ***
>*   Ingo Rockel, EMAIL: [EMAIL PROTECTED] **
>**   Homepage: http://inro.da.ru   *




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Pipes

2000-02-03 Thread marcus . monaghan

Dear List,
Can someone please tell me how to create a named pipe in java?

Cheers,
Marcus

++
| Marcus Monaghan|
| BOOT Computers Limited |
| Tel : 01270 611299 |
| Fax : 01270 611302 |
+ ---+


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: No swing classes

2000-02-03 Thread Jacob Nikom

I think if you download Blackdown RC4 you are not going to have
those messages. You also can try the solution from Nathan Meyers
book. Look at 
http://www.javalinux.net/JavaLinux/CDROM/Chapter14/font.properties

Jacob Nikom

Jeff Galyan wrote:
> 
> paul campbell wrote:
> >
> > Works OK - well sort of...
> >
> > (except "Font specified in font.properties not found[--symbol blbah blah
> 
> This one's a known issue. I think there may be a fix for it - check the
> Blackdown.org site.
> 
> > and
> > Could not load Look and Feel:
> > com.sun.java.swing.plaf.windows.WIndowsLookAndFeel
> > when I clicked the "Windows" radio button.
> > )
> >
> 
> This is expected behaviour on non-MS systems. The decision was made to
> simply not allow the Windows look & feel to be loaded except on Windows
> (although the classes *are* there), since Microsoft hasn't given
> permission to Sun to use the Windows look & feel anywhere except
> Windows.
> 
> --
> Jeff Galyan
> http://www.anamorphic.com
> http://www.sun.com
> jeffrey dot galyan at sun dot com
> talisman at anamorphic dot com
> Sun Certified Java(TM) Programmer
> ==
> Linus Torvalds on Microsoft and software development:
> "... if it's a hobby for me and a job for you, why are you doing such a
> shoddy job of it?"
> 
> The views expressed herein do not necessarily reflect those of my
> employer.
> 
> Sun Microsystems, Inc., has no connection to my involvement with the
> Mozilla Organization.
> 
> --
> 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]



JMF and Linux .. help please...

2000-02-03 Thread Gayathri Viswanathan

Hi !
I have an application that works fine on WinNT and when I try running it on
Linux with RedHat 6.1, jdk1.2.2 rc4 and the all-java version of jmf, the jmf
application does not work. In fact the SimplePlayerApplet (sample from JMF)
does not work either. If I change the threads to be green then the
SimplePlayerApplet works but then some of my application's threads dont seem
to get started. (Like my SourceStream thread so thats no use to me). If I
set the threads to be native, SimplePlayerApplet will come up, get realized
and show the first frame or so of the video and thats it. If I seek the
player will seek and display that frame and maybe a couple of more frames.
Its the same thing with my application. However, sometimes the whole thing
woeks pretty smoothly. 
Does anyone have any idea whats going on ? 
Please help me... 
Thanks a lot. 
-- Gayathri 


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



[Linux-IrDA]Java-IrDA interface...

2000-02-03 Thread Jean Tourrilhes

Hi everybody...

I'm sorry to disturb the IrDA mailing list again, and hello to
the Java mailing list ;-)

As part of the project I'm working on, HP has produced a IrDA
interface for Java under Linux. It's basically some JNI code the glue
on the Linux-IrDA socket interface and offer a socket interface in
Java, allowing any Java application to communicate over IrDA.
So, for example, you could re-implement Obex in Java, or you
can use it with whatever Java networking application or package you
wishes (name your own).
We have been using this interface in the last month over
Linux-IrDA and it has been getting quite stable and usable so far
(fortunately for us ;-). We currently use JDK 117v3 from BackDown, but
it should work with any other JDKs (1.2, Sun, IBM) and should even be
portable to Windows.

So, why I'm talking about it ? We have the authorisation from
our bosses to release this code as GPL, and if enough people are
interested in it and willing to take over the development, we will
take the effort to release it. We might even encourage in getting it
in the standard Java distribution ;-)...
I just don't feel publishing it in its current state, because
more work need to be done to have a version that we can export and
people can use, mostly some cleanups and documentation, but also that
the current code use features which are not working or implemented in
the current IrDA stack.

So, if you are interested in this stuff, please contact me...

Jean

P.S. : Dag, the quality of the latest IrDA stack I tried was way up,
congratulation. Just a shame that I had to shout to make myself
understood :-(

___
Linux-IrDA mailing list  -  [EMAIL PROTECTED]
http://www4.pasta.cs.UiT.No/mailman/listinfo/linux-irda



TYA

2000-02-03 Thread jbaker

Hiya,

In reference to the TYA JIT, how does it slot in to the Blackdown Jdk1.2?
Has anyone done any benchmarks of the Blackdown JVM performance without a
JIT, with it's own JIT and with the TYA JIT?

J Baker

-- 
John Baker, BSc CS.   
Java developer and Linux lover:-)
Sms: [EMAIL PROTECTED]


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



RE: JNI & .so Files

2000-02-03 Thread Lee_Xing

Hi Nathan,

Thank you for your response.  Please let me re-address my question by using
the following pseudo code.  I embedded my question in so2.c pseudo code.

The following lines are app.java, so1.c and so2.c.  They are only pseudo
code.

==
//app.java
public class app
{
static
{
System.loadLibrary("so1");
}
native void so1Func();  

public static void main(String args[])
{
app myApp = new app();
myApp.so1Func();
}

javaFunc()
{
System.out.printfln("In Java, called back from so1.so");
}

}
==
//so1.c for libso1.so
JNIEnv gEnv;
jobject gObj; 

void Java_app_so1Func(JNIEnv * jEnv, jobject _this)
{
gEnv = jEnv;
gObj = _this;
...
library = dlopen("./libso2.so", RTLD_LAZY);
funcRef = dlsym(library, "so2Func");
(*funcRef)(); //call function so2Func() in libso2.so
...
}

void callBack()
{
jclass cls = (*gEnv)->GetObjectClass(gEnv, gObj);
jmethodID mid = (*gEnv)->GetMethodID(gEnv, cls, "javaFunc", "(V)V");
(*gEnv)->CallVoidMethod(gEnv, gObj, mid); //call back to java app.
}
==
//so2.c for libso2.so
so2Func()
{
while(1)
{
...
//
//how to call back to the function 
//callBack() in libso1.so from here?
//
...
}
}

app.java loads libso1.so into its address space, and libso1.so loads
libso2.so into the same address space.  So, libso2.so should be able to call
a function in libso1.so (in the same address space) if libso2.so can resolve
that function's symbol, but how?

Thanks.


Lee


-Original Message-
From: Nathan Meyers [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 02, 2000 10:44 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: JNI & .so Files


[EMAIL PROTECTED] wrote:
> 
> Hi,
> 
> I got a question on JNI.  It would be appreciated if someone could help.

Lee,

I'm having trouble understanding the problem you're posing. What is the
difficulty you're trying to solve... how to call functions in one .so
from another .so? You're already doing that.

Is it the problem of figuring out how to call a function whose name you
do not know until runtime? If so, I think you'll find the
dlopen()/dlsym()/dlclose() functions useful. Other than that
possibility, I'm not quite sure what problem you're trying to solve.

Nathan


> 
> Q:
> In order to hide java and jni related issues (e.g. jni function name
> convention, etc.) from .so programmers, a wrapper .so file so1.so is used
in
> between java app and another .so file so2.so (the one with native
functions
> we need).  This way, the java app interacts with the wrapper so1.so
> directly.  Every time when java app needs a native function service in
> so2.so, it first calls a native function in so1.so through jni.  so1.so,
in
> turn, calls the required function in so2.so.  Everything works fine in
this
> direction (i.e. java app->so1.so->so2.so.  java app loads so1.so, and
so1.so
> loads so2.so, then java app invokes a function in so2.so through a
function
> in so1.so).  The question is how a function in so2.so calls back to java
app
> through a function in so1.so?  In fact, we only need to know how functions
> in so2.so can call functions in so1.so because jni will let us call back
to
> java app from so1.so.
> 
> More information:
> - the java app is multithreaded application using Thread.start().
> - each java thread may call the same function in so1.so, then
>   this function, in turn, calls a function in so2.so
> - native code doesn't create any thread.
> 
> Use IPC? which one is easier on Linux?  Is there any other mechanism
> for this on Linux?
> 
> A simple sample code will help a lot.
> 
> Thank you.
> 
> Lee
> 
> --
> 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: JNI & .so Files

2000-02-03 Thread Nathan Meyers

On Thu, Feb 03, 2000 at 12:28:25PM -0600, [EMAIL PROTECTED] wrote:
> Hi Nathan,
> 
> Thank you for your response.  Please let me re-address my question by using
> the following pseudo code.  I embedded my question in so2.c pseudo code.

Thanks, that helps. You're simply trying to get a symbol address so you
can call it. You could use the same technique in so2 that you used in
so1: dlopen() to load the library and dlsym() to look up a symbol.

Yes, it appears that dlopen() is redundant, since the so1 library is
already loaded... but that's not a problem. Calling dlopen() on that
library will not load another copy, it will just increase a refcount
maintained by the system. More importantly, it'll return a handle you
can use in a dlsym() call.

Nathan


> 
> The following lines are app.java, so1.c and so2.c.  They are only pseudo
> code.
> 
> ==
> //app.java
> public class app
> {
>   static
>   {
>   System.loadLibrary("so1");
>   }
>   native void so1Func();  
> 
>   public static void main(String args[])
>   {
>   app myApp = new app();
>   myApp.so1Func();
>   }
> 
>   javaFunc()
>   {
>   System.out.printfln("In Java, called back from so1.so");
>   }
> 
> }
> ==
> //so1.c for libso1.so
> JNIEnv gEnv;
> jobject gObj; 
> 
> void Java_app_so1Func(JNIEnv * jEnv, jobject _this)
> {
>   gEnv = jEnv;
>   gObj = _this;
>   ...
>   library = dlopen("./libso2.so", RTLD_LAZY);
>   funcRef = dlsym(library, "so2Func");
>   (*funcRef)(); //call function so2Func() in libso2.so
>   ...
> }
> 
> void callBack()
> {
>   jclass cls = (*gEnv)->GetObjectClass(gEnv, gObj);
>   jmethodID mid = (*gEnv)->GetMethodID(gEnv, cls, "javaFunc", "(V)V");
>   (*gEnv)->CallVoidMethod(gEnv, gObj, mid); //call back to java app.
> }
> ==
> //so2.c for libso2.so
> so2Func()
> {
>   while(1)
>   {
>   ...
>   //
>   //how to call back to the function 
>   //callBack() in libso1.so from here?
>   //
>   ...
>   }
> }
> 
> app.java loads libso1.so into its address space, and libso1.so loads
> libso2.so into the same address space.  So, libso2.so should be able to call
> a function in libso1.so (in the same address space) if libso2.so can resolve
> that function's symbol, but how?
> 
> Thanks.
> 
> 
> Lee
> 
> 
> -Original Message-
> From: Nathan Meyers [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, February 02, 2000 10:44 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: JNI & .so Files
> 
> 
> [EMAIL PROTECTED] wrote:
> > 
> > Hi,
> > 
> > I got a question on JNI.  It would be appreciated if someone could help.
> 
> Lee,
> 
> I'm having trouble understanding the problem you're posing. What is the
> difficulty you're trying to solve... how to call functions in one .so
> from another .so? You're already doing that.
> 
> Is it the problem of figuring out how to call a function whose name you
> do not know until runtime? If so, I think you'll find the
> dlopen()/dlsym()/dlclose() functions useful. Other than that
> possibility, I'm not quite sure what problem you're trying to solve.
> 
> Nathan
> 
> 
> > 
> > Q:
> > In order to hide java and jni related issues (e.g. jni function name
> > convention, etc.) from .so programmers, a wrapper .so file so1.so is used
> in
> > between java app and another .so file so2.so (the one with native
> functions
> > we need).  This way, the java app interacts with the wrapper so1.so
> > directly.  Every time when java app needs a native function service in
> > so2.so, it first calls a native function in so1.so through jni.  so1.so,
> in
> > turn, calls the required function in so2.so.  Everything works fine in
> this
> > direction (i.e. java app->so1.so->so2.so.  java app loads so1.so, and
> so1.so
> > loads so2.so, then java app invokes a function in so2.so through a
> function
> > in so1.so).  The question is how a function in so2.so calls back to java
> app
> > through a function in so1.so?  In fact, we only need to know how functions
> > in so2.so can call functions in so1.so because jni will let us call back
> to
> > java app from so1.so.
> > 
> > More information:
> > - the java app is multithreaded application using Thread.start().
> > - each java thread may call the same function in so1.so, then
> >   this function, in turn, calls a function in so2.so
> > - native code doesn't create any thread.
> > 
> > Use IPC? which one is easier on Linux?  Is there any other mechanism
> > for this on Linux?
> > 
> > A simple sample code will help a lot.
> > 
> > Thank you.
> > 
> > Lee
> > 
> > --
> > To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> > with

Re: Java 1.2.2 px plug-in installation problem

2000-02-03 Thread Tom Williams

Thanks!

Peace.

Tom




Sascha Richter <[EMAIL PROTECTED]> on 02/03/2000 12:36:26 PM

To:   Tom Williams/HQ/dssi
cc:   [EMAIL PROTECTED]
Subject:  Re: Java 1.2.2 px plug-in installation problem




Tom Williams wrote:
>
> Hi!  I can't get the Java 1.2.2 plug-in installed on Linux 2.2.14 w/
> glibc-2.1.2 and bash 2-03 due to the following errors:
>
> : command not found.sh:
> : command not found.sh:
> : command not found.sh:
> ': not a valid identifierxport: `RESPONSE
> Do you agree to the above license terms?
> If you do not agree to the terms, installation cannot proceed
> 'avaPlugIn_1.2.2.px.sh: line 275: syntax error near unexpected token
`then
> 'avaPlugIn_1.2.2.px.sh: line 275: `if  (  test -w . ) then
>
> Can a gzip'd tarball be made available as an alternative to the
> self-extracting install script?
>
> The same happens with bash-1.1.4.
>
> I'm not a shell script expert but I will try to see what I can get
working
> for now.
>
> Thanks in advance for your time!
>
> Peace..
>
> Tom
Hi Tom,
I had the same problem, due to a recode of the JavaPlugin..sh in the
"dos"-format. You see it, if you open the file with vi and vi prompts
you something like "dos"-mode in the status bar.
Then I downloaded the plugin from an other site and had no problems.
Best regards
Sascha





--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: TYA

2000-02-03 Thread Joseph Shraibman

I did a while ago with tya 1.5 and was surprised to see sunwjit beat it.
But tya doesn't crash the vm in certain circumstances that sunwjit crashes.
I keep meaning to run the benchmarks again with all the updated versions of
everything but I've been busy.  I'll let everyone know when I get around to
it.

[EMAIL PROTECTED] wrote:

> Hiya,
>
> In reference to the TYA JIT, how does it slot in to the Blackdown Jdk1.2?
> Has anyone done any benchmarks of the Blackdown JVM performance without a
> JIT, with it's own JIT and with the TYA JIT?
>
> J Baker
>
> --
> John Baker, BSc CS.
> Java developer and Linux lover:-)
> Sms: [EMAIL PROTECTED]
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Many small objects -> crash

2000-02-03 Thread Ekkehard Kraemer

Hello,

the problem which was discussed a while ago on this list is still persistent
with RC4: any program that creates lots (say, 30) of small objects (like
java.math.BigInteger) will eventually segfault.

Just to make sure it doesn't drop off any TODO lists. ;-) Perhaps somebody
could verify that it is really a Linux bug (by trying a small test program on
the Win or Solaris JDK).

MbG, Ekkehard


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



RE: JNI & .so Files

2000-02-03 Thread Lee_Xing

Hi Nathan,

Thank you very much for your information.  I created three small real files
(app.java, so1_beep.c and so2_hello.c) and attach them below.  They can be
compiled into .class, .h, .o and .so files.  I'm using BlackDown 1.1.8 v1 on
RH6.1

It seems so2 can call back to so1, but when so1 calls back to java app, a
segment error happens.  I checked the code many times but still couldn't
figure out why.  I have a feeling that saving JNIEnv and jobject in so1 to
global vars may have problem but not sure.  Thank you and forgive me for
this long e-mail.

The error msg is long.  It looks like:

SIGSEGV   11*  segmentation violation
stackbase=B8C8, stackpointer=B248

Full thread dump:
...
...
app.main(app.java:8)
Monitor Cache Dump:
Registered Monitor Dump:
Thread queue lock: 
Name and type hash table lock: 
String intern lock: 
JNI pinning lock: 
JNI global reference lock: 
BinClass lock: 
Class loading lock: 
Java stack lock: 
Code rewrite lock: 
Heap lock: 
Has finalization queue lock: 
Finalize me queue lock: 
Waiting to be notified:
"Finalizer thread" (0x80af440)
Monitor registry: owner "main" (0x80a3b78, 1 entry)
Aborted


//app.java
public class app 
{
static public void main(String args[]) 
{
System.out.println("*** in main() ***");

toNative app = new toNative();
app.loadSo2("*** call load_so2() from java ***");
} 
}

class toNative
{
toNative()
{
System.loadLibrary("so1_beep");
}

native void loadSo2(String msg);

void callBack()
{
System.out.println("In Java, called back from so1");
}
}

//so1_beep.c
#include 
#include 
#include 
#include "toNative.h"

JNIEnv *gEnv;
jobject gObj;

void Java_toNative_loadSo2(JNIEnv * jEnv, jobject _this, jstring jMsg)
{
void *library;
void (*soHello)(void);
const char *error;


gEnv = jEnv;  //save them in global vars to let local function
gObj = _this; //backToJava() use them to call back to java app.

printf("*** so1: in loadSo2() before dlopen() ***\n");

library = dlopen("./libso2_hello.so", RTLD_LAZY);
if(library==NULL)
{
fprintf(stderr, "Could not open libso2_hello.so: %s\n",
dlerror());
exit(1);
}

dlerror();
soHello = (void *) dlsym(library, "print_hello");
error = dlerror();
if(error)
{
fprintf(stderr, "Could not find print_hello(): %s\n",
error);
exit(1);
}

(*soHello)();
}


void backToJava()
{
jclass cls = (*gEnv)->GetObjectClass(gEnv, gObj);
jmethodID mid = (*gEnv)->GetMethodID(gEnv, cls, "callBack", "(V)V");

printf("*** in backToJava() ***\n"); // I can see this msg after
run it
 //and before the
segmentation error.
(*gEnv)->CallVoidMethod(gEnv, gObj, mid);
}

//so2_hello.c
#include 
#include 
#include 

print_hello()
{
void (*backToSo1)(void);
void *library;
const char *error;

library = dlopen("./libso1_beep.so", RTLD_LAZY);
if(library==NULL)
{
fprintf(stderr, "Could not open libso1_beep.so in
libso2_hello.so:%s\n", dlerror());
exit(1);
}

dlerror();
backToSo1 = (void *) dlsym(library, "backToJava");
error = dlerror();
if(error)
{
fprintf(stderr, "Could not find backToJava(): %s\n", error);
exit(1);
}

while(1)
{
sleep(1);

(*backToSo1)();
}
}







-Original Message-
From: Nathan Meyers [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 03, 2000 1:27 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: JNI & .so Files


On Thu, Feb 03, 2000 at 12:28:25PM -0600, [EMAIL PROTECTED] wrote:
> Hi Nathan,
> 
> Thank you for your response.  Please let me re-address my question by
using
> the following pseudo code.  I embedded my question in so2.c pseudo code.

Thanks, that helps. You're simply trying to get a symbol address so you
can call it. You could use the same technique in so2 that you used in
so1: dlopen() to load the library and dlsym() to look up a symbol.

Yes, it appears that dlopen() is redundant, since the so1 library is
already loaded... but that's not a problem. Calling dlopen() on that
library will not load another copy, it will just increase a refcount
maintained by the system. More importantly, it'll return a handle you
can use in a dlsym() call.

Nathan


Re: Many small objects -> crash

2000-02-03 Thread Joseph Shraibman

Try using a differnt jit like tya.

Ekkehard Kraemer wrote:

> Hello,
>
> the problem which was discussed a while ago on this list is still persistent
> with RC4: any program that creates lots (say, 30) of small objects (like
> java.math.BigInteger) will eventually segfault.
>
> Just to make sure it doesn't drop off any TODO lists. ;-) Perhaps somebody
> could verify that it is really a Linux bug (by trying a small test program on
> the Win or Solaris JDK).
>
> MbG, Ekkehard
>
> --
> 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: JNI & .so Files

2000-02-03 Thread Ekkehard Kraemer

Hallo Lee,

LX>figure out why.  I have a feeling that saving JNIEnv and jobject in so1 
LX>to global vars may have problem but not sure.  Thank you and forgive me 
LX>for 

I am no expert on .so's, but "global variables" in conjunction with "dynamic
binding" should ring an alarm bell immediately in any case. ;-) Especially in
YOUR case, where you're loading the same library (so1) twice, once from the
Java side, and once from so2. I would be surprised if both would share the
same global variables (but as I said, I'm no .so expert).

Try to remove any global variables. This will force you to pass them around
more often (especially, into so2 and out of it again), but it may work better
afterwards. If you don't want to include the jni.h in so2, you could pass them
as void* (with explicit casts in so1) and/or create wrapper structs/classes
for them (so that you only need to pass one pointer instead of two).

MbG, Ekkehard


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: Many small objects -> crash

2000-02-03 Thread Ekkehard Kraemer

Hallo Joseph,

JS>Try using a differnt jit like tya.

This may avert the problem (I tried it and it goes away if sunwjit is switched
off), but it would be better to fix the bug, as long as tya is not the default
JIT.

But I guess that Blackdown isn't allowed to change sunwjit, even to remove
bugs. Sigh... those Sun lawyers really have weird ideas sometimes... ;-)

MbG, Ekkehard


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: VMs with processor specific code generation

2000-02-03 Thread noisebrain


I think I see indirect evidence of the IBM/intel/linux 118 jvm
using PII instructions - see the RESAMPLE benchmark at
   www.idiom.com/~zilla/Computer/javaCbenchmark.html

This is a synthetic benchmark available in java and C++ versions.
On a PII machine the java code runs faster than the C++ code
that is compiled with g++ -O!

I assume this must be due to the jvm using PII instructions while
the g++ -O assuming only pentium IS without additional flags.




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: JNI & .so Files

2000-02-03 Thread Nathan Meyers

On Fri, Feb 04, 2000 at 12:23:00AM +, Ekkehard Kraemer wrote:
> Hallo Lee,
> 
> LX>figure out why.  I have a feeling that saving JNIEnv and jobject in so1 
> LX>to global vars may have problem but not sure.  Thank you and forgive me 
> LX>for 
> 
> I am no expert on .so's, but "global variables" in conjunction with "dynamic
> binding" should ring an alarm bell immediately in any case. ;-) Especially in
> YOUR case, where you're loading the same library (so1) twice, once from the
> Java side, and once from so2. I would be surprised if both would share the
> same global variables (but as I said, I'm no .so expert).

I share this concern. Although the two loads didn't load the library
twice, I'm not convinced you don't have two separate instances of the
library's global data areas. You might try dumping the address of one
of those globals - once when you save into it, later when you use it -
to see if they agree.

I also wonder whether the data you're saving, the JNIEnv ptr and
jobject, are valid outside the call in which you obtained them. The JNI
spec must have something to say about that.

Nathan

> 
> Try to remove any global variables. This will force you to pass them around
> more often (especially, into so2 and out of it again), but it may work better
> afterwards. If you don't want to include the jni.h in so2, you could pass them
> as void* (with explicit casts in so1) and/or create wrapper structs/classes
> for them (so that you only need to pass one pointer instead of two).
> 
> MbG, Ekkehard
> 
> 
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

-- 
[EMAIL PROTECTED]  Public Access User -- Not affiliated with Teleport
Public Access UNIX and Internet at (503) 220-1016 (2400-28800, N81)


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: VMs with processor specific code generation

2000-02-03 Thread Wolfgang Hoschek

Thanks for the hints,

So, I found valuable material from IBM research
(http://www.research.ibm.com/journal/sj39-1.html)
In particular, http://www.research.ibm.com/journal/sj/391/suganuma.html
is very detailed, yet does not mention prefetch issues.

There it says that for IBMJDK1.1.7 Pentium and PentiumPro family
(Pentium Pro, Pentium II, and Pentium III) specific instructions are
generated. They say code scheduling in 1.1.7 is not yet available for
the PentiumPro family, but they promise for 1.1.8. So maybe, something
is already there.

SHUDO Kazuyuki wrote:
> Java Grande Forum (*1) Numerics Working Group (*2)
> (JGNWG) has been trying to allow JVM and JIT developers
> to use PowerPC's fmac (fused multiply and accumulate)
> instruction. In May 1998, They proposed an
> `associativefp' modifier, but the proposal is refused by
> Sun. But a `strictfp' modifier which is introduced into
> JDK 1.2 is an important result of the discussion.

fma is also an issue with Titanium, since it also uses fma's for fast
IEEE standard conforming floating point operations...

> JIT compiler may utilize even MMX instructions of
> x86. Of course, current JITs cannot utilize them
> efficiently, but I have a paper written by Intel
> researchers. The paper describes the method for JIT to
> exploit MMX instructions.

Could only find an announcement for two Intel tutorials at SC and
JavaGrande, but nothing written. Do you have something printable?

Regards,
Wolfgang.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



java, lesstif, Choice component bug

2000-02-03 Thread blake

Ok, this has been haunting me for a while now :

For some reason the keyboard focus gets screwed up after two selections of
a choice box in my java apps... I've found very little reference to this
bug anywhere.  I was told however that this is a problem with Motif, not
specificly the JVM (which would make sense, since IBM's JVM has the same
problem, but Netscape doesn't???).  So I was supposed to get the latest
copy of Lesstif. I've done that, installed like the directions said,
ldconfig...

So my question is : What the heck am I doing?

same problem still exists... It can't possibly be that this bug exists in
the most common system configurations or I there would be a fix, or atleast
some note about it somewhere?  How do I even figure out what the JVM(s) are
using? How do I tell/make them use something different?

I'm really absolutely clueless on this and would very much appreciate any help.


  Thanks,
   ~blake



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: JNI & .so Files

2000-02-03 Thread Weiqi Gao

[EMAIL PROTECTED] wrote:
> 
> jmethodID mid = (*gEnv)->GetMethodID(gEnv, cls, "callBack", "(V)V");

It's "()V" not "(V)V".  It worked on my machine after the change.

--
Weiqi Gao
[EMAIL PROTECTED]


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: JNI & .so Files

2000-02-03 Thread Jeff Galyan

Change RTLD_LAZY to RTLD_NOW and I think it will work. There was a bug
filed at Sun about something similar to this, and if I recall correctly,
the fix was to use RTLD_NOW.

--Jeff


[EMAIL PROTECTED] wrote:
> 
> Hi Nathan,
> 
> Thank you for your response.  Please let me re-address my question by using
> the following pseudo code.  I embedded my question in so2.c pseudo code.
> 
> The following lines are app.java, so1.c and so2.c.  They are only pseudo
> code.
> 
> ==
> //app.java
> public class app
> {
> static
> {
> System.loadLibrary("so1");
> }
> native void so1Func();
> 
> public static void main(String args[])
> {
> app myApp = new app();
> myApp.so1Func();
> }
> 
> javaFunc()
> {
> System.out.printfln("In Java, called back from so1.so");
> }
> 
> }
> ==
> //so1.c for libso1.so
> JNIEnv gEnv;
> jobject gObj;
> 
> void Java_app_so1Func(JNIEnv * jEnv, jobject _this)
> {
> gEnv = jEnv;
> gObj = _this;
> ...
> library = dlopen("./libso2.so", RTLD_LAZY);
> funcRef = dlsym(library, "so2Func");
> (*funcRef)(); //call function so2Func() in libso2.so
> ...
> }
> 
> void callBack()
> {
> jclass cls = (*gEnv)->GetObjectClass(gEnv, gObj);
> jmethodID mid = (*gEnv)->GetMethodID(gEnv, cls, "javaFunc", "(V)V");
> (*gEnv)->CallVoidMethod(gEnv, gObj, mid); //call back to java app.
> }
> ==
> //so2.c for libso2.so
> so2Func()
> {
> while(1)
> {
> ...
> //
> //how to call back to the function
> //callBack() in libso1.so from here?
> //
> ...
> }
> }
> 
> app.java loads libso1.so into its address space, and libso1.so loads
> libso2.so into the same address space.  So, libso2.so should be able to call
> a function in libso1.so (in the same address space) if libso2.so can resolve
> that function's symbol, but how?
> 
> Thanks.
> 
> Lee
> 
> -Original Message-
> From: Nathan Meyers [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, February 02, 2000 10:44 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: JNI & .so Files
> 
> [EMAIL PROTECTED] wrote:
> >
> > Hi,
> >
> > I got a question on JNI.  It would be appreciated if someone could help.
> 
> Lee,
> 
> I'm having trouble understanding the problem you're posing. What is the
> difficulty you're trying to solve... how to call functions in one .so
> from another .so? You're already doing that.
> 
> Is it the problem of figuring out how to call a function whose name you
> do not know until runtime? If so, I think you'll find the
> dlopen()/dlsym()/dlclose() functions useful. Other than that
> possibility, I'm not quite sure what problem you're trying to solve.
> 
> Nathan
> 
> >
> > Q:
> > In order to hide java and jni related issues (e.g. jni function name
> > convention, etc.) from .so programmers, a wrapper .so file so1.so is used
> in
> > between java app and another .so file so2.so (the one with native
> functions
> > we need).  This way, the java app interacts with the wrapper so1.so
> > directly.  Every time when java app needs a native function service in
> > so2.so, it first calls a native function in so1.so through jni.  so1.so,
> in
> > turn, calls the required function in so2.so.  Everything works fine in
> this
> > direction (i.e. java app->so1.so->so2.so.  java app loads so1.so, and
> so1.so
> > loads so2.so, then java app invokes a function in so2.so through a
> function
> > in so1.so).  The question is how a function in so2.so calls back to java
> app
> > through a function in so1.so?  In fact, we only need to know how functions
> > in so2.so can call functions in so1.so because jni will let us call back
> to
> > java app from so1.so.
> >
> > More information:
> > - the java app is multithreaded application using Thread.start().
> > - each java thread may call the same function in so1.so, then
> >   this function, in turn, calls a function in so2.so
> > - native code doesn't create any thread.
> >
> > Use IPC? which one is easier on Linux?  Is there any other mechanism
> > for this on Linux?
> >
> > A simple sample code will help a lot.
> >
> > Thank you.
> >
> > Lee
> >
> > --
> > To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

-- 
Jeff Galyan
http://www.anamorphic.com
http://www.sun.com
jeffrey dot galyan at sun dot com
talisman at anamorphic dot com
Sun Certified Java(TM) Programmer
==
Linus Torvalds on Microsoft and software dev

Crashes in Java

2000-02-03 Thread Richard R Malloy

I've been getting crashed in forte4j, and InstallShield for java and
with ElixirIDE which all
have dumps that look like the follow:

(I've  been real busy lately so I haven't been follow the groups
closely, so .. )

Anybody have a clue. Forte used to work and I can for the life of me
remember
any system changes.

Rich.

Thanks 



SIGSEGV   11*  segmentation violation
 stackpointer=0x41811128

Full thread dump Classic VM (Linux_JDK_1.2_pre-release-v2, green
threads):
"Screen Updater" (TID:0x40517048, sys_thread_t:0x87d5ed8, state:R)
prio=4
 at java.lang.Thread.setPriority0(Native Method)
 at java.lang.Thread.setPriority(Compiled Code)
 at sun.awt.ScreenUpdater.run(Compiled Code)
"Image Fetcher 2" (TID:0x4050a6b0, sys_thread_t:0x86cd2b8, state:CW)
prio=8
 at java.lang.Object.wait(Native Method)
 at sun.awt.image.ImageFetcher.nextImage(Compiled Code)
 at sun.awt.image.ImageFetcher.fetchloop(Compiled Code)
 at sun.awt.image.ImageFetcher.run(Compiled Code)
"Image Fetcher 1" (TID:0x4050c380, sys_thread_t:0x870a028, state:CW)
prio=8
 at java.lang.Object.wait(Native Method)
 at sun.awt.image.ImageFetcher.nextImage(Compiled Code)
 at sun.awt.image.ImageFetcher.fetchloop(Compiled Code)
 at sun.awt.image.ImageFetcher.run(Compiled Code)
"Image Fetcher 0" (TID:0x4050f6e0, sys_thread_t:0x8742580, state:CW)
prio=8
 at java.lang.Object.wait(Native Method)
 at sun.awt.image.ImageFetcher.nextImage(Compiled Code)
 at sun.awt.image.ImageFetcher.fetchloop(Compiled Code)
 at sun.awt.image.ImageFetcher.run(Compiled Code)
"Image Fetcher 3" (TID:0x404fc7f8, sys_thread_t:0x85e0f58, state:CW)
prio=8
 at java.lang.Object.wait(Native Method)
 at sun.awt.image.ImageFetcher.nextImage(Compiled Code)
 at sun.awt.image.ImageFetcher.fetchloop(Compiled Code)
 at sun.awt.image.ImageFetcher.run(Compiled Code)
"AWT-Motif" (TID:0x4050c7d8, sys_thread_t:0x8488a30, state:R) prio=5

 at sun.awt.motif.MToolkit.run(Native Method)
 at java.lang.Thread.run(Compiled Code)
"SunToolkit.PostEventQueue-0" (TID:0x4050eed8,
sys_thread_t:0x8463c58, state:R) prio=5
 at java.awt.EventQueue.postEvent(Compiled Code)
 at sun.awt.PostEventQueue.run(Compiled Code)
"AWT-EventQueue-0" (TID:0x4050eea8, sys_thread_t:0x84c3548, state:R)
prio=6
 at sun.java2d.loops.DefaultComponent.IntIsomorphicCopy(Native Method)
 at sun.java2d.loops.IntRgbToIntRgb.OpaqueBlit(Compiled Code)
 at sun.java2d.loops.RasterOutputManager.performOpaqueBlit(Compiled
Code)
 at sun.java2d.loops.RasterOutputManager.compositeSrcDst(Compiled Code)
 at sun.java2d.loops.RasterOutputManager.renderImage(Compiled Code)
 at sun.java2d.SunGraphics2D.renderingPipeImage(Compiled Code)
 at sun.java2d.SunGraphics2D.drawImage(Compiled Code)
 at sun.awt.motif.X11Graphics.drawImage(Compiled Code)
 at javax.swing.JComponent.paint(Compiled Code)
 at java.awt.Container.paint(Compiled Code)
 at sun.awt.motif.MComponentPeer.handleEvent(Compiled Code)
 at java.awt.Component.dispatchEventImpl(Compiled Code)
 at java.awt.Container.dispatchEventImpl(Compiled Code)
 at java.awt.Window.dispatchEventImpl(Compiled Code)
 at java.awt.Component.dispatchEvent(Compiled Code)
 at java.awt.EventQueue.dispatchEvent(Compiled Code)
 at java.awt.EventDispatchThread.run(Compiled Code)
"Finalizer" (TID:0x404f6320, sys_thread_t:0x81061d8, state:CW)
prio=8
 at java.lang.Object.wait(Native Method)
 at java.lang.ref.ReferenceQueue.remove(Compiled Code)
 at java.lang.ref.ReferenceQueue.remove(Compiled Code)
 at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:174)
"Reference Handler" (TID:0x404f63b0, sys_thread_t:0x8101848,
state:CW) prio=10
 at java.lang.Object.wait(Native Method)
 at java.lang.Object.wait(Compiled Code)
 at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:114)
"Signal dispatcher" (TID:0x404f63e0, sys_thread_t:0x80fdfb8,
state:CW) prio=5
"main" (TID:0x404f61e0, sys_thread_t:0x804c360, state:R) prio=5
 at
javax.swing.plaf.basic.BasicTabbedPaneUI.installKeyboardActions(Compiled
Code)
 at javax.swing.plaf.basic.BasicTabbedPaneUI.installUI(Compiled Code)
 at javax.swing.JComponent.setUI(Compiled Code)
 at javax.swing.JTabbedPane.setUI(Compiled Code)
 at javax.swing.JTabbedPane.updateUI(Compiled Code)
 at javax.swing.JTabbedPane.(Compiled Code)
 at com.elixirtech.fx.PanelSite.(Compiled Code)
 at com.elixirtech.fx.FrameManager.x577(Compiled Code)
 at com.elixirtech.fx.FrameManager.createFrame(Compiled Code)
 at com.elixirtech.ide.IDEFrame.(Compiled Code)
 at com.elixirtech.ide.IDEFrame.main(Compiled Code)
 at com.elixirtech.IDE.main(Compiled Code)
Monitor Cache Dump:
java.lang.Class@4050E958/405975F0: owner "AWT-EventQueue-0"
(0x84c3548) 1 entry
 (0x4051a021): owner "main" (0x804c360) 1 entry
java.lang.ref.Reference$Lock@404F63C0/4052B890: 
 Waiting to be notified:
 "Reference Handler" (0x8101848)
java.util.Vector@404FC7B0/405BD7F0: 
 Waiting to be notified:
 "Image Fetcher 3" (0x85e0f58)
 "Image Fetcher 0" (0x8742580)
 "Image F