I'm not sure about the impact. So adjust the priority as it is appropriate.

Well, I can't reproduce the problem in a test and you claim it fails only "sometimes", so I don't think it is that big
problem. If you can reproduce it, please generate a heap dump after reproduction, I'll try to analyze it.

I can't reproduce either. Jirka reproduced on Windows (as was said in the mentioned issue 114387).

Actually I'm not sure about the 'sometime'. Jirko are you able to reproduce always with the build you showed me
yesterday on Windows? I was not able to reproduce on *Linux*. So if Jirka is able to reproduce with Windows on 100% just
change the Platform/OS, since it might Windows specific. I've just filed issue on your behalf ;)

After extensive review, I have found a single case of locating resources that used to work and is broken now:
getResources("/file"), that is, locating it using getResources() (instead of getResource()), placing it into default
package (which is discouraged) and referencing it with leading slash (which is discouraged as well).

I'll commit both a fix for this case and a test covering all potential failure modes.

I was able to reproduce it on WindowsXP, JDK1.6.0_02. When you fix it I will verify if it works for me.

I was able to reproduce the problem on Linux as well; the trick seemed to be to not use a new user directory.

Start NetBeans with a new user directory. Open Window > Output > IRB. Restart the IDE and do the same thing again. The
second time, this failed for me. (Note - you can't use the trunk since as of yesterday I've fixed the problem with IRB
by changing the file out of the default package; you need to use a build from yesterday morning or a current beta1
build. (I may soon integrate the fix into beta1 unless you plan to fix this issue in beta1.)

Regarding "getResources("/file")" - the code in question in JRuby was

Constants.class.getResourceAsStream("/jruby.properties")

Regarding "referencing it with leading slash (which is discouraged as well)" - that's well and good for module code, but
what about usage of 3rd party libraries which is doing it? I suppose there are ways to include the library through an
explicit class loader that I supply myself which performs translation, but that certainly sounds like nontrivial work
since the code is using the class loader that the original class was loaded with (referenced from ALL over my source).

I said it is discouraged, not that it shouldn't work.
Moreover, I talked specifically about ClassLoader.getResource(). Class.getResource() HAS to use initial slash and does
it right. It gets translated along the way.

Anyway, thanks for the info. I have extended the test to cover the case with cached package coverage and found that it
can fail even without initial slash and getResources() call. The problem is in StringTokenizer usage, which doesn't
parse empty token, it seems.

Fixed both scenarios with tests (trunk only).

Verified in trunk.