Why LeftProjection.forEach and RightProjection.foreach with different capitalization?

[Christian Semrau]

Dear Jedi developers!

I'm glad that you took the time and fixed most of FindBugs' warnings.
On my system, FindBugs now has 3 warnings for jedi-core main (and lots
of warnings for test, most of which can be ignored). I consider none
of these bugs, but you may want to take actions anyway.

One warning is that LeftProjection.forEach and RightProjection.foreach
use different capitalization, which is new since SVN revision 257
(LeftProjection.foreach is now deprecated). Was that on purpose, or
simply an oversight in RightProjection?

The other two warnings are for the new Range class: It does not
declare a serialVersionUID, which is easily fixable (set it to 1L). It
has the non-serializable instance field filter, which cannot be fixed
(short of making Range non-serializable), and so the warning can be
ignored, but the fact that the Range is only serializable if its
filter is, should be noted in the JavaDoc. BTW, the internally used
AllPassFilter is non-serializable.

Regards,
Christian Semrau

[Lance Walton]

Hi Christian.

Thanks for spending all of this time on Jedi. I have applied all of the things you've suggested below.

Are you using Jedi? If you are, are you using the code generation or just the library? Tell us more :-)

Regards,

Lance

[Christian Semrau]

Hi Lance.

I used functional approaches in a 2009 customer project, with the
Guava library. Mainly map (transform in Guava) and select (filter in
Guava), but also the composite Comparator (Ordering in Guava). Having
to write a Function class for each getter method was so tedious.
That's why I investigated in the Jedi framework, and found its code
generator an appropriate tool. But Guava and Jedi use their own
Function/Functor interfaces, which means that I need to switch to Jedi
completely, or have an adapter that wraps a Jedi Functor in a Guava
Function. Therefore, I did not use Jedi back then.

This year, I am working on a new module of my company's software
product (a Flex/Java application), and am again tempted to use
functional approaches, partially because Flex provides them OOTB. In
my spare time and out of curiousity, I tested my understanding of the
Jedi code generation, by modifying it to create implementations of the
Guava Function interface. This way, I could use the Jedi code
generator with the Guava library. Of course, I did not want to change
too much, especially, I did not want to patch jedi-core. Therefore I
added in another Maven module "java-guava" an interface, also named
Functor, but in a different package, extending both Guava Function and
Jedi Functor (and Functor0 and Functor2, just extending their Jedi
counterpart). I managed to reach that goal with patching 3 jedi-
annotation classes. The main obstacle was that Function has apply()
and Functor has execute() method.

Then, I locally changed some of the newly written company code I am
working on, to see the difference "functional" makes. For the cases I
checked until now, there is little difference between Guava and Jedi,
so I might just use plain Jedi with unpatched code generation. I
showed a collegue side-by-side examples of what I named "imperative
Java" and "functional Java", and she said something like "it looks
strange, because I am not used to it. Similar to how a Java 5 for-each
loop looked strange, compared to an iterator loop." Well, she will
have to get used to it. ;-)


Regards,
Christian Semrau

[Channing Walton]

Christian, are you at ubs by any chance? There's a big flex/java project going on there too.

Channing

-~-~-~-~-~-~-~-~-
Channing Walton

m: +44 (0) 7980 294 809
t: +44 (0) 1483 799 491

web: http://www.casualmiracles.com/
twitter: http://www.twitter.com/channingwalton

[Channing Walton]

Actually, I wondered about making Jedi interoperate with other libs somehow. There are several including Hamcrest possibly.

Any thoughts?

-~-~-~-~-~-~-~-~-
Channing Walton

m: +44 (0) 7980 294 809
t: +44 (0) 1483 799 491

web: http://www.casualmiracles.com/
twitter: http://www.twitter.com/channingwalton

On 9 Apr 2011, at 23:27, Christian Semrau <goo...@chsemrau.de> wrote:

[Lance Walton]

I would be pretty easy to make the code generation produce closure factories for other libraries (It sounds like Christian has already done it for Guava).

[Christian Semrau]

On 9 Apr., 22:42, Channing Walton <channingwal...@mac.com> wrote:
> Christian, are you at ubs by any chance? There's a big flex/java project going on there too.
>
> Channing
>

No, Channing, I don't work for UBS. I work for Actano, a german
software and consulting company with focus on project management.

In the project, I decided to not use code generation, but instead
create anonymous inner classes where needed. Main reason is that code
generation does not work OOTB with Eclipse, where you still have to
add the annotation processor in the project configuration, even with
JDK 6.

In a private test project (working on Project Euler), I integrated the
annotation processor in Eclipse, and noticed that you must add all
three libraries, jedi-core, jedi-annotations, and jedi-jdk6, as
annotation processor libraries, even if the three libraries are on the
project class path, or else you suffer strange compilation errors.

On 9 Apr., 22:46, Channing Walton <channingwal...@mac.com> wrote:
> Actually, I wondered about making Jedi interoperate with other libs somehow. There are several including Hamcrest possibly.
>
> Any thoughts?
>

In that private project, I integrated Jedi, Guava and Hamcrest by
static adapter functions, named "guava" and "jedi", allowing me to use
Function as Functor (and vice versa), Predicate as Filter (and vice
versa), and Matcher as Predicate or Filter (e.g. to write the Filter
"jedi(greaterThan(4000000))"). This currently is good enough for the
needs of that little project.

Interesting would be generation of a Matcher from an annotation, with
a meaningful Matcher description in case of a mismatch.

On 9 Apr., 22:52, Lance Walton <lance.c.wal...@googlemail.com> wrote:
> I would be pretty easy to make the code generation produce closure factories for other libraries (It sounds like Christian has already done it for Guava).
>

The way I did it, I *modified* the generator to produce factories for
jedi.extensions.guava.Functor (a subinterface of Functor and
Function), instead of *adding* a generator for Guava's Function
interface. I have not looked into what is required to add other
generators.
For real flexible use, I'd prefer to have a way of generating
factories for arbitrary one-method-interfaces (like Comparator and
several Listener interfaces), or even classes-with-one-abstract-method
(like Guava's Ordering).

Christian