Projects

google-collections

The Google Collections Library 1.0 is a set of new collection types, implementations and related goodness for Java 5 and higher, brought to you by Google. It is a natural extension of the Java Collections Framework you already know and love. We are now posting release candidates for the final ... [More] 1.0 release. Until the release is final, the API is still subject to change. (However, these changes should be very minimal at this point.) Download 1.0 Release Candidate 2 nowThe library consists of: New Collection types: Multimap, Multiset, BiMap and others High-performance immutable implementations of the standard collection types, for example ImmutableSet MapMaker, a builder for concurrent hash maps with many advanced features Ordering, which can only be described as a "Comparator on stero [Less]

ReadOnlyCollections

Backported read-only collection interfaces and extensions/adapters around them

FxCop Rules collection

A collection of FxCop rules: Immutable attribute checking, Exception processing and IDisposable checks.

fine-collection

FineCollection is a package of fully object-oriented, comfort fo usage collection classes for .Net, developed in C#.

functionaljava

Functional Java is an open source library that aims to prepare the Java programming language for the inclusion of closures. It also serves as a platform for learning functional programming concepts by introducing these concepts using a familiar language. The library is intended for use in production ... [More] applications and is thoroughly tested using the technique of automated specification-based testing with ScalaCheck. Functional Java website Functional Java Examples Functional Java API Specifications Functional Java Community Download Functional Java FeaturesFirst-Class FunctionsFunctional Java provides generic interfaces and abstract classes that serve as first-class functions or closures, entirely within Java's type system (i.e. without reflection or byte-code manipulation). The library centers around the F interface, which models a function from type A to type B. Functions are written with anonymous class syntax: // Regular Style Integer timesTwo(Integer i) { return i * 2; } // Functional Style F timesTwo = new F() { public Integer f(Integer i) { return i * 2; } }First-class functions can be composed and passed as arguments to higher-order functions: // Regular Style Integer timesTwoPlusOne(Integer i) { return plusOne(timesTwo(i)); } // Functional Style F timesTwoPlusOne = compose(plusOne, timesTwo);... mapped over collections ... // Regular Style List oneUp = new ArrayList(); for (Integer i: ints) oneUp.add(plusOne(i)); // Functional Style List oneUp = ints.map(plusOne);Functions up to arity-8 are supported, allowing elimination of nested control constructs: // Regular Style Integer product = 1; for (Integer x: ints) product = x * product; List products1 = new ArrayList(); for (int x = 0; x < ints.size(); x++) { for (int y = 0; y s a lot here, so check out the API docs, download the binary or source distributions, and join the Functional Java community. [Less]

pcollections

OverviewPCollections serves as a persistent and immutable analogue of the Java Collections Framework. This includes efficient, thread-safe, generic, immutable, and persistent stacks, maps, vectors, sets, and bags, compatible with their Java Collections counterparts. Persistent and immutable ... [More] datatypes are increasingly appreciated as a simple, design-friendly, concurrency-friendly, and sometimes more time- and space-efficient alternative to mutable datatypes. Related WorkClojure also provides persistent collections in Java, but for now they are less interoperable with Java Collections, and seem more designed to be used within the Clojure language itself. Both Google Collections and Java's Collections utility class provide immutable collections but they are not persistent, that is they do not provide efficient producers, so they are not nearly as useful. See 'Persistent versus Unmodifiable' below. UsagePCollections are created using producers and static factory methods. Some example static factory methods are HashTreePSet.empty() which returns an empty PSet, while HashTreePSet.singleton(e) returns a PSet containing just the element e, and HashTreePSet.from(collection) returns a PSet containing the same elements as collection. See 'Example Code' below for an example of using producers. The same empty(), singleton(), and from() factory methods are found in each of the PCollections implementations, which currently include one concrete implementation for each abstract type: HashTreePMap provides a PMap implementation, analogous to Java's HashMap. ConsPStack provides a PStack implementation, analogous to Java's LinkedList. TreePVector provides a PVector implementation, analogous to Java's ArrayList. HashTreePSet provides a PSet implementation, analogous to Java's HashSet. HashTreePBag provides a PBag implementation, which is unordered like a set but can contain duplicate elements. PCollections are highly interoperable with Java Collections: every PCollection is a java.util.Collection, every PMap is a java.util.Map, every PSequence — including every PStack and PVector — is a java.util.List, and every PSet is a java.util.Set. PCollections uses Semantic Versioning, which establishes a strong correspondence between API changes and version numbering. Example CodeThe following gives a very simple example of using PCollections, including the static factory method HashTreePSet.empty() and the producer plus(e): import pcollections.*; public class Example { public static void main(String... args) { PSet set = HashTreePSet.empty(); set = set.plus("something"); System.out.println(set); System.out.println(set.plus("something else")); System.out.println(set); } }Running this program gives the following output: [something] [something else, something] [something] Persistent versus UnmodifiableNote that these immutable collections are very different from the immutable collections returned by Java's Collections.unmodifiableCollection() and similar methods. The difference is that Java's unmodifiable collections have no producers, whereas PCollections have very efficient producers. Thus if you have an unmodifiable Collection x and you want a new Collection x2 consisting of the elements of x in addition to some element e, you would have to do something like: Collection x2 = new HashSet(x); x2.add(e);which involves copying all of x, using linear time and space. If, on the other hand, you have a PCollection y you can simply say: Collection y2 = y.plus(e);which still leaves y untouched but generally requires little or no copying, using time and space much more efficiently. [Less]

scala-deque

A fast immutable deque in and for Scala. Right now there are two decent implementations. The Finger Tree implementation was originally implemented by Ross Judson based on the paper by Paterson/Hinze. I made it covariant and generally hacked on it a bit. It is reasonably fast, splittable and ... [More] supports lg(n) apply. I hope to specialize it to make a priority Queue, etc. The current default Deque (ie Deque.empty) is faster than the Finger Tree- at least with my tests on my machine. It also seems to be faster than scala.immutable.Queue (woot!). Currently, apply is O(N). Also in the source is an implementation of Kaplan,Tarjan,Okasaki. This is relatively slow; there may be an issue with the implemention. Or maybe not, this structure does more bookkeeping than the above two. The base structure in the literature is Deque[T]= (Buffer[T], Deque[Foo[T]], Buffer[T]). The Kaplan,Tarjan,Okasaki uses a variation with Deque[T]= (Buffer[T], Deque[Foo[T]], Buffer[T], Deque[Foo[T],Buffer[T]). The ones from the literature use pairs, triples or quadruples as Foo, my default uses a Deque as Foo. If the two buffers are lists pointed outwards and Foo is empty, the base structure looks like Scala's Queue. Surprisingly, my benchmarking shows arrays to be slower than tuple-like as a buffer. The slow access time of lists seems to be problematic. There is a small test suite using ScalaTest and ScalaCheck. This suite is growing, but still small, many codepaths are untested. [Less]

immutablej

Ever thought that final should be the default in Java? Well, you can very easily make that true with this handy javac plugin. Just follow the simple instructions below to integrate this into your build and reap the benefits of immutable by default. What does it do?It's very simple. All ... [More] variables are converted to final by default. If you want a non-final variable, you have to annotate it with @var. Here's a simple example: import org.immutablej.var; public class Foo { public static void main (String[] args) { // args = new String[] { "w00t!" }; // illegal! int foo = 1; // foo = 2; // illegal! @var int bar = 1; bar = 2; // legal // _one = 1; // illegal! _two = 2; // legal } void foo (@var int value, int constant) { value = 5; // legal // constant = 5; // illegal! } int _one = 0; @var int _two; }Note: you can put final on your variables manually if you like but it's redundant. If you define a variable as @var final type name then we're going to assume you mean that you want it final and leave it final, but we also emit a warning. Don't do that! Question to anyone who has an opinion: do you think the annotation should be javax.annotation.var instead of org.immutablej.var? This strikes me as something at least as fundamental as @Nullable, so having a semi-standard annotation may be useful. How do I use it on my project?It could hardly be simpler. Download immuter.jar and put that somewhere in your project. Add the jar to the classpath passed to javac and it will automatically be activated. Here's an excerpt from an Ant build script: Note: the immuter plugin (and the imferrer plugin below) require JDK 1.6. The compiler plugin interface changed dramatically between 1.5 and 1.6, and we use the 1.6 API. Automatically inferring @var annotationsIf you have a body of code that you want to convert to immutable by default, you're in luck! I have also written an immutability inferencer which you can run on your code and which will (with some limitations) infer which variables can be immutable and which must remain mutable, and it will automatically add @var annotations to the latter. You can run it on your code as follows. Download imferrer.jar and wire it (temporarily) into your build script as follows: The imferrer is (currently) not idempotent, so you can't run it on code that already has @var annotations. Thus you need to be sure that you do the equivalent of ant clean on your project before running the imferrer to ensure that everything gets properly processed. Also note, the imferrer overwrites source files in place so be sure you're working on a pristine version control checkout so that you can revert the changes if something goes horribly awry. You shouldn't encounter any problems, but better safe than sorry. Once you have run the imferrer, you should be able to compile your code with the immuter plugin and it will compile right out of the box. You may bump into one of the few corner cases of the inference algorithm in which case you'll see a compile error that you can easily go in and fix by adding a @var annotation to the variable that the imferrer erroneously thought was immutable, more on that below. Note: you only ever run the imferrer once on a codebase. Once you've inferrered immutability for existing code, then it's up to you to correctly mark things mutable or not when you're writing new code. The whole point of immutable by default is that your code fails to compile when you accidentally try to mutate a variable that should not be mutable (or more generally, that you realize when you are causing a variable to need mutability). If we inferred mutability all the time, then we'd magically make variables mutable without you knowing, which would undermine the whole purpose. Inference limitationsThe inference is local, so it can only infer immutability for formal method parameters, local variable declarations and private members. Public and protected members may be mutated by code outside the classfile which the imferencer cannot see, so it automatically marks all such members mutable (unless of course they have been manually marked final). The inference does not do flow analysis in a class constructor. It assumes that if a potentially immutable value is only assigned in the constructor, then you're probably initializing it for the first time and it can still be considered immutable. Thus it will not mark such members as immutable. If there is a path through your constructor that initializes a member twice, then after you run the immuter your code won't compile because that member will have been marked final and you'll need to go manually add a @var annotation. This could be fixed, but I'm lazy. All declared members of anonymous inner classes are considered local from the standpoint of immutability checking because there is no way to access them through any reference to the anonymous inner class. This is not strictly true, there is a way to reference declared members of an anonymous inner class. Did you know that you can do: new Object() { public int foo; }.foo = 5;? If you do that, the imferencer will not "see" the assignment to foo and will assume it can be made immutable. Fortunately you are a nice person and you would never do anything so crazy, so you won't run into this problem. The imferencer has to add import org.immutablej.var to your class if it adds @var annotations. This import is placed at the top of all your other imports for lack of an obvious better choice. If you have no imports it puts a blank line after your package statement and puts the import there. If you have a space between your package name and the semicolon that follows it, this process will be confused (because we're working with the AST rather than the source text, we can't see that semicolon). Inference unlimitationsThe imferencer looks for any assignments to your variables and if it doesn't see one, it allows that variable to remain immutable (yay for immutable by default). This means that variables that used to be mutable in your code will be made immutable where it does not break your program. Win! Future enhancementsFor situations where you know you can recompile the entire codebase, you could instruct the imferencer to assume that protected and public members were amenable to local analysis. This will almost certainly break your build and cause you to have to go in and manually adjust the mutability of some of your public and/or protected members. However, this might be worth the trouble because then you would be sure that everything that could be marked immutable was. Presently the imferrer doesn't remove final declarations that have been made redundant. This shouldn't be hard. It would also be easy to make the immuter emit a warning when it sees a redundant final qualifier. That way you could keep them from creeping back into your codebase. A configuration option could be provided to control where the imferencer puts the @var import. Maybe someone who is as anal about import ordering as I am will do this and send me a patch. Some people probably chafe at seeing @var rather than @Var. We could easily support both and provide an option to the imferencer to emit one or the other. Suppressing the unhandled annotation warningBecause of the way the javac Annotation Processing API works, it is not possible to tell javac that your plugin needs to see every source file (which you do by saying you handle all annotation types) and then tell it that you handled some of those annotations. As a result, you will see a warning when you compile: warning: No processor claimed any of these annotations: [org.immutablej.var]In fact, if you use any other annotations (like JUnit's @Test annotation for example), javac will start complaining that nothing is handling those annotations either. If you know that you're not using any other annotation processors, you can pass an argument to the immuting processor and tell it to go ahead and claim that it handled all annotations in all of your files. This will suppress all such warnings, which is very nice. It will also prevent any other annotation processor from getting a chance to operate on your code, so don't do it if you need to use any other annotation processors in conjunction with the immuter. Here's what that argument looks like in the Ant javac task: IDE IntegrationEclipse: Eclipse uses its own Java compiler totally different from javac and not (AFAIK) supporting javac's annotation processor interface. Thus using this will probably confuse Eclipse until a similar plugin can be written for Eclipse. Since I wrote this as a distraction from my research (which involves an APT that makes changes to javac's AST), I won't get around to doing an Eclipse version until I'm doing the same thing for my research project. If someone wants to take a crack at an Eclipse plugin before that, that would be awesome. It shouldn't be very hard. NetBeans: Since NetBeans uses javac internally, it should be possible to let it know about the immuter annotation processor and have everything work. I don't use NetBeans so I don't know if or how to do this. If anyone does get this working, let me know and I'll put instructions here. IntelliJ: I don't know what compiler IntelliJ uses under the hood, so I don't know how one would go about wiring this annotation processor in. Again, help or feedback from an IntelliJ user is most welcome. FeedbackI'd love to hear what you think about the idea, receive patches, long tirades about how I'm undermining the integrity of the Java language and balkanizing programmers, anything you like! You can send me email at the name listed in the Project owners section in the upper right, @gmail.com. [Less]

pfds

Some often used functional data structures in Scala. They are not available in Scala standard library at present. Most of them are implementations of Okasaki's Purely Functional Data Structures.

Pusca

Pure Functional Scala (Scala Compiler Plugin that enforces pureness)