There is a bug reported by NetBeans team 
http://www.netbeans.org/issues/show_bug.cgi?id=21022
Working with RMI crash JVM

It was originally reported against JDK1.4.0 and pointed to bug 4623152 - JVM crash during dynamic class installation that is fixed in JDK1.4.1-b10. Now our testing reveals an xxxxx  problem and with JDK1.4.1-b10. JVM process crashes or falls into some bad state (request for HttpUrlConnection is send but no response is generated). The bug description on NetBeans.org site contains more information how to reproduce it, thread dumps and  xxxxx  details.

When the IDE runs with -Xcheck:jni the following output is generated. Note that there is no native code provided by the IDE.
 
FATAL ERROR in native method: Null object passed to JNI
    at java.net.PlainSocketImpl.socketAccept(Native Method)
    at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:343)
    - locked <0x450b9f70> (a java.net.PlainSocketImpl)
    at java.net.ServerSocket.implAccept(ServerSocket.java:439)
    at java.net.ServerSocket.accept(ServerSocket.java:410)
    at org.apache.tomcat.service.PoolTcpEndpoint.acceptSocket(PoolTcpEndpoint.java:286)
    at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:402)
    at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498)
    at java.lang.Thread.run(Thread.java:536)

The behavoiur is similar with -Xint switch so it should not be problem of compiler. The stacktrace from core dump will be attached.


 xxxxx@xxxxx  2002-09-30
JDK 1.4.1-b21
This bug causes NetBeans 3.4 to crash during execution of RMI application.
The RMI executor uses http java.rmi.server.codebase and java.security.policy.
The http server is netbeans internal httpserver (Apache Tomcat) which crashes
the JVM.
This makes the RMI module hard to use, there is a work around but it is quite complicated for the user.

How to reproduce:
1. Install NB 3.4
2. Create RMI Server Application from the Template
3. Execute it using RMI Executor
4. If the IDE does not crash, terminate the application and start it again.

If JVM is run with -Xcheck:jni
the output is:
FATAL ERROR in native method: Null object passed to JNI
at java.net.PlainSocketImpl.socketAccept(Native Method)
        at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:353)
        - locked <0x45452858> (a java.net.PlainSocketImpl)
        at java.net.ServerSocket.implAccept(ServerSocket.java:439)
        at java.net.ServerSocket.accept(ServerSocket.java:410)
        at org.apache.tomcat.service.PoolTcpEndpoint.acceptSocket(PoolTcpEndpoint.java:286)
        at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:402)
        at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498)
        at java.lang.Thread.run(Thread.java:536)

N/A

The "Null object passed to JNI" error stems from a unchecked call to
JNI's NewObject. The returned object is provided to a subsequent JNI call
without first checking if NewObject failed. Typically NewObject can only
fail if we are out of memory, the ctor throws an exception, or we try
to create an instance of an interface or abstract class. In the case of a java.net.Inet4Address (which this test is failing on) the class is a concrete
class and the no-arg ctor doesn't throw an exception. It is therefore likely that the exception is an OutOfMemoryError.

 xxxxx@xxxxx  2002-10-01


The exception has now been tracked now - it's a ThreadDeath caused by
NetBeans stopping an entire thread group. 

For mantis we'll fix this so that all JNI calls are checked.
 xxxxx@xxxxx  2002-10-07