commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [JEXL] towards 2.0 release, code freeze ?
Date Tue, 28 Jul 2009 18:28:53 GMT
On 28/07/2009, Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
> On Tue, Jul 28, 2009 at 11:44 AM, sebb<sebbaz@gmail.com> wrote:
>  > On 28/07/2009, Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
>  >> On Tue, Jul 28, 2009 at 10:43 AM, Henrib<hbiestro@gmail.com> wrote:
>  >>  >
>  >>  > After JEXL-60 is reviewed & committed, it seems Jexl-2.0 could reach
code
>  >>  > freeze.
>  >>
>  >> <snip/>
>  >>
>  >>  Cool, so (as I just asked in JIRA) you're done with that patch for a bit?
:-)
>  >>
>  >>
>  >>
>  >>  > All 1.1 pending bugs would be fixed, enhancements requests & new
features
>  >>  > are in (assignment, ternary operators, UnifiedJEXL, constructor) and
>  >>  > micro-benchmarks seem to indicate better performance (for what it's worth).
>  >>  > Checkstyle is clean, code coverage improved with more tests and the
>  >>  > refactoring that took place should make the code easier to maintain.
>  >>  > Any comments - and especially some committers cycles to review JEXL-60
-
>  >>  > would be very helpfull at this late stage; the patch is "heavy" so is
in a
>  >>  > tar.gz form, instructions to apply in JEXL-60.
>  >>
>  >> <snap/>
>  >>
>  >>  Haven't looked at it, but does it also contain docs to address JEXL-43 as
well?
>  >>
>  >>  If not, thats the main remaining pending item for a v2.0 IMO.
>  >>
>  >>
>  >>
>  >>  > Some Jexl-users feedback (from API to doc and real-world perf) would
also be
>  >>  > appreciated if anyone interested has time to spare.
>  >>
>  >> <snip/>
>  >>
>  >>  Yes indeed.
>  >
>  > Now that the code requires Java 1.5, there are a lot of complaints
>  > from the Eclipse compiler about Type Safety and Raw Types. I think
>  > these should ideally be fixed.
>  >
>
> <snip/>
>
>  Agreed (ideally). Some were fixed, any others in non-generated code
>  may be looked at.
>
>
>
>  > Findbugs complains:
>  >
>  > There is an apparent infinite recursive loop in Interpreter:
>  >
>  >    public void setAttribute(Object object, Object attribute, Object value) {
>  >        setAttribute(object, attribute, null);
>  >    }
>  >
>  > Also complains: forgets to throw the Exception for:
>  >        if (node == null) {
>  >            new UnsupportedOperationException("unable to set object property, "
>  >                            + "object:" + object + ", property: " + attribute);
>  >        }
>  >

Both the above now fixed.

>  > There are some other more minor complaints, e.g. use Byte.valueOf()
>  > rather than new Byte();
>  >
>
> <snap/>
>
>  Suggest adding this to JEXL-20 -- I know it says checkstyle in the
>  issue title, but we can take that to mean static analysis for now (or
>  just commit fixes, if you want).
>
>
>
>  > Is Jexl 2.0 compliant with BSF 3.0 (JSR-223)?
>  > If not, it would be useful to add this. I can help with that.
>  >
>
> <snip/>
>
>  What does compliant mean? ISTR contributing a BSF engine based on JEXL
>  1.x (I think you were also involved, IIRC). I suspect we can do
>  similar for BSF 3.0 with JEXL 2.0. Help is always welcome.
>

It's OK - current Jexl 2.0 seems to work fine with BSF 3.0 (beta2).

>  > The JavaCC generator unforunately generates some rather unsafe code
>  > (e.g. writable public static String arrays); I don't know if it is
>  > possible to fix this.
>  >
>
> <snap/>
>
>  Very low priority, atleast for me.

The bugs seem to be inherent in the JavaCC compiler.
I think the only short-term solution would be to post-process the
generated source.
Might perhaps be worth fixing the two worst offenders.
I'll look into it.

>
>  -Rahul
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>  For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message