-> pnejedly.  Not sure if it has anything to do with patching bytecode.

Note: no line numbers in stack trace :-(

Especially exciting exception, seeing as there are no synchronized
statements in this method at all.

Gili, is this reproducible?

Reproducable? Not exactly.. I got it randomily while using JavaCVS. I
will most probably run into it again within the following days and
follow up.

BTW:

- Note the dev build where this bug was reproduced, there might have
been synchronization blocks then (?)

- If your code makes use of built-in JVM classes which are not
thread-safe (such as SimpleDateFormat, for example) you could end up
seeing this error.

OK, boys, I've read the Javadocs for ya ;-)
It can't be caused by using any thread unsafe class.
It can't be caused by presence of "synchronized", but it can
(only) be caused by the absence of "synchronized.

IMSE is thrown if you call any version of wait() or notify*()
on an object you don't have locked.
This will throw IMSE:
public class MonitorTest {
    public static void main(String[] args) {
        "Test".notify();
    }
}

This will not throw IMSE:
public class MonitorTest2 {
    public static void main(String[] args) {
        synchronized("Test") {
            "Test".notify();
        }
    }
}

Please note there is no wait or notify in the whole ProxyClassLoader
and its superclasses.

The "JVMLK001" seems very suspicious to me...

*** Issue 26769 has been marked as a duplicate of this issue. ***

NOTES: 

- "JVMLK001" is a JVM-specific message, doesn't mean much (looks like
it refers to a "JVM lock")

- Contrary to your last message, it is quite possible to get a
IllegalMonitorStateException by calling a thread-unsafe class. The
difference is that you'd probably see that class in the stacktrace and
in this case we don't so our code is probably responsible, not some
3rd party class.

Be concrete. How can I get IllegalMonitorStateException by calling
"thread unsafe class"? What do you mean by that term.
If you mean totally unsynchronized class (Like, say, ArrayList),
all I can get is a race condition and corrupted data but not IMSE
as there is *no monitor* that can be in illegal state.

Please read the Javadoc for IllegalMonitorStateException,
you should get it only by calling Object.notify(), Object.notifyAll(),
Object.wait() while not owning the objects lock (i.e. out of the
synchronized section).
If it is thrown elsewhere, it is JVMs fault.

All I know is that when I accessed the same SimpleDateFormat from
multiple threads simultaneously I got this error and once I
synchronized the error went away. The stacktrace pointed to a line
*inside* SimpleDateFormat. Not exactly sure why this is. Anyway, you
can ignore this case if you wish and simply rely upon the case
discussed in the Javadoc since the case I'm discussing doesn't seem to
be relevant to this specific issue.

"All I know is that when I accessed the same SimpleDateFormat from
multiple threads simultaneously I got this error and once I
synchronized the error went away." - in that case it seems clear to me
that the JVM is broken. Did you report a bug about it?

What remains is to figure out why NB code might be triggering this JVM
bug and what we might be able to do about it. I have no suggestions
yet, since I am not aware of anything wrong with our code, or even
anything particularly fishy in what it is doing (as far as threading
goes).

I did not file a bug against the JVM because I was doing something
explicitly forbidden: allowing multiple threads to access the same
SimpleDateFormat object. The error might not have been what I wanted
it to be but I'm pretty sure Sun would have closed it off as a "user
at fault" error.

As per your code, if you want you can you email me a copy and I'll try
to help you with it.

"I was doing something explicitly forbidden: allowing multiple threads
to access the same SimpleDateFormat object." - yes, this is a user
error, and the SimpleDateFormat class is permitted to behave
unpredictably if you try to do this. However (as far as I know) the
JVM is at fault for throwing IMSE, which is only supposed to be thrown
as a result of using wait() or notify() without a lock. For the IBM
1.3 VM to throw it under other conditions probably violates the JLS.

The question is still open what these "other conditions" actually are.

FWIW I just tried IBM JDK 1.3.1 on my Linux box with a current dev
build, and had no problems, incl. using JavaCVS. Suggest this be
marked WORKSFORME unless there is a definite way to reproduce the
exception.

I'd like you to quickly review the function in question --
org.netbeans.ProxyClassLoader.smartLoadClass() -- for any signs of
anything that could cause a IMSE. If you can't find anything feel free
to close the issue; I will reopen it if I see this in any future builds.

There's nothing suspicious in the ProxyClassLoader and the problem
never occured during long usage of ProxyClassLoader.

Note: There are only few IMSEs in the whole issuezilla,
most of them filled by you lately, nonreproducible and at impossible
places. I bet your JVM is broken.

FYI, I've made more headway on this issue.. The exception quoted by
ide.log was misleading and points to the wrong piece of code. What's
actually happening is that an IllegalMonitorException is being thrown,
caught and another exception is being thrown in its place using the
original IMSE's getMessage() for its own message. The result is that
the message still reads: "IllegalMonitorStateException" but the
stackTrace actually leads you to the second exception, not the first.

    I've tracked one IMSE back to its source, although it might be a
different IMSE than the one originally reported here. I get the
following exception:


java.lang.IllegalMonitorStateException: JVMLK002: current thread not owner
	at
org.netbeans.ProxyClassLoader.loadInOrder(ProxyClassLoader.java(Compiled
Code))
	at
org.netbeans.ProxyClassLoader.smartLoadClass(ProxyClassLoader.java(Compiled
Code))
	at
org.netbeans.ProxyClassLoader.loadClass(ProxyClassLoader.java(Compiled
Code))
	at java.lang.ClassLoader.loadClass(ClassLoader.java(Compiled Code))
	at
org.openide.loaders.InstanceSupport.findClass(InstanceSupport.java:534)
	at
org.openide.loaders.InstanceSupport.instanceClass(InstanceSupport.java:132)
	at
org.openide.loaders.InstanceDataObject$Ser.instanceClass(InstanceDataObject.java:1084)
	at
org.openide.loaders.InstanceSupport.instanceCreate(InstanceSupport.java:204)
	at
org.openide.loaders.InstanceDataObject$Ser.instanceCreate(InstanceDataObject.java:1143)
	at
org.openide.loaders.InstanceDataObject.instanceCreate(InstanceDataObject.java:674)
[catch] at
org.netbeans.core.ShortcutsFolder.acceptDataObject(ShortcutsFolder.java:127)
	at
org.openide.loaders.FolderInstance.defaultProcessObjects(FolderInstance.java:484)
	at org.openide.loaders.FolderInstance.access$100(FolderInstance.java:45)
	at org.openide.loaders.FolderInstance$2.run(FolderInstance.java:456)
	at org.openide.util.Task.run(Task.java:136)
	at
org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:599)


   A quick scan of ProxyClassLoader.loadInOrder() doesn't seem to
reveal any cause for IMSE but I'll keep on investigating until I find
the source. This just goes to show you debugging this code isn't
necessarily so straight forward. Furthermore, I don't think it makes
sense to close a bug as WORKSFORME when the person is unable to
actually run tests against the platform in question.

   I'll let you know when I figure this one out.

OK, well you seem to be the only one able to produce the bug and
conceivably find a fix, so you are the logical assignee for it. IMSE
is still illegal to throw from that location as far as I know.

Where was an exception being rethrown with just the message kept?

org.openide.loaders.InstanceSupport.instanceClass(): line 148
repackages IMSE's message and rethrows it inside a ClassNotFoundException.

Yes, this is so; however it (1) does not keep the same
Throwable.message, it creates a new one, (2) uses ErrorManager to
annotate the new exception with the old one, meaning that if the CNFE
is reported using ErrorManager.notify (as all exceptions in NB are
supposed to be) then both stack traces will be visible. Obviously
something here is not working, but I couldn't guess what.

*** Issue 25871 has been marked as a duplicate of this issue. ***

I haven't seen this issue in a long time. Closing as WORKSFORME.

closing.