FunctionalJ is a library which makes it easy to use functional programming patterns in Java code. FunctionalJ provides the following features: * Easily represent functions as objects * Code with functional programming patterns such as mapping, filtering, and folding * Use parameter binding, also known as partial application * Write methods which accept functions as parameters and/or return functions as a result (higher-order functions) * Replace procedural code with functional code for simpler, less error-prone computations * Define functions by implementing an interface, subclassing a base class, or with a reflection mechanism, according to your preference * The reflection mechanism makes it easy to create functions that refer to existing constructors, instance methods, or static methods * No need to deal with exceptions if you don't want to. Summary of what is new in version 0.8: * Major refactoring from version 0.7 to improve the API * Now available in two versions, JDK 1.4 version and new JDK 1.5 version that uses generic types and other 1.5 features * Pluggable reflection mechanism * Two reflection mechanism implementations: one that uses the standard JDK and one that uses cglib * Improved documentation.

FunctionalJ looks very interesting and it should increase developer productivity. Oh, and it provides many benefits of the closures as well :-)

I'm not certain you can add true functional programming and list processing in Java through the introduction of an API. Even if you could, I imagine the compile to real Java constructs probably erases some of the things you do, much like erasure removes types in generics. Still, I'll download it because it's really interesting if it works well and provides a new tool for problems. I also want to see how it does the magic :-)

No magic really, just simple constructs. Anyone could write such a library, but someone does have to write it, document it, test it, etc. and I'm just hoping it will be useful to others as it is to me. I gave particularily lots of attention to the documentation, since it seems to be an area that suffers in open source projects. As for Lisp, sure, we'd all love to use every language for the best features that they offer, but that's not always possible. If you can write an enterprise web application in Lisp, and convince the manager to maintain that after you're gone, now that is what I'd call magic ;-)

Worth at least looking at for an interesting discussion. If nothing else it looks like a good reflection utility if you have parts of your program where you want more dynamic behavior. It does reduce the lines of code but at the cost of immediate clarity for Java programmers? Would be leery of using it in a corporate environment with off-the-shelf programmers but on special modules or projects it could be handy. Didn't look but I'm hoping that the library doesn't have any dependencies. ______________ George Coller DevilElephant

It does reduce the lines of code but at the cost of immediate clarity for Java programmers? Would be leery of using it in a corporate environment with off-the-shelf programmers but on special modules or projects it could be handy.

I've written two reflection mechanisms, one that is more concise and one that is more verbose, so you can choose which tradeoff you prefer. Indeed I find it useful when you need a piece of code that uses reflection. In fact, that's how I initially got started - I just wanted to be able to use reflection without doing so much song and dance that the standard JDK API requires. Eventually it turned into a "functional programming" library.

Didn't look but I'm hoping that the library doesn't have any dependencies.

No dependencies, just add the JAR file to your CLASSPATH. The only exception is that if you want to use the cglib implementation of the reflection mechanisms, of course you need the cglib JAR file in your CLASSPATH as well.

does anyone know any reason why the author didn't try something closer to Alex Winston's trick here for stronger typing? http://weblogs.java.net/blog/alexwinston/archive/2005/04/strongly_types_1.html I'm seeing that the compose function uses string method names which is icky.

I'm seeing that the compose function uses string method names which is icky.

Not sure where you're looking, but string method names are only used in the reflection mechanisms of FunctionalJ, which is separate from the core, strongly-typed part of the library. Function composition does not use string method names: http://functionalj.sourceforge.net/javadocs-0.8-jdk15/info/javelot/functionalj/Function1.html

Looks awesome. Professionally, I'm a a Java programmer with extensive academic Lisp knowledge and I was really missing a lot of functional stuff in Java. I was using a lot of functional tricks in my programs, but with no solid approach. Your library looks awesome, just judging from the Javadocs and 1.5 version also has a neat syntax. We'll be definitely trying it.

Aleksei, Thank you for your kind comments. I hope the library will be useful to you, and feel free to contact me with any questions or feedback that you may have. Best regards, Frederic

Nice though type safety imposed by generics is not really applied correctly: i.e. FunctionN length = reflect.instanceFunction(String.class, "length", new Class[0]); instanceFuntion methid returns the raw type FuntionN. SO you inherently get compile time warning. On the other hand given the fact that instanceFunction can impersonate any Java public mehod it's impossible (to me at least) to infer the parameterixed type on compile time. So what's the point of generics here?