Re: problem with Installation

1999-03-01 Thread Ted Garrett

The problem you are running into has to do with the fact that your system
is not being told where to find the dynamic libraries.  Try adding
/usr/local/jdk117_v1a/lib/i586/green_threads to the file /etc/ld.so.conf
and doing an ldconfig.  After that, your problem should go away.

An alternative is to add that directory to your LD_LIBRARY_PATH
environment variable.

On Sun, 28 Feb 1999 [EMAIL PROTECTED] wrote:

> hi, I got problems when using java interpreter, appletviewer, etc.. the system
> shows the error messages are : $ java -version
> /usr/local/jdk117_v1a/bin/../bin/i586/green_threads/java: error in loading shared
> libraries libjava.so: cannot open shared object file: No such file or directory I
> installed jdk117_v1a completly followed the REAME file, I don't know why I got this
> error? please help me out, thanks a lot ! Cheers, Charles

---
"I don't have to take this abuse from you -- I've got hundreds of
people waiting to abuse me." -- Bill Murray, "Ghostbusters"
---
Ted GarrettPGP Key ID: 0A04AE45
Network Systems Analyst for hire   [EMAIL PROTECTED]


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



classes

1999-03-01 Thread mike dobbs

I'm learning java, and I cannot get a hsa.Console class to work on
linux?  Where can I get this?
Thank alot



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



Re: Green Threads

1999-03-01 Thread Nathan Meyers

Lee Chee Wai wrote:
> I have read the README file associated with the 1.1.7b port on
> the native thread support package and am a little confused by the
> description of native and "green" threads.
> 
> I'd first like to ask about "green" threads. What exactly are
> they and where can I get more information about them?

Sounds like you know what threads (lightweight processes) are, so I
won't bore you (or the list readership) with any definitions.

When implementing threads -- no matter how you are implementing them --
the goal is to have multiple flows of execution going in the same
address space. The question is who performs the switching between the
threads. The answer is either:

1) The kernel controls it, or

2) It's controlled in user space.

Native threads use answer #1, while green threads are the (nearly)
OS-independent Sun version of answer #2. They have the advantage of
working, with some porting effort, on OSes that don't support threads
well in the kernel and/or in system libraries.

> The second question is about the description of native
> threads. From the README file, it sounds as if native threads are in
> fact UNIX processes instead of pthread lightweight threads (which from
> my understanding are user-level threads that can still be handled by
> the OS in an SMP environment).

This is the part of your question that's Linux-specific (which exempts
you from the customary "this isn't a Linux question" rebuke :-). The
Linux OS supports kernel threads. They are threads in the true sense of
the word: multiple paths of execution operating in a shared address
space, including preemptive thread-switching performed by the kernel.

It so happens that the Linux implementation of threads causes each
thread to take up space in the process table. There are some potentially
unpleasant implications (a fairly low limit on thread count) but they
are otherwise no different from anyone else's notion of threads.


Now about pthreads: that's an API for C programmers, not a threading
mechanism. A multithreaded application might choose to use this API
because it's portable. There's nothing about the pthread API that
commits you to a particular underlying thread implementation -- it might
be a user-space or kernel-space implementation, it might or might not do
preemption, it might or might not clutter up the process table.


> Could you please help clarify my doubts on the above? The JVM
> I've used for Solaris does not seem to exhibit non-deterministic
> behaviour as is expected of simultaneously executing threads even on
> an SMP machine with 4 processors.

The surprises you're hoping for are more likely to happen with a
threading mechanism that does preemption. In general, you're more likely
to see them with a native thread implementation than a green thread
implementation.


Nathan Meyers
[EMAIL PROTECTED]


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



Multicast sockets

1999-03-01 Thread Topi Maenpaa

I have been observing your java port effort for a long time, and I'm
happy noticing that it seems pretty much ready now...

You may already know this, but it might help you to know that the
multicast socket bug in Linux kernel is corrected in 2.2.1 (may be in
2.2.0 also).

Good luck
-Topi-
 << http://ee.oulu.fi/~topiolli >>



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



Multicast sockets

1999-03-01 Thread Steve Byrne

Topi Maenpaa writes:
 > I have been observing your java port effort for a long time, and I'm
 > happy noticing that it seems pretty much ready now...
 > 
 > You may already know this, but it might help you to know that the
 > multicast socket bug in Linux kernel is corrected in 2.2.1 (may be in
 > 2.2.0 also).

Thanks!  I read the kernel code in 2.0.36, and it explained why I was getting
back an IP address that, if interpreted as characters, spelled out 
"eth0", instead of an actual multicast device address.  I also looked at the
2.2.0 kernel sources, and found out, as you have mentioned that the multicast
socket address problems are fixed there. 

So it's up to Sun to say whether this constitutes passing behavior on a kernel
without proper support for this kind of functionality or not.  Let's cross our
fingers :-)

Steve


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



Re: has anyone got the native threads jdk1.1.7a1 running?

1999-03-01 Thread Markus Enzenberger


Hi,

I have a similar problem here. I use the Invocation API with native
threads, definitely call JNI_CreateJavaVM with a correct classpath, but
JNI_CreateJavaVM hangs for about 30 sec, before it stops with:

  Can't find class java.lang.System

Difficult to say more, it happens only with my large program, simple
example programs (like invoce.c from tha Java tutorial) work :-(

If someone can interpret it, I could send him a complete output from
strace, but the main output while JNI_CreateJavaVM hangs is (many times
repeated): 


  open("/proc/937/stat", O_RDONLY)= 8
  fstat(8, {st_mode=0, st_size=0, ...})   = 0
  mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
  0x4000d000
  read(8, "937 (example) T 936 934 832 769 "..., 1024) = 190
  read(8, "", 1024)   = 0
  close(8)= 0
  munmap(0x4000d000, 4096)= 0
  open("/proc/935/stat", O_RDONLY)= 8
  fstat(8, {st_mode=0, st_size=0, ...})   = 0
  mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
  0x4000d000
  read(8, "935 (example) R 934 934 832 769 "..., 1024) = 198
  read(8, "", 1024)   = 0
  close(8)= 0
  munmap(0x4000d000, 4096)= 0
  gettimeofday({920232779, 618017}, NULL) = 0
  gettimeofday({920232779, 657611}, NULL) = 0
  gettimeofday({920232779, 668469}, NULL) = 0
  gettimeofday({920232779, 684209}, NULL) = 0
  gettimeofday({920232779, 684496}, NULL) = 0
  gettimeofday({920232779, 684742}, NULL) = 0
  kill(937, SIGCONT)  = 0
  kill(937, SIGSTOP)  = 0


"example" is the name of my large program.

See you

- Markus



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



Re: has anyone got the native threads jdk1.1.7a1 running?

1999-03-01 Thread Juergen Kreileder

> Markus Enzenberger writes:

Markus> Hi,

Markus> I have a similar problem here. I use the Invocation API
Markus> with native threads, definitely call JNI_CreateJavaVM with
Markus> a correct classpath, but JNI_CreateJavaVM hangs for about
Markus> 30 sec, before it stops with:

Markus>   Can't find class java.lang.System

Invocation with native threads works with 1.2. Maybe I'll try
to get it working with 1.1.8 after our first 1.2 release.


Juergen

-- 
Juergen Kreileder, Universitaet Dortmund, Lehrstuhl Informatik V
Baroper Strasse 301, D-44221 Dortmund, Germany
Phone: ++49 231/755-5806, Fax: ++49 231/755-5802


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



Re: Green Threads

1999-03-01 Thread Cees de Groot

Nathan Meyers wrote:

> 1) The kernel controls it, or
>
> 2) It's controlled in user space.
>
> Native threads use answer #1, while green threads are the (nearly)
> OS-independent Sun version of answer #2. They have the advantage of
> working, with some porting effort, on OSes that don't support threads
> well in the kernel and/or in system libraries.

IMHO, Native threads use #1 or #2, whatever the OS at hand finds fit to offer,
and green threads are an implementation of #2. That's basically all you can say
- native threads don't necessarily pre-empt, and it is unwise to make
assumptions anyway.

For development, use green threads (cooperative multithreading tends to expose
MT programming errors, like forgetting to yield(), very quickly). For
deployment, see what's best. Native threads may use SMP capabilities better,
and native threads when they're preemptive will probably be better at
controlling CPU-bound threads. For the average Java app/service, where most
work is I/O bound (GUI, network), green threads should be a tad faster because
they are adapted at what Java's needs and its cooperative thread switching is
typically faster (setjmp()/longjmp() call) then preemptive switching (which
will probably invoke a syscall).

Whatever the JVM, you *have* to assume that on the Java level, you'll need to
explicitely implement threads to deal with a cooperative scheduling setup. You
can assume that in a loop, any I/O call will yield (so you don't need to do
stuff in a server accept() loop, for example), but otherwise think about what
your code is doing and try to make it sleep() or yield() as often as is
reasonable.




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



Is KOI8 bug still present in JDK 1.2?

1999-03-01 Thread Aleksey V. Lukin

Hello, JDK porting team!
First of all let me say THANK YOU for all you doing for Linux users.

Just one question: Is KOI8 bug still present in JDK 1.2?
I mean that Cyrillic KOI8 chars do not get encoded into unicode in all
JDKs excluding FreeBSD port.
It caused incorrect behavior of JAVA applications and applets in Linux -
just complete abracadabra.
This is SUN's bug, but it would be nice to correct it in Linux port.
With such little bug JDK is allmost useless for Russian and Ukrainaian
users.

-- 
With respect,
Alexey Lukin,
JSC "CINET" http://www.ci.net.ua
phone/fax +380-462-101710, 101263


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



SwingApps (fwd)

1999-03-01 Thread Kathleen McLean



-- Forwarded message --

I'm trying to run a program that's using swing apps(on JDK 1.2 beta).  The
program comiles ok but when I try to run it I get the following:


SIGSEGV   11*  segmentation violation
si_signo [11]: SIGSEGV   11*  segmentation violation
si_errno [0]: Error 0
si_code [1]: SEGV_MAPERR [addr: 0xeaa4fff8]

stackpointer=EAC9F838

Full thread dump:
"Screen Updater" (TID:0xebcab100, sys_thread_t:0x4e2b90, state:MW)
prio=6
at sun.awt.motif.MComponentPeer.pTriggerRepaint(Native Method)
at sun.awt.motif.MComponentPeer.updateClient(Compiled Code)
at sun.awt.ScreenUpdater.run(Compiled Code)
"AWT-Finalizer" (TID:0xebcb8988, sys_thread_t:0x4d86b8, state:CW)
prio=9
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Compiled Code)
at sun.awt.AWTFinalizer.run(Compiled Code)
"TimerQueue" (TID:0xebcb0048, sys_thread_t:0x411050, state:CW) prio=5
at java.lang.Object.wait(Native Method)
at com.sun.java.swing.TimerQueue.run(Compiled Code)
at java.lang.Thread.run(Compiled Code)
"AWT-Motif" (TID:0xebcb9290, sys_thread_t:0x268008, state:MW) prio=5
at sun.awt.motif.MToolkit.run(Native Method)
at java.lang.Thread.run(Compiled Code)
"AWT-Input" (TID:0xebcb9520, sys_thread_t:0x2659d8, state:CW) prio=5
at java.lang.Object.wait(Native Method)
at sun.awt.motif.InputThread.run(Native Method)
"AWT-EventQueue-0" (TID:0xebcb9360, sys_thread_t:0x24c158, state:R)
prio=6 *
current thread*
at sun.awt.motif.X11Graphics.X11LockViewResources(Native Method)
at sun.awt.motif.X11Graphics.lock(Compiled Code)
at sun.java2d.loops.LockableRaster.lock2D(Compiled Code)
at sun.java2d.loops.LockableRaster.(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 com.sun.java.swing.SwingGraphics2D.drawImage(Compiled Code)
at com.sun.java.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:0xebc993a0, sys_thread_t:0x64d08, 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:128)
"Reference Handler" (TID:0xebc99430, sys_thread_t:0x36ad0, 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:209)
"Signal dispatcher" (TID:0xebc992e8, sys_thread_t:0x36e38, state:CW)
prio=10
"Thread-0" (TID:0xebcb1158, sys_thread_t:0x293d8, state:CW) prio=5
Monitor Cache Dump:
sun.awt.motif.MToolkit@EBCB91B8/EBD33A90: owner "AWT-EventQueue-0"
(0x24c158
, 1 entry)
Waiting to enter:
"Screen Updater" (0x4e2b90)
"AWT-Motif" (0x268008)
Waiting to be notified:
"AWT-Input" (0x2659d8)
Registered Monitor Dump:
PCMap lock: 
utf8 hash table: 
JNI pinning lock: 
JNI global reference lock: 
BinClass lock: 
Class linking lock: 
System class loader lock: 
Code rewrite lock: 
Heap lock: 
Dynamic loading lock: 
Monitor IO lock: 
User signal monitor: 
Waiting to be notified:
"Signal dispatcher" (0x36e38)
Child death monitor: 
I/O monitor: 
Alarm monitor: 
Waiting to be notified:
Internal clock thread (ef7a0c38)
Thread queue lock: 
Waiting to be notified:
"Thread-0" (0x293d8)
Monitor registry: owner "AWT-EventQueue-0" (0x24c158, 1 entry)
Segmentation Fault

Any help on what the problem is would be much appreciated,

cheers...


kathy


--
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: problem with Installation

1999-03-01 Thread Michael Sinz

On Mon, 1 Mar 1999 00:50:45 -0500 (EST), Ted Garrett wrote:

>The problem you are running into has to do with the fact that your system
>is not being told where to find the dynamic libraries.  Try adding
>/usr/local/jdk117_v1a/lib/i586/green_threads to the file /etc/ld.so.conf
>and doing an ldconfig.  After that, your problem should go away.
>
>An alternative is to add that directory to your LD_LIBRARY_PATH
>environment variable.

One should not add these things to LD_LIBRARY_PATH directly.  The
.java_wrapper does this as part of running the various JDK commands.

Now, if this is happening you most likely have a problem with the
wrong version of the JDK installed.  (glibc version on libc5 system?)

Again, please do not try to add the directory to /etc/ld.so.conf
or to add it directly to LD_LIBRARY_PATH.  That is what the .java_wrapper
does and when the next release is installed you would need to remember
to clean up any cruft otherwise other confusion will occure.


Michael Sinz -- Director of Research & Development, NextBus Inc.
mailto:[EMAIL PROTECTED] - http://www.nextbus.com
My place on the web ---> http://www.users.fast.net/~michael_sinz



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



Re[2]: problem with Installation

1999-03-01 Thread Pierre MIGUEL

PLEASE STOP TO SEND ME MESSAGE SOMEONE PUT MY EMAIL IN COPY

__ Reply Separator _



[EMAIL PROTECTED]
01/03/99 12:39:00


 To: [EMAIL PROTECTED]@internet
[EMAIL PROTECTED]@internet
 cc: [EMAIL PROTECTED]@internet (bcc: Pierre MIGUEL/marc-otc/fr/socgen)
Return Receipt: No
Importance: Normal


SUBJECT: Re: problem with Installation


On Mon, 1 Mar 1999 00:50:45 -0500 (EST), Ted Garrett wrote:

>The problem you are running into has to do with the fact that your system
>is not being told where to find the dynamic libraries.  Try adding
>/usr/local/jdk117_v1a/lib/i586/green_threads to the file /etc/ld.so.conf
>and doing an ldconfig.  After that, your problem should go away.
>
>An alternative is to add that directory to your LD_LIBRARY_PATH
>environment variable.

One should not add these things to LD_LIBRARY_PATH directly.  The
.java_wrapper does this as part of running the various JDK commands.

Now, if this is happening you most likely have a problem with the
wrong version of the JDK installed.  (glibc version on libc5 system?)

Again, please do not try to add the directory to /etc/ld.so.conf
or to add it directly to LD_LIBRARY_PATH.  That is what the .java_wrapper
does and when the next release is installed you would need to remember
to clean up any cruft otherwise other confusion will occure.


Michael Sinz -- Director of Research & Development, NextBus Inc.
mailto:[EMAIL PROTECTED] - http://www.nextbus.com
My place on the web ---> http://www.users.fast.net/~michael_sinz



--
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: SwingApps (fwd)

1999-03-01 Thread Christopher Rowan

Blackdown Java is still at 1.1.7 (not 1.2 yet).  This means you are
talking about a different implementation of Java.

This list if for Blackdown Java related questions only.  It is not a
general Java list.

Unless you have a secret copy of Blackdown Java or you have posted your
version number wrong, you have posted your query in the wrong place.

Please try another list.

I hope the other list members are as gentle with you as I have been (be
nice folks!).

Kathleen McLean wrote:
> 
> -- Forwarded message --
> 
> I'm trying to run a program that's using swing apps(on JDK 1.2 beta).  The
> program comiles ok but when I try to run it I get the following:

[snip]


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



HTTPS

1999-03-01 Thread Zoltan . Tar

Hello

I want to make an https connection but I get this error:

java.lang.ClassNotFoundException: javax.net.ssl.SSLException: Received
fatal alert: handshake_failure (no cipher suites in common)


at
sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1072)


at sun.security.ssl.SSLSocketImpl.clearPipeline(Compiled Code)


at sun.security.ssl.SSLSocketImpl.write(Compiled Code)


at sun.security.ssl.AppOutputStream.write(Compiled Code)


at java.io.OutputStream.write(OutputStream.java:65)


at
sun.plugin.protocol.jdk12.https.HttpsClient.doConnect(HttpsClient.java:3
21)


at sun.net.www.http.HttpClient.openServer(HttpClient.java:320)


at sun.net.www.http.HttpClient.openServer(HttpClient.java:388)


at sun.net.www.http.HttpClient.(HttpClient.java:260)


at sun.net.www.http.HttpClient.(HttpClient.java:265)


at
sun.plugin.protocol.jdk12.https.HttpsClient.(HttpsClient.java:211)



at
sun.plugin.protocol.jdk12.https.HttpsClient.New(HttpsClient.java:225)


at
sun.plugin.protocol.jdk12.https.HttpsURLConnection.privBlock(HttpsURLCon
nection.java:97)


at
sun.plugin.protocol.jdk12.https.HttpsURLConnection$PrivilegedBlockAction
.run(HttpsURLConnection.java:169)


at java.security.AccessController.doPrivileged(Native Method)


at
sun.plugin.protocol.jdk12.https.HttpsURLConnection.connect(HttpsURLConne
ction.java:136)


at
sun.plugin.protocol.jdk12.http.HttpURLConnection.getInputStream(HttpURLC
onnection.java:191)


at sun.applet.AppletClassLoader.getBytes(Compiled Code)


at
sun.applet.AppletClassLoader.access$1(AppletClassLoader.java:216)


at
sun.applet.AppletClassLoader$1.run(AppletClassLoader.java:139)


at java.security.AccessController.doPrivileged(Native Method)


at
sun.applet.AppletClassLoader.findClass(AppletClassLoader.java:136)


at java.lang.ClassLoader.loadClass(ClassLoader.java:280)


at
sun.applet.AppletClassLoader.loadClass(AppletClassLoader.java:110)


at java.lang.ClassLoader.loadClass(ClassLoader.java:237)


at
sun.applet.AppletClassLoader.loadCode(AppletClassLoader.java:368)


at sun.applet.AppletPanel.createApplet(AppletPanel.java:532)


at sun.plugin.AppletViewer.createApplet(AppletViewer.java:759)


at sun.applet.AppletPanel.runLoader(AppletPanel.java:468)


at sun.applet.AppletPanel.run(Compiled Code)


at java.lang.Thread.run(Thread.java:479)

I am using a Java2 plugin and trying to download a html page that
contain an applet.
On server side there is a Netscape Enterprise Server 3.5 and a Netscape
Certificate Server.

Can anybody help me?

Zoltan Tar
[EMAIL PROTECTED]


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



Re: Hatred of 1.2 messages

1999-03-01 Thread Paolo Ciccone

> "GG" == Gerald Gutierrez <[EMAIL PROTECTED]> writes:

GG> Unfortunately those, such as yourself, who understand and care
GG> about what's involved only constitute the minority .. the
GG> "java-elite". I know many programming gurus at Motorola where
GG> I work that can't care less what JCK tests java-linux has
GG> passed. They simply a) expect it to work when its released and
GG> b) want to know when it'll be released. I find the same
GG> attitude amongst all those whom I know that care about
GG> java-linux.

Still, seeing a change of status in the chart is an indication of
things improving and I believe that everybody prefer to see that
things are moving instead of waiting for the end result.


-- 
Paolo


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



Way to go!

1999-03-01 Thread Dustin Lang


Hi,

Sorry for adding to the noise, but there seems to be a lot of green on the
JDK1.2 status page!!  Way to go!!

dstn.

---
--  Dustin Lang, [EMAIL PROTECTED]  --
(java developer, linux guy, green-haired freak)
---


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



[Fwd: ANNOUNCE: ejboss, an ejb application server for linux]

1999-03-01 Thread blaise toad


huh... this really BELONGS here.

regards
blaise



---ejboss <[EMAIL PROTECTED]> wrote:
>
> 
> 
> ATTACHMENT part 2 message/rfc822 
>
> We announce the availability of EJBOSS, an enterprise java beans (EJB)
> compliant server for Linux.
> 
> You can find the source code and executables at www.ejboss.org
> ejboss stands for "enterprise java beans in OSS".  It is a GPL'd EJB
> server that complies with SUN's EJB1.0 specification.  It was
developed
> for Linux (aka Linux based GNU system) but also runs on Solaris 2.6.
 It
> is 100% pure java.
> 
> WHO CARES?: System and network administrator of IT shops.  ISP's
looking
> to host applications on linux.  Developers of distributed
applications.
> System integrators.
> 
> ADVANTAGES: Centralized and declarative management of beans and
> deployment. Puts System administrators in command.  Powerful
> comprehensive GUI. Eases the "run-time" burden of development on
> programmers. Industry standard.  GPL'd.
> 
> STATUS: This is version 0.04, an early access targeted at developers
and
> sys-admins.  Session beans stateful and stateless are stable.   The
> "optional" support for entity beans will be coded next.
> 
> LICENSE: GPL and ALL (see www.ejboss.org for terms of ALL)
> 
> The ejboss organization.
> 
> 
> 

_
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com


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



Re: has anyone got the native threads jdk1.1.7a1 running?

1999-03-01 Thread Moses DeJong

I was having this problem but one of the nice folks from the blackdown
porting team told me how to fix it. The fix was to add the libjava.so
file to the process space with this command.

setenv LD_PRELOAD libjava.so

After doing that it worked perfectly.

Mo DeJong
[EMAIL PROTECTED]
gimme multimedia group

On Mon, 1 Mar 1999, Markus Enzenberger wrote:

> 
> Hi,
> 
> I have a similar problem here. I use the Invocation API with native
> threads, definitely call JNI_CreateJavaVM with a correct classpath, but
> JNI_CreateJavaVM hangs for about 30 sec, before it stops with:
> 
>   Can't find class java.lang.System
> 
> Difficult to say more, it happens only with my large program, simple
> example programs (like invoce.c from tha Java tutorial) work :-(
> 
> If someone can interpret it, I could send him a complete output from
> strace, but the main output while JNI_CreateJavaVM hangs is (many times
> repeated): 
> 
> 
>   open("/proc/937/stat", O_RDONLY)= 8
>   fstat(8, {st_mode=0, st_size=0, ...})   = 0
>   mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
>   0x4000d000
>   read(8, "937 (example) T 936 934 832 769 "..., 1024) = 190
>   read(8, "", 1024)   = 0
>   close(8)= 0
>   munmap(0x4000d000, 4096)= 0
>   open("/proc/935/stat", O_RDONLY)= 8
>   fstat(8, {st_mode=0, st_size=0, ...})   = 0
>   mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
>   0x4000d000
>   read(8, "935 (example) R 934 934 832 769 "..., 1024) = 198
>   read(8, "", 1024)   = 0
>   close(8)= 0
>   munmap(0x4000d000, 4096)= 0
>   gettimeofday({920232779, 618017}, NULL) = 0
>   gettimeofday({920232779, 657611}, NULL) = 0
>   gettimeofday({920232779, 668469}, NULL) = 0
>   gettimeofday({920232779, 684209}, NULL) = 0
>   gettimeofday({920232779, 684496}, NULL) = 0
>   gettimeofday({920232779, 684742}, NULL) = 0
>   kill(937, SIGCONT)  = 0
>   kill(937, SIGSTOP)  = 0
> 
> 
> "example" is the name of my large program.
> 
> See you
> 
> - Markus
> 
> 
> 
> --
> 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]



Java 1.2 w/2.0.X

1999-03-01 Thread Tom McMichael

Hello,
   Am I to assume that jdk 1.2 will not be released for 2.0.X kernels
and only
for the 2.2.X.

... assumed from the status page of jdk 1.2

Tom McMichael
[EMAIL PROTECTED]


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



Status of 1.2 in this article

1999-03-01 Thread Tom McMichael

http://abcnews.go.com/sections/tech/CNET/cnet_javalinux990301.html

According to this article sun says that the 1.2 linux port will be done
in
one to two weeks.

Tom McMichael
[EMAIL PROTECTED]


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



Status of 1.2 in this article

1999-03-01 Thread Steve Byrne

Tom McMichael writes:
 > http://abcnews.go.com/sections/tech/CNET/cnet_javalinux990301.html
 > 
 > According to this article sun says that the 1.2 linux port will be done
 > in
 > one to two weeks.

Now isn't that interesting.  And here I thought it was *I* who decided
when we were ready.

Hmm.  

 > Tom McMichael
 > [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]



Beta tester question

1999-03-01 Thread Greg Sternberg

Hi,

   I don't know if you have any need for a Java 1.2 beta tester but if
you
do I would be interested.

--
Thank you,
Greg Sternberg
Productive Data Systems  "Just because something is obviously
[EMAIL PROTECTED]  happening doesn't mean something obvious
  is happening." - Larry Wall



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