On 28/07/2009, Rahul Akolkar <rahul.akol...@gmail.com> wrote:
> On Tue, Jul 28, 2009 at 11:44 AM, sebb<seb...@gmail.com> wrote:
> > On 28/07/2009, Rahul Akolkar <rahul.akol...@gmail.com> wrote:
> >> On Tue, Jul 28, 2009 at 10:43 AM, Henrib<hbies...@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-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
