What About Performance?
This question is asked about almost every language, library, concept or technology when it is introduced. Sometimes the question expresses a genuine concern. Frequently however, it appears almost as a throat clearing utterance for those who want to give the illusion of some deep thought. In such cases, those asking the question are often unwilling to embrace the consequences of fully answering the question.
In the case of Jedi, there may be a very minor performance impact due to closure instantiation. However, it is likely to be lost in the noise of general object instantiation that any Java system will cause and that you as a developer will probably not even be aware is happening most of the time. In addition, if for example, a non-memory database or network IO is in use, then this performance impact will be several orders of magnitude below that caused by these things. This is much more than made up for by the clarity, simplicity and probably 'more correct' code that will result from Jedi's use.
If you are still worried about performance, I ask you to consider whether Java itself is adequate for your needs. Maybe C/C++ would be better. Failing that, how about Objective Caml. Or how about machine code? If that is still inadequate, electronics might do the trick. Maybe optics might perform just fast enough for your needs...
Many would consider the last few options listed above as going too far or maybe a little ridiculous. I consider these options perfectly reasonable given the condition that the performance yielded by them is required. I consider the rejection of them foolish and indicative of the baselessness of the original questions.
What is the Point of FunctionalPrimitives.forEach()?
The full question here is 'Does FunctionalPrimitives.forEach(java.util.Collection, Command) have any benefits over JDK 1.5's new for loop construct when we simply want to invoke something on every item in a collection?' It is questionable. The new for loop construct removes conditional logic associated with looping and therefore, although branching is implied, could reasonably be considered as representing a linear segment of code.
There is certainly truth in the notion that, in software, on the one hand we have machine code and on the other, we have different ways of thinking about programming. Sometimes a small piece of syntactic sugar such as the for loop construct can bring up interesting questions such as this one. You will have to judge for yourself the conditions under which it makes sense to use FunctionalPrimitives.forEach() instead.
Don't Jedi Annotations Encourage non-OO Code?
No. We have found that it encourages better encapsulation and abstraction because it is easier to place annotations under these conditions; logic seems to be encouraged into more appropriate places in order to have a method on which to place an annotation.
Are There Any Other Similar Projects?
Plenty. However, we wanted a genericised set of closures and utility functions which we could not find. We also wanted the annotations. We are not aware of any other projects that do anything similar to Jedi's annotations.
Are You Aware of Scala?
Yes. If you can use Scala instead of Java, do so.
Are You Aware of the Introduction of Closures in Java 1.7 / JDK7 / J7EE / Whatever It Is?
Yes. In many cases this may obviate the need for Jedi. The presence of the generated closure factories may still be useful however.
Where is JEDI used?
Jedi started life in a commercial project in a major bank in London out of a real-world need. It quickly moved to a few more projects in the bank and then to a couple of open source projects. Later it became used in a few more banks in London as developers moved around, and a few TV companies. This is what we know, but there are likely to be many more projects using it.
