franciscocpg / beanshell2 Goto Github PK

Copied from 
https://sourceforge.net/tracker/?func=detail&aid=3117777&group_id=4075&atid=1040
75

If the BeanShell jar is loaded by the boot class loader (which will happen with 
its use in Xbootclasspath or with Java agents), the bsh.Interpreter constructor 
will blow up with the following NPE:

Exception in thread "Thread-13" java.lang.NullPointerException
at bsh.classpath.ClassManagerImpl.classForName(Unknown Source)
at bsh.NameSpace.classForName(Unknown Source)
at bsh.NameSpace.getClassImpl(Unknown Source)
at bsh.NameSpace.getClass(Unknown Source)
at bsh.Name.consumeNextObjectField(Unknown Source)
at bsh.Name.toObject(Unknown Source)
at bsh.Name.toObject(Unknown Source)
at bsh.NameSpace.get(Unknown Source)
at bsh.Interpreter.get(Unknown Source)
at bsh.Interpreter.getu(Unknown Source)
at bsh.Interpreter.<init>(Unknown Source)
at bsh.Interpreter.<init>(Unknown Source)
at bsh.Interpreter.<init>(Unknown Source)
at com.my.code.Class.java:387)

This is because of the following code from ClassManagerImpl.java (unknown line) 
from classForName():

if ( name.startsWith( BSH_PACKAGE ) )
try {
c = Interpreter.class.getClassLoader().loadClass( name );
} catch ( ClassNotFoundException e ) {}

If the Interpreter class, along with the rest of bsh is loaded from the boot 
class loader, the getClassLoader() call will return null, and the loadClass() 
call will cause an NPE. Sorry that I don't have time to suggest a proper fix or 
provide a proper unit test. Maybe replacing the call with a Thread context 
class loader if the class loader is found to be null.

Most scripting languages allow for multi-line string literals.  I suggest
copying Groovy for this, and use triple quotes """ to quote multi-line
strings.  See:

http://groovy.codehaus.org/Strings

This is a syntax extension, and I don't want to extend BeanShell too much,
like Groovy did.  But I can't think of a single successful scriping
language that doesn't have this feature, so I think we should add it.  And
I personally need it.

foo( x ) { print("foo1");}
foo( x ) { print("foo2");}

foo(1);  // produces "foo1" should produce "foo2"

----------

I will write a junit test for this, also someone on the users lists said 
they had a fix for this in their local build, I will research to see if I 
can get that submitted.

Null values (and void, I think, too) do not serialize/deserialize correctly. To 
demonstrate, run this code (in Java, not beanshell):
        Interpreter origInterpreter = new Interpreter();
        origInterpreter.eval("myNull = null;");
        ByteArrayOutputStream byteOS = new ByteArrayOutputStream();
        new ObjectOutputStream(byteOS).writeObject(origInterpreter);
        Interpreter serInterperter = (Interpreter)new ObjectInputStream(
                new ByteArrayInputStream(byteOS.toByteArray())).readObject();
        System.out.println("Expected " + origInterpreter.eval("myNull")
                + ", but got " + serInterperter.eval("myNull"));
        System.out.println("Expected " + origInterpreter.eval("myNull == null")
                + ", but got " + serInterperter.eval("myNull == null"));     

The expected output is:
Expected null, got null
Expected true, got true

Instead, the result is:
Expected null, got bsh.Primitive$Special@169e11
Expected true, got false

class bar {
static { print("bar"); }
};

produces 


// Error: Parser Error: Parse error at line 1, column 763.  Encountered: 
static

I dont know how to make a test case for this because it doesnt even parse.

I suggest adopting some (written) coding conventions to keep the source
easier to read, and to avoid some common pitfalls that occur when the
compiler is the only syntax verification step.

Sun has published a set of guidelines that look fairly reasonable, and
should be easy to configure an IDE to help enforce:

http://java.sun.com/docs/codeconv/

(My biggest complaint with these standards is the liberal use of /* */
comments, instead of // comments, and that there is no distinction in
variable naming for instance variables, but I think this is good enough.)

They can also be partially enforced with indent(1) although I have no
experience with that tool myself.

If there are no objections, or other suggested guides to consider, then
I'll start working on this in a day or two, and try to work through the
codebase gradually as I learn the structure of the code myself.

What steps will reproduce the problem?
1. Write an applet that uses beanshell scripts, I think nothing really 
complicated is needed to trigger this issue.
2. Watch how the applet slows to a crawl.

What is the expected output? What do you see instead?

Something that runs in one second in the local machine can take minutes on 
a slow connection.

The reason seems to be that the applet tag puts the codebase into the 
classpath, and BeanShell looks there first in its Class.forName(...) and 
similar calls. This doesn't seem to make much sense, as it should at the 
very least look in the local jars first.

I have stumbled into this issue now but it is better documented in the old 
beanshell list, there are several threads reporting it:

http://osdir.com/ml/java.beanshell.user/2005-04/msg00031.html
http://osdir.com/ml/java.beanshell.user/2005-03/msg00033.html
http://osdir.com/ml/java.beanshell.user/2005-11/msg00033.html

This is a real show-stopper for anyone wanting to use beanshell in 
applets. A fix in beanshell2 would be very nice.

Provide JSR-223 javax.script support

see
http://sourceforge.net/tracker/index.php?func=detail&aid=1897313&group_id=4075&a
tid=104075

Test case is "classinterf1.bsh"

This interface couldn't be 'compiled' (because of the constant definitions):

interface TestInt1 {
        static int a = 5;
        static int b = 6;
        void go() { }
}

What steps will reproduce the problem?
1.I am using beanshell with ant, bsh-2.1b1.jar can produce this issue, not with 
bsh-2.0b5.jar
2.I use beanshell with ant task <scriptdef>, when this task is called, the 
message is printed.

<scriptdef name="postprocessvcproj" language="beanshell">
        <attribute name="newvcproj" />
        <attribute name="oldvcproj" />
    <![CDATA[

    import java.io.*;
    import java.util.regex.*;
    import org.apache.tools.ant.*;

    synchronized ( this ) {

    String newvcproj_fname = attributes.get("newvcproj");
    String oldvcproj_fname = attributes.get("oldvcproj");

    boolean dontPatchImportLibrary = newvcproj_fname
        .contains("ImagePerceptualDifference");

    String oldvcprojWithoutGUID = "";
    try {
      StringBuffer result = new StringBuffer();
      BufferedReader bReader = new BufferedReader(new FileReader(
          oldvcproj_fname));
      String lineIn;
      while ((lineIn = bReader.readLine()) != null) {
        result.append(lineIn + "\n");
      }
      bReader.close();
      oldvcprojWithoutGUID = result.toString().replaceAll(
          "ProjectGUID=\".*\"", "ProjectGUID=\"\"");
    } catch (Exception e) {
    }

    try {
      StringBuffer result = new StringBuffer();
.......
.......

        } catch (Exception e) {
        }
      }

      if (!oldvcprojWithoutGUID.equals(vcprojWithoutGUID)) {
        // System.out.printf("patched: %s \n", patchImportLibrary ?
        // "true" : "false");
        // System.out.println("updated vcproj");
        FileWriter fstream = new FileWriter(oldvcproj_fname);
        BufferedWriter out = new BufferedWriter(fstream);
        out.write(vcproj);
        out.close();
      }
    } catch (Exception e) {
      self.fail("postprocessvcproj failed: " + e.getMessage()
          + "\n  old vcproj: " + oldvcproj_fname + "\n  new vcproj: "
          + newvcproj_fname + "\n");
    }
    }
    ]]>
</scriptdef>


3.The ant script task is called like this:
<postprocessvcproj newvcproj="${qmake.projectdir.@{projectfile}.vcproj}.cached"
                oldvcproj="${qmake.projectdir.@{projectfile}.vcproj}" />

What is the expected output? What do you see instead?
I expect no message "experiment: creating class manager" printed from 
postprocessvcproj task, but the result is:
[postprocessvcproj] experiment: creating class manager

Please use labels and text to provide additional information.

All,
   I found more than people reported that beanshell console hangs. I think this may relate to the communication mechanism used between JConsole and Interpreter. Basically, both of them were too closely coupled. I believe the originally intention was to use interpret to decide when a script ends. I don't think this is important. The MySQL console allows you set delimiter anytime. We can also do this.

   I just decoupled them by doing the following:
   1) let JConsole drive the process (no thread is needed)
   2) by default the delimiter is \g, but users can set delimiters in the console at anytime.
   3) JConsole captures the output of System.out and System.err by stream instead of thread.

   By doing the above, the threads in both JConsole and Interpreter are avoid. Besides, the history buffer can capture the whole script instead of lines ended by "return" key.

   I'm currently doing testing. I'll publish it as soon as I can.

BshMethod.equals() succeeds when comparing subclasses with BshMethod instances:

{{{
   @SuppressWarnings("serial")
   @Test
   public void testEqualsObject_subclassEquality() {
      // define a simple subclass of BshMethod:
      class SubMethod extends BshMethod {
         public SubMethod(String name, Class returnType, String[] paramNames,
               Class[] paramTypes, BSHBlock methodBody,
               NameSpace declaringNameSpace, Modifiers modifiers) {
            super(name, returnType, paramNames, paramTypes, methodBody,
declaringNameSpace,
                  modifiers);
         }
      };

      final String name = "testMethod";
      final BshMethod subInst = new SubMethod(name, 
            Integer.class, new String[]{}, new Class[]{}, null, null, null);
      final BshMethod supInst = new BshMethod(name, 
            Integer.class, new String[]{}, new Class[]{}, null, null, null);

      Assert.assertFalse("Subclasses should not be equal to super classes",
            supInst.equals(subInst));
   }
}}}

This method also does not support the hashcode/equals contract:

{{{
   @Test
   public void testHashCode_contract() {
      final String name = "testMethod";
      final BshMethod method1 = new BshMethod(name, 
            Integer.class, new String[]{}, new Class[]{}, null, null, null);
      final BshMethod method2 = new BshMethod(name, 
            Integer.class, new String[]{}, new Class[]{}, null, null, null);

      Assert.assertTrue("precondition check for test failed.", 
            method2.equals(method1));
      Assert.assertEquals("Equal classes should have equal hashcodes",
            method2.hashCode(), method1.hashCode());
   }
}}}

This is a fairly easy fix, as long as it is not intentional.  I'll try and
attach a patch tonight / tomorrow.

I suggest adding 2 commands:

List list(Object... objs) {
    return new ArrayList(Arrays.asList(objs));
}

Map map(Map.Entry... entries) {
    Map map = new HashMap();
    for( Map.Entry entry : entries ) {
        map.put( entry.getKey(), entry.getValue() );
    }
    return map;
}

And I suggest adding one binary operator => which would create a Map.Entry
.  So now we could do things like:

numbers = list( 1, 2, 3 );
numberNames = map( 1 => "one", 2 => "two", 3 => "three" );

compile this java:

public class T {
    private static String foo( Integer x ) { return "integer"; }
    public static String foo( Number x ) { return "number"; }
}

then run this:

i = new Integer(9);
setAccessibility(true);
print(T.foo(i));
setAccessibility(false);
print(T.foo(i));

The second print still calls the private method because it is cached in the
BshClassManager.  This is quite a mess because accessibility is a static
variable in Capabilities while there can be many BshClassManagers.  The
best solution I see is to keep a counter in Capabilities and increment it
for each call to setAccessibility() and then have each BshClassManager keep
its own counter and if it falls behind, clear the method cache.

Run "test" ant build.  class3.bsh fails


     [java] Script: class3.bsh produced an eval Error: Sourced file: 
class3.bsh : Object constructor : at Line: 74 : in file: class3.bsh : new 
Bar33 ( )
     [java] Called from method: run : at Line: 60 : in 
file: /bsh/commands/run.bsh : run ( filename , null )
     [java] Target exception: java.lang.IllegalAccessError: tried to 
access method Foo33.<init>()V from class Bar33
     [java] Test: class3.bsh FAILED!

What steps will reproduce the problem?
1. build beanshell
2. run the "tests" ant build
3. look for failed tests

What is the expected output? What do you see instead?
Expected: No failed tests
See:

    [java] FAILED Tests:
     [java] accessibility.bsh
     [java] class13.bsh
     [java] class3.bsh
     [java] classinterf1.bsh
     [java] strings.bsh
     [java] Warnings on Tests:
     [java] methodselection2.bsh


Please use labels and text to provide additional information.

see
http://sourceforge.net/tracker/index.php?func=detail&aid=1897015&group_id=4075&a
tid=104075

After the cleanups in rev. #13, bsh-core built by "ant jarcore" is unusable, 
because BshClassManager now depends on BshClassManagerImpl, which is not 
available in Core.

$ java -jar bsh-core-2.1b3.jar

Exception in thread "main" java.lang.NoClassDefFoundError: 
bsh/classpath/ClassManagerImpl
    at bsh.Interpreter.<init>(Interpreter.java:190)
    at bsh.Interpreter.<init>(Interpreter.java:223)
    at bsh.Interpreter.<init>(Interpreter.java:229)
    at bsh.Interpreter.main(Interpreter.java:411)
Caused by: java.lang.ClassNotFoundException: bsh.classpath.ClassManagerImpl
    at java.net.URLClassLoader$1.run(URLClassLoader.java:217)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
    ... 4 more

Here is the particular code change:

@@ -137,19 +135,9 @@
        {
                BshClassManager manager;

-               // Do we have the necessary jdk1.2 packages and optional 
package?
-               if ( Capabilities.classExists("java.lang.ref.WeakReference") 
-                       && Capabilities.classExists("java.util.HashMap") 
-                       && 
Capabilities.classExists("bsh.classpath.ClassManagerImpl") 
-               ) 
-                       try {
-                               // Try to load the module
-                               // don't refer to it directly here or we're 
dependent upon it
-                               Class clas = Class.forName( 
"bsh.classpath.ClassManagerImpl" );
-                               manager = (BshClassManager)clas.newInstance();
-                       } catch ( Exception e ) {
-                               throw new InterpreterError("Error loading 
classmanager: "+e);
-                       }
+               // Do we have the optional package?
+               if ( Capabilities.classExists("bsh.classpath.ClassManagerImpl") 
) 
+                       manager = new bsh.classpath.ClassManagerImpl();
                else 
                        manager = new BshClassManager();


The java package checks can be probably removed, but the rest of the patch 
should be reverted to make bsh-core usable.

The BeanShell parser can be used to parse a script and then walk through the 
abstract syntax tree.  Unfortunately, all of the node objects have package 
protected access, which means that you really cannot use this feature from user 
code.  Even the example in the documentation for the bsh.Parser class will not 
work due to class protection.

I propose to change the protection to public for all nodes classes.  In 
addition, I would like one small change to the parser so that informal comments 
are not skipped, but instead are included in comments nodes (just like JavaDoc 
comments).  This should not have any side effects.

One of the motivations for this is to develop two-way editing tools.  Another 
motivation is to investigate source code translation tools, perhaps to 
automatically convert BeanShell scripts to other languages (like Groovy).

int fn() {
    try {
        return 1;
    } finally {}
    print("shouldn't get here, but does");
    2;
}

print(fn());

The code now compiles with JDK 1.5 .  We should add support for Java 1.4 by
using a tool like:

http://retroweaver.sourceforge.net/
http://retrotranslator.sourceforge.net/

This should be added into the build to produce a separate jar for Java 1.4 .

I started looking through the code and a lot of it is really messy because
of support for old JDKs.  I suggest we assume a modern JDK, say JDK 1.5,
and clean up the code.  Simpler code has fewer bugs.

[deleted issue]

Class comment in bsh.Interpreter states:

    In the above examples we showed a single interpreter instance, however 
    you may wish to use many instances, depending on the application and how
    you structure your scripts.  Interpreter instances are very light weight
    to create, however if you are going to execute the same script repeatedly
    and require maximum performance you should consider scripting the code as 
    a method and invoking the scripted method each time on the same interpreter
    instance (using eval()). 

But if you do so, and if you do it concurrently, and the block contains a class 
definition you will encounter an internal error:

Defining class problem: Check: BeanShell cannot yet simultaneously define two 
or more dependant classes of the same name. Attempt to define: X while 
defining: X
at bsh.BshClassManager.definingClass(Unknown Source)
at bsh.ClassGeneratorImpl.generateClassImpl(Unknown Source)
at bsh.ClassGeneratorImpl.generateClass(Unknown Source)
at bsh.BSHClassDeclaration.eval(Unknown Source)
at bsh.BSHBlock.evalBlock(Unknown Source)
at bsh.BSHBlock.eval(Unknown Source)
at bsh.BshMethod.invokeImpl(Unknown Source)
at bsh.BshMethod.invoke(Unknown Source)
at bsh.BshMethod.invoke(Unknown Source)
at bsh.This.invokeMethod(Unknown Source)
at bsh.This.invokeMethod(Unknown Source)

This is a parse error for:

"\1"

This should be easy to fix once I figure out how the parser works.

When trying to create an anonymous class from an Applet (or other
environments with restricted policies) you get an exception.

You can reproduce the problem evaluating this code from an applet:

Runnable r = new Runnable(){ 
  public void run() {}
};

In ClassGenerator.java, line 78, I found this comment:

// Scripting classes currently requires accessibility
// This can be eliminated with a bit more work.

I think it's a bit optimistic, but I want to believe :-)

Can you tell me if it is planned to be fixed? I know that working with
applets in 2009 sounds a bit strange, but believe me, it's for a good cause ;-)

regards

Luigi

Purpose of code changes on this branch:

Allow compiling main code without compiling tests.

When reviewing my code changes, please focus on:

Is this a logical way to organize build.xml?

The following tests are apparently well-known to fail.

test-scripts failures:

     [java] FAILED Tests:
     [java]     class13.bsh
     [java]     class3.bsh
     [java]     classinterf1.bsh
     [java]     commands.bsh
     [java]     run.bsh

I suggest we break out the "failing" tests into a separate ant target 
"known-failing-tests". That will expedite validation of the codebase when new 
patches applied.  

I am volunteering to make this new ant target, and in fact will assign the bug 
to myself.  Any comments welcome, otherwise will do this and check in changes 
within 48 hours.

Beanshell desktop error hanging forever and never shown.

The error is due to swing show() outside a swing thread.

proposed correction 
file src/bsh/commands/desktop.bsh
replace following (lines 215 to 220)
        frame.show();

    Util.endSplashScreen();

    frame.toFront();
    workSpace.frame.selected=true;

by.
    Util.endSplashScreen();
        EventQueue.invokeLater(new Runnable() {
            public void run() {
               frame.setVisible(true);    
               frame.toFront();
           workSpace.frame.selected=true;
            }
           }
        );

it seems to correct the error.

Java now supports variable numbers of arguments.  BeanShell should too. 
For example:

List list(Object... objs) {
    return new ArrayList(Arrays.asList(objs));
}

In keeping with BeanShell allowing types to be left out, we should also allow:

list(... objs) {
    return new ArrayList(Arrays.asList(objs));
}

Run the unit test for class13.bsh

     [java] Running test: class13.bsh
     [java] Test FAILED: Line: 35 : assert ( isEvalError ( "new 
TestInner1.InstanceInner1().go()" ) )  : while evaluating file: class13.bsh


The comment for this failure indicats that while it is wrong, its "OK" 

// This should really not work... but it's actually ok unless we try to 
// access instance stuff

I actually cannot see why it is expecting to fail.

When tests fail to compile for whatever reason, it is convenient for end
users to be able to compile the rest of the package anyway.  I have patched
the build file to make this easier.

The patch basically changes the compile target not to compile tests,
creates a new compile-tests target that compiles only tests (to a dedicated
directory), creates a compile-all target that depends on compile and
compile-tests, and makes compile-all the default.

I know there are other ways to modify the build to accomplish the same
goal, and I can change my patch if desired.  There are probably bugs in the
patch, because I have not been able to fully test (because the tests don't
compile. :) ).

Interpreter.java has a static field which will hold a back reference to the 
first created Interpreter instance and all local variables of this interpreter.

Simple test case to reproduce:

    public void check_for_memory_leak() throws Exception {
        final WeakReference<Object> reference = new WeakReference<Object>(new Interpreter().eval("x = new byte[1024 * 2024]; return x;"));
        while (reference.get() != null) {
            System.gc();
            Thread.sleep(100);
        }
    }

I would like to move the ASM classes from asm/src/bsh/org/objectweb/asm
into the regular src tree (to src/bsh/org/objectweb/asm).  This is just for
convenience and I don't see any downside to this.  Let me know if you object.

These methods share a great deal of code, and per. source comments could
probably be merged / refactored.

Looking at the code, I don't agree with the failed assertion:

assert(m.foo(null).equals("public"));

m.foo(null) is ambiguous and BeanShell takes the first matching method.  Is
that acceptable?  If yes, then we should remove this assertion.

Here is a simpler version of the same issue:

in T.java:

public class T {
    public static String foo( Integer x ) { return "integer"; }
    public static String foo( String x ) { return "string"; }
}

Then try this BeanShell:

print(T.foo(null));

What should happen?

This is an enhancement which should probably go into a future branch/fork.

A current problem with BeanShell is that it is highly unsecure if run 
within a larger environment.  For example, adding scripting to a J2EE 
environment where the scripts can be user written.   Since BeanShell can 
execute any java code then it can do things that affect the entire 
environment.  A simple example would be System.exit(1) which could bring 
an entire tomcat server down.

A proposed solution to this is implementing your own SecurityManager, but 
this is a very tricky thing to do correctly.  Furthermore, it is desirable 
to allow pure java code to not be managed, but beanshell code to be 
managed.  For example, if I write a custom command I want it to be able to 
do anything, but I dont want user entered scripts to be able to access 
classes or methods outside my "sandbox" (whatever that is).


I propose an enhancement similar to the import() methods which do the 
following, and affect beanshell code only.   Clearly this needs to be 
thought through much more.



1) Add a set of methods which let you setup a list of allowed packages 
and/or allowed classes.   BeanShell script would be unable to instantiate 
any classes not in this list.   However if an instance of these classes 
were set into the beanshell environement from outside (by set() or 
function arguments, or return valids from methods from allowed objects) 
they could be used.   Public static methods not in the list of 
packages/classes could not be called.  Public static variables could not 
be accessed.

The philosophy of this change is "If not allowed you cant do it".
That is security by lists of "allow" not "deny".  That way if new classes 
are added you dont have to keep adding to a list of "bad" classes.


2) Further refinement of #1, allow individual static methods of selected 
classes to be executed. This would be an "allow" list which augments #1.
For example you may want to allow "System.out" to be accessed but not the 
rest of System.


3) Similar to #2, a way to limit global beanshell functions which can be 
called.  Some global beanshell functions could be considered "unsafe" in 
some contexts such as the file access functions.

Copied from 
https://sourceforge.net/tracker/?func=detail&aid=2562805&group_id=4075&atid=1040
75

In bsh.Reflect.java the below code fails if debug is turned on and one of 
method arguments is null.

Since args[i] is null, args[i].getClass() throws NullPointerException.

This makes debuging impossible in some cases.

Line:
+" type = "+args[i].getClass() );

Should be:
+" type = "+(args[i] == null ? "void" : args[i].getClass()) );


{{{
    private static void logInvokeMethod(String msg, Method method, Object[] args) {
        if (Interpreter.DEBUG) {
            Interpreter.debug(msg + method + " with args:");
            for (int i = 0; i < args.length; i++) {
                Interpreter.debug("args[" + i + "] = " + args[i] + " type = " + args[i].getClass());
            }
        }
    }
}}}

What steps will reproduce the problem?

1. Write some .java source, which contains generics classes, enum, annotations.
2. Read .java source into string value and call BeanShell.evalute().
 -> Get Exeption

As I understand beanshell currently not supported this.
May be, it will be hard to implement this features, especially generics.

Do you plan this in future?

BeanShell uses an ancient version of ASM.  See:

http://asm.objectweb.org/

This needs to be upgraded to fix a number of bugs and to add new java features.

see
http://sourceforge.net/tracker/index.php?func=detail&aid=1781130&group_id=4075&a
tid=104075

I find it fairly difficult to ensure that minor changes don't cause
regressions without a unit test suite that is easy to run/inspect.  It may
be that the existing bsh tests do fill this need, but my cursory inspection
seems to indicate that they are integration / functionality tests, rather
than focusing on units.  

I've added junit to the build system as part of ticket #28, and if there
are no objections, I'll commit these changes tomorrow.

This added the following ant targets:

   * junit-tests: Runs the tests (everything under ${junit-test-src-dir}
that matches the pattern **/*Test.java).  This target should "just work" --
building whatever is necessary and then running the tests.
   * build-junit-tests: Builds the test source (at the moment, it just
shoves the classes into the ${build-dir})

Results are recorded to a file in `BeanShell/tests/junit-reports`, and that
directory is cleared on `ant clean`.  A summary report is also printed at
the end of the ant output.

Adapted from 
http://sourceforge.net/tracker/?func=detail&aid=2081602&group_id=4075&atid=10407
5

If two classes defined in script extend each other, and you overwrite a method 
which is called from the super constructor a NullPointerException is issued.

Example code:

{{{
public class A {
   int _id;
   public A (int id) {
      setId(id);
   }
   public void setId (int id) {
      _id = id;
   }
   public int getId() { return _id; }
}
public class B extends A {
   public B (int id) {
      super (id * 3);
   }
   public void setId (int id) {
      super.setId(id * 5);
   }
}
print(new B(1).getId());
}}}

Run the following in BSH 2.1b0 and a Java compiler and runtime:

public class Boolean15_22_2
{
  public static boolean T()
  {
    System.out.println("T");
    return true;
  }

  public static boolean F()
  {
    System.out.println("F");
    return false;
  }

  public static void main(String[] a)
  {
    System.out.println(T() | F());
    System.out.println(F() & T());
    System.out.println(T() ^ T());
  }
}

---

It should print:

T
F
true
F
T
false
T
T
false

In bsh 2.1b0 (and I assume all previous versions), it instead throws a
bsh.InterpreterError on each statement in main:

// Error: Internal Error: unimplemented binary operator                     
bsh.InterpreterError: unimplemented binary operator                         
        at bsh.Primitive.booleanBinaryOperation(Primitive.java:279)         
        at bsh.Primitive.binaryOperationImpl(Primitive.java:244)            
        at bsh.Primitive.binaryOperation(Primitive.java:224)                
        at bsh.BSHBinaryExpression.eval(BSHBinaryExpression.java:139)       
        at bsh.Interpreter.run(Interpreter.java:469)                        
        at bsh.Interpreter.main(Interpreter.java:405)                       
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)      
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.jav
a:43)
        at java.lang.reflect.Method.invoke(Method.java:616)               

        at jline.ConsoleRunner.main(ConsoleRunner.java:69)                


The problem is that the booleanBinaryOperation in Primitive.java does not
process the BIT_OR, BIT_AND, and XOR tokens (note that the first two names
are misleading, which partly explains the bug).  However, section 15.22.2
(http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.22.1)
explicitly requires all three for boolean operands.  Note that 15.23 and
15.24 explain that the only difference between '&' and '&&', and '|' and
'||', is whether the second operand is always evaluated.  

I have attached a patch that fixes the issue.  Note that the code does
eagerly evaluate, as required.  This part didn't require any modification.
 I will write a test if desired.

see
https://sourceforge.net/tracker/index.php?func=detail&aid=1950677&group_id=4075&
atid=104075

The old scrip tests inherited with the fork should be migrated to unit tests.

This will give better tool support and add some convinience.

Provide a .classpath and .project for easy integration to Eclipse

BshClassManager.loadSourceClass() tries to load *.java files.  Why?  This
isn't documented and makes no sense.  If no one objects, I will rip this out.

Making CallStack Serializable would make BeanShell much easier to use in an 
RMI/distributed environments.  As a workaround, we have to capture BeanShell 
stack traces as text and wrap them in another exception.

I'm happy to provide example code and/or patches.

See also the related bug report from the "old" BeanShell tracker:

https://sourceforge.net/tracker/index.php?
func=detail&aid=1015085&group_id=4075&atid=104075