Nabble - janino - dev

[jira] Updated: (JANINO-113) Inner class access to inherited protected violates security

2009-12-21T07:15:59Z

[ http://jira.codehaus.org/browse/JANINO-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Fowles updated JANINO-113:
-------------------------------

Assignee: Matt Fowles (was: Arno Unkrig)

> Inner class access to inherited protected violates security
> -----------------------------------------------------------
>
> Key: JANINO-113
> URL: http://jira.codehaus.org/browse/JANINO-113
> Project: Janino
> Issue Type: Bug
> Reporter: Matt Fowles
> Assignee: Matt Fowles
> Priority: Critical
> Attachments: indirect.patch
>
>
> This is similar to but different then: http://jira.codehaus.org/browse/JANINO-112
> Consider the following classes:
> {code}
> public class Parent {
> protected int var = 1;
> }
> public class Child extends Parent {
> public class Inner {
> public int get() {
> return var;
> }
> public void set() {
> var = 4;
> }
> }
> }
> public class Main {
> public static void main(String[] args) {
> Child.Inner i = new Child().new Inner();
> System.out.println("before set: " + i.get());
> i.set();
> System.out.println("after set: " + i.get());
> }
> }
> {code}
> If you run this using janinoc as your compiler and java from the command line this will print:
> before set: 1
> after set: 4
> as you would expect.
> however, if you do the equivalent thing using SimpleCompiler() the call to get will fail with an "IllegalAccessError".
> Janino is generating direct accesses to the protected variable from within the inner class, which violates the JVM's security policy. The default class loader that runs apps is unsecured but any classes loaded through URLClassLoaders (like ones created by SimpleCompiler) run through secured class loaders. As a result this will fail.
> If you look at the output of javac, you will discover that javac creates specialized accessor methods to handle this case:
> fowles@spiceweasel:~/sample/java$ javap test/Child
> Compiled from "Child.java"
> public class test.Child extends other.Parent{
> public test.Child();
> static int access$000(test.Child);
> static int access$102(test.Child, int);
> }
> Clearly, janino needs to create these accessors too, but I do not yet have a good sense of how to do this in the code base. Pointers or solutions would be most welcome as this is a blocker for my company's use of Janino until it is resolved.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[jira] Updated: (JANINO-129) incorrect max stack size

2009-12-21T07:15:59Z

[ http://jira.codehaus.org/browse/JANINO-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Fowles updated JANINO-129:
-------------------------------

Assignee: Matt Fowles (was: Arno Unkrig)

> incorrect max stack size
> ------------------------
>
> Key: JANINO-129
> URL: http://jira.codehaus.org/browse/JANINO-129
> Project: Janino
> Issue Type: Bug
> Reporter: Matt Fowles
> Assignee: Matt Fowles
> Attachments: max-stack.diff
>
>
> The constant Byte.MAX_VALUE is incorrect for max stack size which is actually 255.
> This patch introduces a constant CodeContext.MAX_STACK_SIZE for this. Do to an off by one somewhere (couldn't track it down), this constant could only be set to 254. Sadly, the test was difficult to extract from our nightly infrastructure, so you will have to take my word that we test it (heavily) here.

[jira] Updated: (JANINO-101) JCI-53: Stack overflow on cross imports in commons-jci-janino

2009-12-21T07:15:59Z

[ http://jira.codehaus.org/browse/JANINO-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Fowles updated JANINO-101:
-------------------------------

Assignee: Matt Fowles (was: Arno Unkrig)

> JCI-53: Stack overflow on cross imports in commons-jci-janino
> -------------------------------------------------------------
>
> Key: JANINO-101
> URL: http://jira.codehaus.org/browse/JANINO-101
> Project: Janino
> Issue Type: Bug
> Reporter: Arno Unkrig
> Assignee: Matt Fowles
> Priority: Critical
>
> Tracked at
> https://issues.apache.org/jira/browse/JCI-53
> , not here.

[jira] Updated: (JANINO-137) Assignment conversion not possible from type "double[]" to type "double[]"

2009-12-21T07:15:58Z

[ http://jira.codehaus.org/browse/JANINO-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Fowles updated JANINO-137:
-------------------------------

Assignee: Matt Fowles (was: Arno Unkrig)

> Assignment conversion not possible from type "double[]" to type "double[]"
> --------------------------------------------------------------------------
>
> Key: JANINO-137
> URL: http://jira.codehaus.org/browse/JANINO-137
> Project: Janino
> Issue Type: Bug
> Affects Versions: 2.5.15
> Environment: This issue has been recreated on Linux (Ubuntu) and OSX
> Reporter: Michael Ward
> Assignee: Matt Fowles
> Attachments: Calculator.java, error.txt, JANINO-137.diff, MultiThreadedIssueTest.java
>
>
> We have discovered an issue when using Janino from multiple threads. No state is shared across these threads. We are using ClassBodyEvaluator.createFastClassBodyEvaluator. As is the case with most threading issues we do NOT see this issue every time. A simple test has been attached.
> Thanks,
> Mike
> Stacktrace:
> Caused by: org.codehaus.janino.CompileException: File Calculator_33, Line 25, Column 3: Assignment conversion not possible from type "double[]" to type "double[]"
> at org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java)
> at org.codehaus.janino.UnitCompiler.assignmentConversion(UnitCompiler.java)
> at org.codehaus.janino.UnitCompiler.compile2(UnitCompiler.java)
> at org.codehaus.janino.UnitCompiler.access$1700(UnitCompiler.java)
> at org.codehaus.janino.UnitCompiler$4.visitReturnStatement(UnitCompiler.java)
> at org.codehaus.janino.Java$ReturnStatement.accept(Java.java)
> at org.codehaus.janino.UnitCompiler.compile(UnitCompiler.java)
> at org.codehaus.janino.UnitCompiler.compile2(UnitCompiler.java)
> at org.codehaus.janino.UnitCompiler.access$700(UnitCompiler.java)
> at org.codehaus.janino.UnitCompiler$4.visitBlock(UnitCompiler.java)
> at org.codehaus.janino.Java$Block.accept(Java.java)
> at org.codehaus.janino.UnitCompiler.compile(UnitCompiler.java)
> at org.codehaus.janino.UnitCompiler.compile(UnitCompiler.java)
> at org.codehaus.janino.UnitCompiler.compileDeclaredMethods(UnitCompiler.java)
> at org.codehaus.janino.UnitCompiler.compileDeclaredMethods(UnitCompiler.java)
> at org.codehaus.janino.UnitCompiler.compile2(UnitCompiler.java)
> at org.codehaus.janino.UnitCompiler.compile2(UnitCompiler.java)
> at org.codehaus.janino.UnitCompiler$3.visitPackageMemberClassDeclaration(UnitCompiler.java)
> at org.codehaus.janino.Java$PackageMemberClassDeclaration.accept(Java.java)
> at org.codehaus.janino.UnitCompiler.compile(UnitCompiler.java)
> at org.codehaus.janino.UnitCompiler.compileUnit(UnitCompiler.java)
> at org.codehaus.janino.SimpleCompiler.compileToClassLoader(SimpleCompiler.java)
> at org.codehaus.janino.ClassBodyEvaluator.compileToClass(ClassBodyEvaluator.java)
> at org.codehaus.janino.ClassBodyEvaluator.cook(ClassBodyEvaluator.java)
> at org.codehaus.janino.ClassBodyEvaluator.<init>(ClassBodyEvaluator.java)
> at org.codehaus.janino.ClassBodyEvaluator.createFastClassBodyEvaluator(ClassBodyEvaluator.java)
> at me.mward.janino.MultiThreadedIssueTest.create(MultiThreadedIssueTest.java:52)
> ... 2 more

[jira] Updated: (JANINO-125) OutOfMemory when stressing Janino

2009-12-21T07:15:58Z

[ http://jira.codehaus.org/browse/JANINO-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Fowles updated JANINO-125:
-------------------------------

Assignee: Matt Fowles (was: Arno Unkrig)

> OutOfMemory when stressing Janino
> ---------------------------------
>
> Key: JANINO-125
> URL: http://jira.codehaus.org/browse/JANINO-125
> Project: Janino
> Issue Type: Bug
> Affects Versions: 2.5.15
> Environment: Windows XP, Java 1.6, Janino 2.5.15
> Reporter: Robert Klaus
> Assignee: Matt Fowles
> Priority: Minor
> Attachments: JANINO125.zip
>
>
> I have a stress test to see, if Janino detects the 64kb limit of a method. This worked fine with Janino <= 2.5.12, but as I recently updated to 2.5.15, Janino ran out of memory. TestCase included.
> This may not be a "real" bug, but of course has an impact on the general performance of Janino.

[jira] Updated: (JANINO-139) Importing non-existent class does not cause an error

2009-12-21T07:15:58Z

[ http://jira.codehaus.org/browse/JANINO-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Fowles updated JANINO-139:
-------------------------------

Assignee: Matt Fowles (was: Arno Unkrig)

> Importing non-existent class does not cause an error
> ----------------------------------------------------
>
> Key: JANINO-139
> URL: http://jira.codehaus.org/browse/JANINO-139
> Project: Janino
> Issue Type: Bug
> Affects Versions: 2.5.15
> Environment: JDK 1.5.0_20
> Reporter: Martin McNulty
> Assignee: Matt Fowles
> Priority: Minor
> Attachments: NonExistentImportTestCase.java
>
>
> According to the JLS, "a compile-time error occurs if the named type does not exist" (http://java.sun.com/docs/books/jls/second_edition/html/packages.doc.html#26699). However, as long as the type isn't referenced in the class body it seems Janino doesn't raise an error in this case. Attached test case calls {{SimpleCompiler.cook(String)}} with a class that imports {{does.not.Exist}}. This should raise an error, but doesn't in 2.5.15.

[jira] Updated: (JANINO-131) instanceof returns true for null values, instead of false

2009-12-21T07:15:58Z

[ http://jira.codehaus.org/browse/JANINO-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Fowles updated JANINO-131:
-------------------------------

Assignee: Matt Fowles (was: Arno Unkrig)

> instanceof returns true for null values, instead of false
> ---------------------------------------------------------
>
> Key: JANINO-131
> URL: http://jira.codehaus.org/browse/JANINO-131
> Project: Janino
> Issue Type: Bug
> Affects Versions: 2.5.15
> Environment: Windows XP
> Java 1.4.x
> Java 1.6.x
> Reporter: Mario Alberto Ortegón Cabrera
> Assignee: Matt Fowles
> Priority: Critical
> Fix For: 2.5.15
>
> Attachments: instanceof.diff
>
>
> We created the following test class:
> import java.util.List;
> public class InstanceofTest {
> public static void main(String[] args) {
> boolean b = null instanceof List;
> System.out.println("null instanceof List = " + b);
> List aList = null;
> boolean c = (aList instanceof List);
> System.out.println("aList instanceof List = " + c);
> }
> }
> We compiled with janino using:
> "%JAVA_HOME%/bin/java" -cp F:\dev\lib\janino-2.5.15\lib\janino.jar org.codehaus.janino.Compiler InstanceofTest.java
> After execution we get:
> null instanceof List = true
> aList instanceof List = true
> We compiled with java using:
> "%JAVA_HOME%/bin/javac" InstanceofTest.java
> After execution
> "%JAVA_HOME%/bin/java" InstanceofTest
> we get:
> null instanceof List = false
> aList instanceof List = false
> So the behavior is clearly different

[jira] Updated: (JANINO-130) wide versions of IINC and RET are broken

2009-12-21T07:15:58Z

[ http://jira.codehaus.org/browse/JANINO-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Fowles updated JANINO-130:
-------------------------------

Assignee: Matt Fowles (was: Arno Unkrig)

> wide versions of IINC and RET are broken
> ----------------------------------------
>
> Key: JANINO-130
> URL: http://jira.codehaus.org/browse/JANINO-130
> Project: Janino
> Issue Type: Bug
> Reporter: Matt Fowles
> Assignee: Matt Fowles
> Attachments: wide.diff
>
>
> The JVM requires wide instructions for IINC or RET opcodes when there are more than 255 local variables. The attached patch implements that (including tests).

[jira] Updated: (JANINO-126) ExpressionEvaluator isn't handling NaN correctly

2009-12-21T07:15:58Z

[ http://jira.codehaus.org/browse/JANINO-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Fowles updated JANINO-126:
-------------------------------

Assignee: Matt Fowles (was: Arno Unkrig)

> ExpressionEvaluator isn't handling NaN correctly
> ------------------------------------------------
>
> Key: JANINO-126
> URL: http://jira.codehaus.org/browse/JANINO-126
> Project: Janino
> Issue Type: Bug
> Affects Versions: 2.5.12, 2.5.13, 2.5.14, 2.5.15
> Environment: Windows jdk5
> Reporter: mark zeldis
> Assignee: Matt Fowles
> Attachments: NaN.diff
>
>
> NaN is not working within the ExpressionEvaluator. All evaluations involving NaN should be false. Here is an example:
> import org.codehaus.janino.*;
> public class TestTest {
> public static void main(String args[]){
> try {
> ExpressionEvaluator advancedFilter= new ExpressionEvaluator(
> "x>5", // expression
> Boolean.class, // expressionType
> new String[]{"x"}, // parameterNames
> new Class[]{Double.class} // parameterTypes
> );
> System.err.println(advancedFilter.evaluate(new Double[]{Double.NaN}));
> System.err.println(Double.NaN>5);
> }
> catch (Exception e) {
> e.printStackTrace();
> }
> }
> }

[jira] Updated: (JANINO-133) Janino failed compiling with ClassCastException when the source code's size is too large

2009-12-21T07:15:57Z

[ http://jira.codehaus.org/browse/JANINO-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Fowles updated JANINO-133:
-------------------------------

Assignee: Matt Fowles (was: Arno Unkrig)

> Janino failed compiling with ClassCastException when the source code's size is too large
> ----------------------------------------------------------------------------------------
>
> Key: JANINO-133
> URL: http://jira.codehaus.org/browse/JANINO-133
> Project: Janino
> Issue Type: Bug
> Affects Versions: 2.5.15
> Reporter: sherry xu
> Assignee: Matt Fowles
> Fix For: 2.5.15
>
> Attachments: cleaned.zip, janino-133.patch, Source.zip
>
>
> The janino engine failed compiling a java class whose size was 9256 kb (about 140000 lines). A classCastException was thrown as shown in the stacktrace below. Similar errors were received when the source code was downsized to about 95000 lines. The java file compiled with success when it was shrunk to below 60000 lines.
> Caused by: java.lang.ClassCastException: org.codehaus.janino.util.ClassFile$ConstantUtf8Info
> at org.codehaus.janino.CodeContext.determineArgumentsSize(CodeContext.java)
> at org.codehaus.janino.CodeContext.flowAnalysis(CodeContext.java)
> at org.codehaus.janino.CodeContext.flowAnalysis(CodeContext.java)
> at org.codehaus.janino.CodeContext.flowAnalysis(CodeContext.java)
> at org.codehaus.janino.CodeContext.flowAnalysis(CodeContext.java)
> at org.codehaus.janino.CodeContext.flowAnalysis(CodeContext.java)
> at org.codehaus.janino.CodeContext.flowAnalysis(CodeContext.java)
> at org.codehaus.janino.CodeContext.flowAnalysis(CodeContext.java)
> at org.codehaus.janino.CodeContext.flowAnalysis(CodeContext.java)
> at org.codehaus.janino.CodeContext.flowAnalysis(CodeContext.java)
> at org.codehaus.janino.CodeContext.flowAnalysis(CodeContext.java)
> at org.codehaus.janino.CodeContext.flowAnalysis(CodeContext.java)
> at org.codehaus.janino.CodeContext.flowAnalysis(CodeContext.java)
> at org.codehaus.janino.CodeContext.flowAnalysis(CodeContext.java)
> at org.codehaus.janino.CodeContext.flowAnalysis(CodeContext.java)
> at org.codehaus.janino.CodeContext.flowAnalysis(CodeContext.java)
> at org.codehaus.janino.CodeContext.flowAnalysis(CodeContext.java)
> at org.codehaus.janino.CodeContext.flowAnalysis(CodeContext.java)
> at org.codehaus.janino.CodeContext.flowAnalysis(CodeContext.java)
> at org.codehaus.janino.CodeContext.flowAnalysis(CodeContext.java)
> at org.codehaus.janino.UnitCompiler.compile(UnitCompiler.java)
> at org.codehaus.janino.UnitCompiler.compileDeclaredMethods(UnitCompiler.java)
> at org.codehaus.janino.UnitCompiler.compileDeclaredMethods(UnitCompiler.java)
> at org.codehaus.janino.UnitCompiler.compile2(UnitCompiler.java)
> at org.codehaus.janino.UnitCompiler.compile2(UnitCompiler.java)
> at org.codehaus.janino.UnitCompiler$3.visitPackageMemberClassDeclaration(UnitCompiler.java)
> at org.codehaus.janino.Java$PackageMemberClassDeclaration.accept(Java.java)
> at org.codehaus.janino.UnitCompiler.compile(UnitCompiler.java)
> at org.codehaus.janino.UnitCompiler.compileUnit(UnitCompiler.java)
> at org.codehaus.janino.SimpleCompiler.compileToClassLoader(SimpleCompiler.java)
> at org.codehaus.janino.SimpleCompiler.cook(SimpleCompiler.java)
> at org.codehaus.janino.Cookable.cook(Cookable.java)
> at org.codehaus.janino.Cookable.cook(Cookable.java)
> at com.adminserver.utl.engine.janino.JaninoCompilerHelperUtl.compileClass(JaninoCompilerHelperUtl.java:87)

[jira] Updated: (JANINO-122) static field access through instance variables fails

2009-12-21T07:15:57Z

[ http://jira.codehaus.org/browse/JANINO-122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Fowles updated JANINO-122:
-------------------------------

Assignee: Matt Fowles (was: Arno Unkrig)

> static field access through instance variables fails
> ----------------------------------------------------
>
> Key: JANINO-122
> URL: http://jira.codehaus.org/browse/JANINO-122
> Project: Janino
> Issue Type: Bug
> Reporter: Matt Fowles
> Assignee: Matt Fowles
> Attachments: static-access.diff
>
>
> Static field access through instance variables fails when it should not.
> The attached patch fixes it and adds a test.

[jira] Updated: (JANINO-127) LocalVariableTable code attribute not created, giving debuggers problems with classfiles

2009-12-21T07:15:57Z

[ http://jira.codehaus.org/browse/JANINO-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Fowles updated JANINO-127:
-------------------------------

Assignee: Matt Fowles (was: Arno Unkrig)

> LocalVariableTable code attribute not created, giving debuggers problems with classfiles
> ----------------------------------------------------------------------------------------
>
> Key: JANINO-127
> URL: http://jira.codehaus.org/browse/JANINO-127
> Project: Janino
> Issue Type: New Feature
> Reporter: Hayden Schultz
> Assignee: Matt Fowles
> Priority: Critical
> Attachments: localvardiff.txt.gz
>
>
> Since the LocalVariableTable attribute isn't written to class files, we've been having problems debugging code generated by Janino.
> I've attached a diff for the code to write LocalVariableTable code attributes. The changes are fairly minor.
> Thanks,
> Hayden Schultz (I work at StreamBase, the same company as Matt Fowles)

[jira] Updated: (JANINO-136) Covariant return types for abstract methods fail to compile

2009-12-21T07:15:57Z

[ http://jira.codehaus.org/browse/JANINO-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Fowles updated JANINO-136:
-------------------------------

Assignee: Matt Fowles (was: Arno Unkrig)

> Covariant return types for abstract methods fail to compile
> -----------------------------------------------------------
>
> Key: JANINO-136
> URL: http://jira.codehaus.org/browse/JANINO-136
> Project: Janino
> Issue Type: Bug
> Reporter: Matt Fowles
> Assignee: Matt Fowles
> Attachments: covariant.diff, CovariantReturns.java
>
>
> Subclasses are allowed to refine the return type of abstract methods (i.e. provide covariant return types). Javac will compile CovariantReturns.java but janino will hork on it. The attached patch fixes the problem and adds a test for it.
> You can find a fixed version of this at http://code.google.com/p/janino-streambase/

[jira] Updated: (JANINO-128) java.lang.IllegalAccessError when trying to use function from package-protected superclass.

2009-12-21T07:15:56Z

[ http://jira.codehaus.org/browse/JANINO-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Fowles updated JANINO-128:
-------------------------------

Assignee: Matt Fowles (was: Arno Unkrig)

> java.lang.IllegalAccessError when trying to use function from package-protected superclass.
> -------------------------------------------------------------------------------------------
>
> Key: JANINO-128
> URL: http://jira.codehaus.org/browse/JANINO-128
> Project: Janino
> Issue Type: Bug
> Affects Versions: 2.5.15
> Environment: JDK 1.6 update 10, Windows XP SP3.
> Reporter: Mr Glee
> Assignee: Matt Fowles
>
> Using janino 2.5.15 (not currently unreleased as the 'affects versions' box suggests), trying to access a public member function of a superclass that is package-protected results in an IllegalAccessException.
> For example, trying to use java.lang.StringBuilder's length() method (which is defined in package-protected java.lang.AbstractStringBuilder):
> <code>
> public static final void main(String[] args)
> {
> try
> {
> ScriptEvaluator se = new ScriptEvaluator(
> "StringBuilder sb = new StringBuilder(); return sb.length();",
> Integer.class,
> new String[0],
> new Class[0]);
> Object res = se.evaluate(new Object[0]);
> System.out.println(res.toString());
> }
> catch (Exception e)
> {
> throw new RuntimeException(e);
> }
> }
> </code>
> Using this code results in the following:
> Exception in thread "main" java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> at Main.main(Main.java:23)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:90)
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.janino.ScriptEvaluator.evaluate(ScriptEvaluator.java)
> at org.codehaus.janino.ScriptEvaluator.evaluate(ScriptEvaluator.java)
> at Main.main(Main.java:18)
> ... 5 more
> Caused by: java.lang.IllegalAccessError: tried to access class java.lang.AbstractStringBuilder from class SC
> at SC.eval0(SC.java:1)
> ... 12 more
> This isssue seems to be the same (or a very similar) issue raised in JANINO-42 (http://jira.codehaus.org/browse/JANINO-42), which is marked as fixed 2.3.18.

[jira] Updated: (JANINO-90) Make use of initCause in class$, if available.

2009-12-21T07:15:56Z

[ http://jira.codehaus.org/browse/JANINO-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Fowles updated JANINO-90:
------------------------------

Assignee: Matt Fowles (was: Arno Unkrig)

> Make use of initCause in class$, if available.
> ----------------------------------------------
>
> Key: JANINO-90
> URL: http://jira.codehaus.org/browse/JANINO-90
> Project: Janino
> Issue Type: New Feature
> Reporter: Adam Heath
> Assignee: Matt Fowles
> Priority: Trivial
> Attachments: feature_use_initCause_in_class$_method.patch
>
>
> If initCause is available(java 1.4), the use that to initialize chained exceptions in class$ method.

[jira] Updated: (JANINO-132) Inaccessible methods should be ignored for method resolution

2009-12-21T07:15:56Z

[ http://jira.codehaus.org/browse/JANINO-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Fowles updated JANINO-132:
-------------------------------

Assignee: Matt Fowles (was: Arno Unkrig)

> Inaccessible methods should be ignored for method resolution
> ------------------------------------------------------------
>
> Key: JANINO-132
> URL: http://jira.codehaus.org/browse/JANINO-132
> Project: Janino
> Issue Type: Bug
> Reporter: Matt Fowles
> Assignee: Matt Fowles
> Attachments: resolution.diff
>
>
> {code:Override.java}
> public class OverridesWithDifferingVisibility {
> public static void test(Object o) { }
> private static void test(Object[] arr) { }
> }
> {code}
> {code:Test.java}
> OverridesWithDifferingVisibility.test(new Object[] { "asdf"});
> {code}
> should compile.

[jira] Updated: (JANINO-116) Need a Java.StatementList for more flexibility in generating ASTs

2009-12-21T07:15:56Z

[ http://jira.codehaus.org/browse/JANINO-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Fowles updated JANINO-116:
-------------------------------

Assignee: Matt Fowles (was: Arno Unkrig)

> Need a Java.StatementList for more flexibility in generating ASTs
> -----------------------------------------------------------------
>
> Key: JANINO-116
> URL: http://jira.codehaus.org/browse/JANINO-116
> Project: Janino
> Issue Type: New Feature
> Reporter: Matt Fowles
> Assignee: Matt Fowles
> Attachments: statement-list.patch
>
>
> StatementLists provide a way to put a place holder statement somewhere, and then fill it in later with only things that are needed. The big difference between this and a block is that it very explicitly does not introduce a new scope, so that it can be used to inject variables that will be visible.
> The attached patch includes an implementation of this request and tests for it. It also includes the fixes in:
> http://jira.codehaus.org/browse/JANINO-111
> http://jira.codehaus.org/browse/JANINO-112
> http://jira.codehaus.org/browse/JANINO-113
> http://jira.codehaus.org/browse/JANINO-115
> This flexibility is needed for the inclusion of Janino in my project. I am nearly finished integrating Janino as our backend bytecode generation system and it is currently passing our nightly test suite of over 9,000 tests with this patch.

[jira] Assigned: (JANINO-138) upload recent janino release to Maven Central repository

2009-12-21T07:01:56Z

[ http://jira.codehaus.org/browse/JANINO-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Fowles reassigned JANINO-138:
----------------------------------

Assignee: Matt Fowles (was: Arno Unkrig)

> upload recent janino release to Maven Central repository
> --------------------------------------------------------
>
> Key: JANINO-138
> URL: http://jira.codehaus.org/browse/JANINO-138
> Project: Janino
> Issue Type: Wish
> Affects Versions: 2.5.14
> Reporter: Herve Boutemy
> Assignee: Matt Fowles
> Attachments: pom.xml
>
>
> I can wite a pom.xml for you to review it.
> And if you are interested, I can help you to use Maven to deploy Janino to Maven Central more easily: if we change Janino groupId to org.codehaus.janino, we can have automatic synchronization with Maven central repository (unsing Maven to build Janino or not, that's another choice to do)

[jira] Assigned: (JANINO-31) IncompatibleClassChangeError when loading nested classes

2009-12-21T07:01:55Z

[ http://jira.codehaus.org/browse/JANINO-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Fowles reassigned JANINO-31:
---------------------------------

Assignee: Matt Fowles (was: Arno Unkrig)

> IncompatibleClassChangeError when loading nested classes
> --------------------------------------------------------
>
> Key: JANINO-31
> URL: http://jira.codehaus.org/browse/JANINO-31
> Project: Janino
> Issue Type: Bug
> Environment: BEA jrockit81sp3_142_04
> Janino 2.3.7
> Reporter: kdx
> Assignee: Matt Fowles
> Priority: Critical
> Attachments: atd.patch, ExecutableStmt.java, janinoc-incompatibleclasschangeerror-testcase.zip
>
>
> Such a class:
> public class Function_0 {
> public static class PrintX {
> public static void printX() {
> System.err.println("x");
> }
> }
> }
> when compiled by Janino and the resulting class files loaded via the ByteArrayClassLoader like this:
> ByteArrayClassLoader bacl = new ByteArrayClassLoader(classes, parent);
> Class clazz = bacl.loadClass(classNames[0]);
> System.err.println(clazz.getDeclaredClasses());
> results in a verification error on BEA's jrockit81sp3_142_04 JVM:
> java.lang.IncompatibleClassChangeError: Function_0$PrintX
> at java.lang.Class.getDeclaredClasses0(I)[Ljava.lang.Class;(Unknown Source)
> at java.lang.Class.getDeclaredClasses(I)[Ljava.lang.Class;(Unknown Source)
> at Main.main([Ljava.lang.String;)V(Main.java:45)
> And seems to work fine on Sun's j2sdk1.4.2_04:
> [Ljava.lang.Class;@206c555
> BEA's website claims that JRockit performs stricter type checks than Sun's JVM, see "Why is JRockit throwing a ClassFormatError, IncompatibleClassChangeError or other LinkageError exceptions when the Sun JVM is not?" at http://e-docs.bea.com/wljrockit/docs81/dev_faq.html
> The attached source, when compiled by Sun's j2sdk1.4.2_04, runs fine both on the Sun j2sdk1.4.2_04 and BEA jrockit81sp3_142_04 JVMs. When compiled by Janino 2.3.7, it runs fine on the Sun j2sdk1.4.2_04 JVM, but not, as said above, on BEA jrockit81sp3_142_04.
> To verify that it is only the nested classes that cause the problem, the Main.class may be overwritten with a Sun-compiled version (while keeping the Function_0*.class files Janino-compiled) and the IncompatibleClassChangeError still happens.

[jira] Assigned: (JANINO-88) JavaSourceClassLoader has a memory leak for JavaSourceIClassLoader.

2009-12-21T06:59:56Z

[ http://jira.codehaus.org/browse/JANINO-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Fowles reassigned JANINO-88:
---------------------------------

Assignee: Matt Fowles (was: Arno Unkrig)

> JavaSourceClassLoader has a memory leak for JavaSourceIClassLoader.
> -------------------------------------------------------------------
>
> Key: JANINO-88
> URL: http://jira.codehaus.org/browse/JANINO-88
> Project: Janino
> Issue Type: Bug
> Reporter: Adam Heath
> Assignee: Matt Fowles
> Attachments: fix_JavaSourceClassLoader-memleak.patch
>
>
> JavaSourceClassLoader creates a singleton JavaSourceIClassLoader in it's constructor. This is actually a cause for a memory leak in long-running server processes. The simplest fix is to create a new JavaSourceIClassLoader each time in generateByteCodes.

[jira] Assigned: (JANINO-117) UnparseVisitor does not handle Byte or Short Literals

2009-12-21T06:57:56Z

[ http://jira.codehaus.org/browse/JANINO-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Fowles reassigned JANINO-117:
----------------------------------

Assignee: Matt Fowles (was: Arno Unkrig)

> UnparseVisitor does not handle Byte or Short Literals
> -----------------------------------------------------
>
> Key: JANINO-117
> URL: http://jira.codehaus.org/browse/JANINO-117
> Project: Janino
> Issue Type: Bug
> Reporter: Matt Fowles
> Assignee: Matt Fowles
> Fix For: 2.5.15
>
> Attachments: literals.diff
>
>
> The following test will fail with a RuntimeException. While parsed java cannot create a literal Byte or Short value, it is fairly easy to create them directly from the AST, and handling them is quite simple.
> {code}
> public void testLiterals() throws Exception {
> Object[][] tests = new Object[][] {
> { new Java.Literal(null, new Short((short)1)), "((short)1)" },
> { new Java.Literal(null, new Byte((byte)1)), "((byte)1)" },
> };
> for(int i = 0; i < tests.length; ++i) {
> Atom expr = (Atom) tests[i][0];
> String expected = (String) tests[i][1];
>
> StringWriter sw = new StringWriter();
> UnparseVisitor uv = new UnparseVisitor(sw);
> expr.accept(uv);
> Assert.assertEquals(expected, sw.toString());
> }
> }
> {code}

[jira] Closed: (JANINO-91) Add support for returning tokens of whitespace

2009-12-21T06:57:55Z

[ http://jira.codehaus.org/browse/JANINO-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Fowles closed JANINO-91.
-----------------------------

Resolution: Won't Fix

Adam says that he no longer needs the feature. I would be open to such a feature in the future, but currently am focused on bring the list of outstanding Jira's under control.

> Add support for returning tokens of whitespace
> ----------------------------------------------
>
> Key: JANINO-91
> URL: http://jira.codehaus.org/browse/JANINO-91
> Project: Janino
> Issue Type: New Feature
> Reporter: Adam Heath
> Assignee: Matt Fowles
> Priority: Minor
> Attachments: feature_swallowable_whitespace_comment_tokens.patch
>
>
> I have code that filters package/import stmts from source files, then wraps the remaining code in a class definition. To keep line numbers identical after adding the class definition, I need to have comments and whitespace parsed an return to my application. The attached patch does this.

[jira] Assigned: (JANINO-91) Add support for returning tokens of whitespace

2009-12-21T06:56:10Z

[ http://jira.codehaus.org/browse/JANINO-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Fowles reassigned JANINO-91:
---------------------------------

Assignee: Matt Fowles (was: Arno Unkrig)

[jira] Closed: (JANINO-94) Static build paths in Janino

2009-12-21T06:53:55Z

[ http://jira.codehaus.org/browse/JANINO-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Fowles closed JANINO-94.
-----------------------------

Resolution: Won't Fix

Cleaning out old tickets. The issues with the current build configuration are known to be and will be tracked in the ticket JANINO-138

> Static build paths in Janino
> ----------------------------
>
> Key: JANINO-94
> URL: http://jira.codehaus.org/browse/JANINO-94
> Project: Janino
> Issue Type: Bug
> Environment: Especially UNIX-like
> Reporter: Philipp Hagemeister
> Assignee: Arno Unkrig
> Attachments: build-remove-hardcoded.patch
>
> Original Estimate: 30 minutes
> Remaining Estimate: 30 minutes
>
> The buildfile contains hardcoded paths, resulting in build failure on all UNIX and nearly all Windows systems.
> The attached patch fixes the problem.
> See also this mailing list post: http://archive.janino.codehaus.org/user/4665DD5E.3040105%40phihag.de .

[jira] Closed: (JANINO-62) Support JSR-223 when it is finalized

2009-12-21T06:51:56Z

[ http://jira.codehaus.org/browse/JANINO-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Fowles closed JANINO-62.
-----------------------------

Resolution: Fixed

Closing this issue as it hasn't been updated for 3 years and claims to be fixed.

> Support JSR-223 when it is finalized
> ------------------------------------
>
> Key: JANINO-62
> URL: http://jira.codehaus.org/browse/JANINO-62
> Project: Janino
> Issue Type: New Feature
> Reporter: Arno Unkrig
> Assignee: Arno Unkrig
> Attachments: janino-jsr-223.zip
>
>
> This issue was originally submitted on SOURCEFORGE as
> https://sourceforge.net/tracker/?func=detail&atid=592674&aid=980895&group_id=90164
> I moved it here and will look into it soon.
> Feature Requests item #980895, was opened at 2004-06-27 22:20
> Message generated for change (Comment added) made by coxcu
> You can respond by visiting:
> https://sourceforge.net/tracker/?func=detail&atid=592674&aid=980895&group_id=90164
> Please note that this message will contain a full copy of the comment thread,
> including the initial issue submission, for this request,
> not just the latest update.
> Category: None
> Group: None
> Status: Closed
> Priority: 5
> Submitted By: Curt Cox (coxcu)
> Assigned to: Nobody/Anonymous (nobody)
> Summary: Support JSR-223 when it is finalized
> Initial Comment:
> Hi,
> Please support JSR-223 when it is finalized.
> JSR-223 Scripting Pages in Java(TM) Web Applications
> http://www.jcp.org/en/jsr/detail?id=223
> Thanks,
> Curt
> ----------------------------------------------------------------------
> >>Comment By: Curt Cox (coxcu)
> Date: 2006-05-23 20:06
> Message:
> Logged In: YES
> user_id=540
> For a clarification, see:
> "Scripting Support in Mustang"
> http://www.ociweb.com/jnb/jnbFeb2006.html
> ----------------------------------------------------------------------
> Comment By: Arno Unkrig (mecki)
> Date: 2004-07-22 22:37
> Message:
> Logged In: YES
> user_id=865893
> What is this JSR about? Implementing a PHP engine in Java?
> What does it mean "JANINO supports JSR-223"?
> ----------------------------------------------------------------------
> You can respond by visiting:
> https://sourceforge.net/tracker/?func=detail&atid=592674&aid=980895&group_id=90164

[jira] Commented: (JANINO-140) LocatedException (and subclasses such as CompileException) is not serializable

2009-12-21T06:47:55Z

[ http://jira.codehaus.org/browse/JANINO-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=203663#action_203663 ]

Matt Fowles commented on JANINO-140:
------------------------------------

Thanks for the test case. I have a small back log of tickets to merge into trunk before I add this, but it will definitely make it there before too long.

> LocatedException (and subclasses such as CompileException) is not serializable
> ------------------------------------------------------------------------------
>
> Key: JANINO-140
> URL: http://jira.codehaus.org/browse/JANINO-140
> Project: Janino
> Issue Type: Bug
> Affects Versions: 2.5.15
> Reporter: Simon Nickerson
> Assignee: Matt Fowles
> Priority: Minor
> Attachments: SerializationTestCase.java
>
>
> The class {{java.lang.Exception}} in Java implements {{java.io.Serializable}}, which means that all {{Exception}} sub-classes need to be serializable. This allows exceptions to be passed via RMI.
> However, {{org.codehaus.janino.util.LocatedException}} (and subclasses, such as {{org.codehaus.janino.CompileException}}) contains an instance field of type {{org.codehaus.janino.Location}}, which is not serializable. This prevents serialization of the exception object.

[jira] Assigned: (JANINO-140) LocatedException (and subclasses such as CompileException) is not serializable

2009-12-21T06:44:55Z

[ http://jira.codehaus.org/browse/JANINO-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Fowles reassigned JANINO-140:
----------------------------------

Assignee: Matt Fowles (was: Arno Unkrig)

[jira] Updated: (JANINO-140) LocatedException (and subclasses such as CompileException) is not serializable

2009-12-21T06:07:55Z

[ http://jira.codehaus.org/browse/JANINO-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Simon Nickerson updated JANINO-140:
-----------------------------------

Attachment: SerializationTestCase.java

Failing JUnit test for this issue

> LocatedException (and subclasses such as CompileException) is not serializable
> ------------------------------------------------------------------------------
>
> Key: JANINO-140
> URL: http://jira.codehaus.org/browse/JANINO-140
> Project: Janino
> Issue Type: Bug
> Affects Versions: 2.5.15
> Reporter: Simon Nickerson
> Assignee: Arno Unkrig
> Priority: Minor
> Attachments: SerializationTestCase.java
>
>
> The class {{java.lang.Exception}} in Java implements {{java.io.Serializable}}, which means that all {{Exception}} sub-classes need to be serializable. This allows exceptions to be passed via RMI.
> However, {{org.codehaus.janino.util.LocatedException}} (and subclasses, such as {{org.codehaus.janino.CompileException}}) contains an instance field of type {{org.codehaus.janino.Location}}, which is not serializable. This prevents serialization of the exception object.

[jira] Created: (JANINO-140) LocatedException (and subclasses such as CompileException) is not serializable

2009-12-21T05:53:55Z

LocatedException (and subclasses such as CompileException) is not serializable
------------------------------------------------------------------------------

Key: JANINO-140
URL: http://jira.codehaus.org/browse/JANINO-140
Project: Janino
Issue Type: Bug
Affects Versions: 2.5.15
Reporter: Simon Nickerson
Assignee: Arno Unkrig
Priority: Minor

The class {{java.lang.Exception}} in Java implements {{java.io.Serializable}}, which means that all {{Exception}} sub-classes need to be serializable. This allows exceptions to be passed via RMI.

However, {{org.codehaus.janino.util.LocatedException}} (and subclasses, such as {{org.codehaus.janino.CompileException}}) contains an instance field of type {{org.codehaus.janino.Location}}, which is not serializable. This prevents serialization of the exception object.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Uber-despot flexing of power - addition of new developer

2009-12-13T14:54:10Z

Hi,

Just writing to let you know that "we" (Codehaus Operations) have just
granted developer level access to a new developer as per HAUS-1890.

We do not wish to Janino die due to the loss of the sole despot (Arno Unkrig).

If this proves problematic (e.g. if Arno returns), then we will
reevaluate the position at that point.

Feedback is (of course) welcome at any time.

Thanks,

Ben

--
Ben Walding :: bwalding@...
Web: http://codehaus.org/

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[jira] Created: (JANINO-139) Importing non-existent class does not cause an error

2009-12-10T07:29:55Z

Importing non-existent class does not cause an error
----------------------------------------------------

Key: JANINO-139
URL: http://jira.codehaus.org/browse/JANINO-139
Project: Janino
Issue Type: Bug
Affects Versions: 2.5.15
Environment: JDK 1.5.0_20
Reporter: Martin McNulty
Assignee: Arno Unkrig
Priority: Minor
Attachments: NonExistentImportTestCase.java

According to the JLS, "a compile-time error occurs if the named type does not exist" (http://java.sun.com/docs/books/jls/second_edition/html/packages.doc.html#26699). However, as long as the type isn't referenced in the class body it seems Janino doesn't raise an error in this case. Attached test case calls {{SimpleCompiler.cook(String)}} with a class that imports {{does.not.Exist}}. This should raise an error, but doesn't in 2.5.15.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[jira] Updated: (JANINO-138) upload recent janino release to Maven Central repository

2009-12-07T17:47:55Z

[ http://jira.codehaus.org/browse/JANINO-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Herve Boutemy updated JANINO-138:
---------------------------------

Attachment: pom.xml

ok, I see
Here is a pom.xml from what I see in Janino on Codehaus.
You can take and modify it for your fork.

> upload recent janino release to Maven Central repository
> --------------------------------------------------------
>
> Key: JANINO-138
> URL: http://jira.codehaus.org/browse/JANINO-138
> Project: Janino
> Issue Type: Wish
> Affects Versions: 2.5.14
> Reporter: Herve Boutemy
> Assignee: Arno Unkrig
> Attachments: pom.xml
>
>
> I can wite a pom.xml for you to review it.
> And if you are interested, I can help you to use Maven to deploy Janino to Maven Central more easily: if we change Janino groupId to org.codehaus.janino, we can have automatic synchronization with Maven central repository (unsing Maven to build Janino or not, that's another choice to do)

Re: Maintained Janino Releases

2009-12-01T14:51:59Z

Matt Fowles wrote:

Mark~

I completely agree with you, that is why I sent Arno (and the list) an email in February to see if he could be stirred up.

http://archive.codehaus.org/lists/org.codehaus.janino.user/msg/fbf191170902052034p7cb828eagbde767ed605b62bd@...

Then sent a follow up in June announcing the initial branch.

http://archive.codehaus.org/lists/org.codehaus.janino.user/msg/fbf191170906051054s72c7698cn57f22ee0eab80122@...

And instructed people on the initial branch to continue using Janino's Jira.

http://code.google.com/p/janino-streambase/

This is, in fact, a very paced effort on my part. Also, I should be extra clear, that if after some time, Arno does return, I will be happy to cede the project back to him. I also emailed him directly twice during the intervening time, as prior to December 2008, we had exchanged friendly personal emails.

Give 2 weeks for anyone to object, send another email one week later, then I think you are good to go.

Mark

Matt

On Tue, Dec 1, 2009 at 5:32 PM, Mark Proctor <mproctor@...> wrote:

Matt Fowles wrote:

All~

Arno has been inaccessible for about a year now, and tickets in Janino's Jira grow older without update. I have been maintaining a google code project which fixes most of the issues in the current Janino environment. The number of issues fixed and the delta from janino trunk has grown to the point, where I would like some more permanent solution. I am somewhat loathe to fork Janino, but I do not readily see any alternatives. Does anyone have opinions or suggestions?

I'd give a month for Arno to respond. Then submit your proposal to this list, twice, and wait 2 weeks to see if anyone objects. If no one objects I then think a fork is acceptable, as long as it's charter is to unwind if/when the original author comes back on the scene and merges things back in. Also make sure the fork communicates this correctly, so that people don't see it as an aggressive move, and that Arno is given the full credit for his work.

Mark

Matt

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Maintained Janino Releases

2009-12-01T14:41:32Z

Mark~

I completely agree with you, that is why I sent Arno (and the list) an email in February to see if he could be stirred up.

http://archive.codehaus.org/lists/org.codehaus.janino.user/msg/fbf191170902052034p7cb828eagbde767ed605b62bd@...

Then sent a follow up in June announcing the initial branch.

http://archive.codehaus.org/lists/org.codehaus.janino.user/msg/fbf191170906051054s72c7698cn57f22ee0eab80122@...

And instructed people on the initial branch to continue using Janino's Jira.

http://code.google.com/p/janino-streambase/

This is, in fact, a very paced effort on my part. Also, I should be extra clear, that if after some time, Arno does return, I will be happy to cede the project back to him. I also emailed him directly twice during the intervening time, as prior to December 2008, we had exchanged friendly personal emails.

Matt

On Tue, Dec 1, 2009 at 5:32 PM, Mark Proctor <mproctor@...> wrote:

Matt Fowles wrote:

All~

Arno has been inaccessible for about a year now, and tickets in Janino's Jira grow older without update. I have been maintaining a google code project which fixes most of the issues in the current Janino environment. The number of issues fixed and the delta from janino trunk has grown to the point, where I would like some more permanent solution. I am somewhat loathe to fork Janino, but I do not readily see any alternatives. Does anyone have opinions or suggestions?

I'd give a month for Arno to respond. Then submit your proposal to this list, twice, and wait 2 weeks to see if anyone objects. If no one objects I then think a fork is acceptable, as long as it's charter is to unwind if/when the original author comes back on the scene and merges things back in. Also make sure the fork communicates this correctly, so that people don't see it as an aggressive move, and that Arno is given the full credit for his work.

Mark

Matt

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Maintained Janino Releases

2009-12-01T14:32:02Z

Matt Fowles wrote:
> All~
>
> Arno has been inaccessible for about a year now, and tickets in
> Janino's Jira grow older without update. I have been maintaining a
> google code project which fixes most of the issues in the current
> Janino environment. The number of issues fixed and the delta from
> janino trunk has grown to the point, where I would like some more
> permanent solution. I am somewhat loathe to fork Janino, but I do not
> readily see any alternatives. Does anyone have opinions or suggestions?
I'd give a month for Arno to respond. Then submit your proposal to this
list, twice, and wait 2 weeks to see if anyone objects. If no one
objects I then think a fork is acceptable, as long as it's charter is to
unwind if/when the original author comes back on the scene and merges
things back in. Also make sure the fork communicates this correctly, so
that people don't see it as an aggressive move, and that Arno is given
the full credit for his work.

Mark
>
> Matt
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email