This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 19133 - Unable to make a simple examle with jdk1.3.1_02
Summary: Unable to make a simple examle with jdk1.3.1_02
Alias: None
Product: obsolete
Classification: Unclassified
Component: languages (show other bugs)
Version: 3.x
Hardware: PC Windows ME/2000
: P2 blocker (vote)
Assignee: Milos Kleint
: 24395 (view as bug list)
Depends on:
Reported: 2002-01-08 12:42 UTC by webmarck
Modified: 2008-08-01 15:47 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

This is the ide.log file (138.24 KB, text/plain)
2002-01-08 12:45 UTC, webmarck
Patch of djava TreeClassLoader class. (1.39 KB, patch)
2002-06-05 13:19 UTC, _ hkrug
Details | Diff
final patch to (5.08 KB, patch)
2002-06-05 16:44 UTC, _ hkrug
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description webmarck 2002-01-08 12:42:38 UTC
The following code result in a AccesControlExcetion

# DynamicJava file -
System.out.println("Example script");

// Place the script in the package p.
package p;

public class C {
    public C() {
	System.out.println("C created");

// Place the script in the anonymous package.
import p.*;

// Create an instance of p.C
new C();
Comment 1 webmarck 2002-01-08 12:45:03 UTC
Created attachment 4005 [details]
This is the ide.log file
Comment 2 mvdb 2002-01-08 16:16:35 UTC
This seems to be a classloader issue. 
When setting the netbeans option 
in the ide.cfg, then the exception changes (see below).
Maybe someone better in debugging netbeans can use this info, to get 
it fixed or check if this is a classloader issue in the current 
ClassLoader of DynamicJava. 
Also tested with removing the setting of the fs classpaths, but the 
result is the same.

ue Jan 08 16:07:06 CET 2002: java.lang.NoClassDefFoundError: 
	at p.C.<init>(Unknown Source)
	at java.lang.reflect.Constructor.newInstance(Native Method)
	at koala.dynamicjava.interpreter.EvaluationVisitor.visit
	at koala.dynamicjava.tree.SimpleAllocation.acceptVisitor
	at koala.dynamicjava.interpreter.TreeInterpreter.interpret
	at org.netbeans.modules.scripting.DynamicJavaScriptType.eval
	at org.netbeans.modules.scripting.AbstractScriptType.eval
	at org.netbeans.modules.scripting.AbstractScriptType.exec
	at org.netbeans.modules.scripting.AbstractScriptType.exec
	at org.openide.execution.ScriptType.exec(
	at org.netbeans.modules.scripting.ScriptUtils$
[catch] at
Comment 3 Milos Kleint 2002-01-14 11:57:34 UTC
I wonder  how do we check that if the problem is on Netbeans' or
Dynamic java's side?
have you tried to run your simple example without the IDE?
Comment 4 mvdb 2002-01-14 12:01:29 UTC
The example specified in this message also has been tried with the 
dynamicjava gui provided in the jar file. It executes fin in there. 
The difference of course is that the base classloader of the gui app 
is the System classloader and the base classloader of netbeans is a 
netbeans core one. 
Comment 5 Milos Kleint 2002-01-15 17:06:02 UTC
lowering priority, since no data gets lost/corrupted.
Comment 6 Milos Kleint 2002-01-15 17:25:09 UTC
Please approve this bug as 3.3.1 waiver, for the following reasons.

1. The bug was reported last week, even though it must have been in
the module since the beginning.
2. There's not apparent solution to the problem and even the
investigation of the causes of the bug can take a fair amount of time.
I think I can't come up with a solution before the 3.3.1 release.
Comment 7 brinkley 2002-01-15 17:35:35 UTC
approved waiver
Comment 8 Jan Chalupa 2002-01-15 17:44:02 UTC
Waiver approved by QA.
Comment 9 iformanek 2002-01-16 08:50:43 UTC
Comment 10 eadams 2002-01-16 09:59:49 UTC
Waiver approved.
Comment 11 Milos Kleint 2002-03-13 15:38:31 UTC
here is my analysis of the problem (big thanks goes to P. Nejedly here)

there's the Netbeans systemclassloader, one of it's children is the
Scripting's module classloader which loads the dynamic java classes as

dynamic java itself however uses another, it's own classloader for
execution. It's parent is not set in the dynamic java directly but
rather in the default java.lang.ClassLoader() constructor where the
parent is assigned the systemclassloader. (because djava doesn't
provide a parent itself). Thus the scripting module's loader is
skipped and not taken into account.. that's why we get the CNFE on

Comment 12 Milos Kleint 2002-03-13 15:55:58 UTC
Comment 13 Milos Kleint 2002-03-14 09:22:30 UTC
the problem cannot be fixed from the Netbeans side. At least I didn't
find a way, however it's quite straight forward to fix in the dynamic
java sources (that's where the bug actually is IMHO)

just add this line to the constructor of the class:


that will set the right parent for the dynamic java classloader.
Then it'll work for Netbeans ok. 
I've tried with latest sources of dynamic java, please note that I had
to rename the dynamicjava.jar to djava.jar and move it to netbeans's
modules/ext directory in order to run with netbeans. The condition
with starting netbeans with the command-line switch still applies.

I'll try to contact the author of  dynamic java and will send him my
Comment 14 Milos Kleint 2002-06-05 09:33:01 UTC
*** Issue 24395 has been marked as a duplicate of this issue. ***
Comment 15 _ hkrug 2002-06-05 13:18:15 UTC
I append a patch to DynamicJava which allows to circumvent the
exception reported by Nicolai Marck in his first posting to this issue
without changing the Netbeans policy.

The exception is thrown because a class loader shall be created from
code, in the call chain of which appears a class generated by
DynamicJava (the class `C' in Nicolai's example). The standard
Netbeans ide.policy grant class loader creation permissions only to
code in the Netbeans and JDK directories. Adding

grant {
       permissions java.lang.RuntimePermission "createClassLoader";

would solve the problem, but for the cost of security problems.

The best solution is to create the class loader in privileged code.
This is done in the patch appended. When applying the patch it is not
necessary to make any changes to the standard Netbeans security
settings. The first exception won't be thrown any more.

Note: The line numbers in the patch do not correspond to the line
numbers of the djava sources, because I additionally made other
changes not included in the patch. But this shouldn't be a problem.
Comment 16 _ hkrug 2002-06-05 13:19:15 UTC
Created attachment 6083 [details]
Patch of djava TreeClassLoader class.
Comment 17 Milos Kleint 2002-06-05 13:32:13 UTC
Hello, Holger. Thanks for the patch.

The sources to dynamic java are out of scope of the
project. Please submit the patch to the author of dynamic java. Thanks
a lot.
Comment 18 _ hkrug 2002-06-05 16:43:21 UTC
I know that the sources of djava are outside of Netbeans. Nevertheless
I (maybe erroneously) feel that the djava author does not react to
patches, hence I use this place to store them for later reuse by
whoever wants to use them. So please excuse me filing one (last) patch
to djava.

The previous patch was restricted insofar as it allows to create
classes but not to access their members. The patch which follows
solves all problems and is really an enhancement worth to apply. (I
will send it to the djava author, too.)

It assigns to all classes defined in djava scripts a code base
This value can be overriden by setting the System property
"koala.dynamicjava.interpreter.TreeClassLoader.codesource.url". One
needs only to add the following entry to the policy file to solve all

grant codeBase
Comment 19 _ hkrug 2002-06-05 16:44:28 UTC
Created attachment 6099 [details]
final patch to
Comment 20 Jesse Glick 2002-06-05 17:20:44 UTC
[Without knowing all the details of this bug, just off-the-cuff
comments:] I'm not sure whether setting a special code source is
strictly necessary. When I have had problems that sound like this one
in the past, all that is needed is to grant AllPermission (e.g.) to
the loaded classes. See for example
Module.OneModuleClassLoader.getPermissions(CodeSource) in
core/src/org/netbeans/core/modules/ in the NB source code.
DJava itself is presumably trusted because it is loaded as a module
extension. Therefore it is permitted to grant any permissions to
classes loaded from classloaders it creates. It might grant
AllPermission. Or it might (as here) just set a code source and permit
the application developer to configure permissions for that code
source as they like - more appropriate when you are not sure to what
use the loaded code might be put.

At any rate, thank you for taking the time to write up a patch, but we
can't really do anything with it here. I see that you have already
filed a patch request on SourceForge (see URL). I would suggest you
actually attach your last diff to the S.F. patch report. Let's hope it
(or something like it) gets accepted on that project and incorporated
into a release, which we can then pick up.
Comment 21 _ hkrug 2002-06-10 17:15:15 UTC
Hi Jesse,

The patches are applied to the djava sources. Is that what is needed
for their integration into Netbeans or shall I ask Stephane to roll a
new jar ?

>From: "Stephane Hillion" <>
>To: "Holger Krug" <>
>Subject: RE: djava patch solving security problems
>I applied the two patches you sent to me to the DynamicJava sources

I reopened the issue, because the new djava jar (either self-made or
official) should replace the old one and



added to `'

# permissions for generated djava classes, necessary for users of
# the djava scripting engine
grant codeBase 

added to `ide.policy'. I would prefer the latter.
Comment 22 Milos Kleint 2002-06-12 08:20:42 UTC
I'd rather have a new official version. I've check the webpages od
djavaand the last version is 1.1.4 that came out on 19/03/2001.
With new version out that includes your patch we have a more
transparent process and can give users an idea what we are using.
(saying "we use 1.1.5" is better then "well, we got a patched 1.1.4
that comes from CVS sources from 15/jul/2002")

Once it gets out it's no problem to have it included in the external
Comment 23 _ hkrug 2002-06-13 07:46:41 UTC
I sent an email to Stephane Hillion, the djava developer.
Comment 24 _ hkrug 2002-06-13 12:42:10 UTC
djava 1.1.5 is now officially available.

See and especially

Please add it to the external binaries and make the aforementioned
changes either in `' or (preferably) in `ide.policy'.

That's all. Many thanks for your cooperation !
Comment 25 Milos Kleint 2002-06-13 15:08:27 UTC
ok, I've initiated the process to have the new jar in the external
binaries. (There's paperwork involved.. :( )
Once i get the approval I'll commit the change.
Comment 26 Milos Kleint 2002-07-10 10:04:19 UTC
the dynamic java 1.1.5 is now part of the trunk external binaries.
the patch to ide.cfg commited. 

Thanks a lot, Holger.