GJL: The Generic Java Library

Transcription

1 GJL: The Generic Java Library An STL for Java Winter 1999 Semester Project Laboratoire des Méthodes de Programmation Ecole Polytechnique Fédérale de Lausanne Corine Hari February 2000

2 Table of Contents INTRODUCTION...2 MOTIVATION... 2 DOCUMENT ORGANIZATION... 3 GENERIC JAVA...4 POSSIBLE SOLUTIONS...5 STRUCTURE OF GJL...6 CONTAINERS... 6 ITERATORS... 8 FUNCTION OBJECTS ALGORITHMS PROBLEMS ENCOUNTERED AND CHANGES MADE...11 CONCLUSION...12 BIBLIOGRAPHY APPENDIX I: GJL PACKAGE APPENDIX II: FUNCTIONS OBJECTS APPENDIX III. ALGORITHMS APPENDIX IV: CHANGES MADE GJL: The Generic Java Library Corine Hari

3 Introduction C++ has STL, Ada has the Ada Generics Library, but so far no equivalent library exists for Java. The goal of this project was therefore to develop GJL, the Generic Java Library, to provide effective ways to organize data and process it. Motivation A generic library is a library containing different data structures, called containers, and algorithms that can be applied to them. The JDK does already have some ways of dealing with data structures such as Collections, but the possibilities are very limited. Only the most basic access methods are supported and the underlying structure is not really organized in any way. The aim of GJL is to offer different types of data structures, each having specific characteristics optimized. For example, DLists offer fast insertions whereas HashSets are better suited for fast object lookup. Each programmer can then choose the structure that best fits his needs and does not have to rely on a single general implementation. The main interest of GJL however lies in its set of generic algorithms. The idea behind GJL, and all generic libraries, is that many algorithms do not depend on the underlying structure of the container on which they are applied, but only on a few fundamental semantic properties, namely accessing, inserting and deleting elements. For instance, to search for an element with a specific value or to sort the elements of a container, it does not matter whether they are stored in an array or a linked list. All the algorithm needs is to be able to read the values of the elements and, in the case of a sort, to delete them and insert them elsewhere. Adding this level of abstraction between algorithms and containers drastically reduces the amount of code that has to be written. Before, a different version of an algorithm had to be written for every different container. With GJL, creating a new algorithm will mean creating only one version which can be applied on a generic container. The same way, when creating a new container it is not necessary to rewrite new versions of existing algorithms for them to work with this specific container. It is also important to note that the GJL containers and algorithms must be designed to deal with any type of element. This means that they do not have to be rewritten to work with all the different types, which also reduces the amount of code produced. GJL: The Generic Java Library Corine Hari

4 The following figure illustrates this concept: k (Sort, Shuffle, ) i (Integer, String, ) j (Array, HashMap, ) Consider a three-dimensional space, the three dimensions being data types (i), containers (j) and algorithms (k). To cover all the different possibilities, you would have to create i*j*k different pieces of code. However, as the algorithms and containers are generic, the i axis can be dropped, which reduces the number of different versions to j*k. And as we saw that algorithms work on all sorts of containers, this reduces the total number of different pieces of code to j+k. Using a generic library therefore improves software development, as reducing the amount of code reduces development time and simplifies debugging and maintenance. Since there is only one version of each algorithm, finding and fixing bugs is a lot easier. It also increases the portability of code, as there is a standard interface that all data structures should implement. This avoids having each programmer define his own specific classes which are not compatible with anyone else's. Document organization Introduction to GJ (Generic Java) the tool which made it possible to create GJL. Brief description of the possible approaches to the problem and justification of the choice of adapting an existing library, JGL, to obtain GJL. Detailed description of the structure of the library. Problems encountered while porting JGL to GJL and the changes they induced. Comparison of the library produced with the goals set above, noting certain functionalities that have been left out and suggesting possible improvements. GJL: The Generic Java Library Corine Hari

5 Generic Java As mentioned in the introduction, for GJL to be effective it is important that containers and algorithms be generic so as not to have to redefine them for every type. Java does have a mechanism which allows you to do this by having all the containers contain Objects. The problem with this method is that there is no type checking possible. It is up to the programmer to keep track of what is inserted into and extracted from the containers and to make sure the types are coherent. Errors could go undetected until run-time. Moreover, this requires a lot of casts to be inserted into the code. The solution to these problems is parameterized types. With the type parameters being declared explicitly, using the library becomes much safer as type checking is now possible. Errors can be detected at compile-time rather than having to wait until run-time. Much fewer casts have to be inserted as the containers know what type of objects they contain, making the code clearer. All this while still providing the flexibility of generic types which is essential for writing GJL. Up to now this solution did not exist in the Java programming language. As in the case of STL in C++ where Stepanov had to wait for templates to be implemented to create his library, a Generic Java Library could not be efficiently written before parameterized types were added to the language. GJ (Generic Java) is a brand new extension to Java. It is implemented by translation into Java which erases type parameters and inserts the appropriate casts and bridge methods. GJ produces programs that are very similar to what would be written if generics were not available, it simply automates the process. To take full advantage of the potential of GJL, programs should be written in GJ. Using pure Java makes it impossible to parameterize the algorithms and containers and so does not make use of this interesting possibility. GJL does of course support "normal" Java code, as this is equivalent to simply considering the type of the elements to be Object. Additional information on GJ can be found in [1] and [2]. These papers, as well as the GJ compiler, are available for download at GJL: The Generic Java Library Corine Hari

6 Possible solutions After looking into the problem, two different solutions appeared for writing this Generic Java Library. One was to start from scratch, based on the successful design of the C++ STL, and the other was to adapt an existing library, JGL, created by ObjectSpace. I chose the second solution for the following reasons. JGL was created in Since then it has been in public use and currently exists as version 3.1. This leads to believe that it has been extensively tested and must be quite reliable. Starting from scratch would mean giving up all this experience. Also, JGL has probably acquired a following of users during these years. Providing an enhanced version would be more constructive than trying to create a rival one. Moreover, creating a whole new library is much too big of a task for a semester project. I could only have developed a small part of it which would have been useless on its own. So if a library already exists, why does it have to be adapted? As I said before, generic types did not exist in Java until recently. JGL was coded using the means that were available then, that is "pure" Java. This means that JGL is plagued by all the problems that were mentioned in the previous section. Adapting JGL to GJL actually consists of adding generics to the existing code. This makes for a safer, more reliable library. GJL: The Generic Java Library Corine Hari

7 Structure of GJL As mentioned before, GJL consists mainly of containers (data structures that store objects) and algorithms that work on these different containers. But there are two other types of components that have not yet been introduced: iterators and function objects. Iterators are very important in that they are a way of abstracting the access to the containers. They are used to traverse a sequence of elements. Algorithms use them to access the containers, which is consistent with the idea of keeping the algorithms as generic as possible. The figure below illustrates how iterators allow us to separate algorithms from the container implementations: Algorithm Iterator Object Container Function objects, of functors, are a way of representing "executable data". They define operations that can be executed on the elements. All these components are defined in detail below. A complete list of the files composing GJL along with a description of the package structure is given in Appendix I. Containers GJL provides eleven sorts of different containers. Each of these implement a Container interface which defines the following basic methods: add clear clone contents isempty equals remove adds an element to the container removes every element from the container returns a shallow copy of the container returns an Enumeration positioned at the start of the container returns true if the container contains no elements returns true if the contents match those of another container of the same type removes element(s) represented by Enumerations GJL: The Generic Java Library Corine Hari

8 size/maxsize start/finish tostring returns current/maximum number of elements in container returns an iterator positioned at the start/finish of the container returns a string that describes the container These methods only use basic properties of objects and so do not depend on the type of object they contain. These are the only methods that the algorithms should use to make sure they can be applied on any type of container. The containers then differ in the way their elements are arranged and if they use keys for sorting purposes. This defines two big groups of containers: sequence and associative. Sequence containers organize their elements in a strictly linear arrangement. They all provide the following methods: pushfront/pushback popfront/popback front/back at/put remove replace count indexof contains insert an item at the beginning/end remove and return the item positioned at the beginning/ end return the first/last item return/replace the item at a specified index remove a particular value replace one value with another count the number of matching elements return the index of a particular element return true if a particular element is present The performance of these methods will vary depending on the type of sequence. The programmer must choose among the following types of sequence containers for the ones that best fit his purpose: Array Deque DList SList Linear, contiguous storage; fast inserts at the end only Linear, noncontiguous storage; fast inserts at extremities Doubly linked list; fast inserts anywhere Singly linked list; fast inserts at extremities A few additional types of sequence containers are provided which are simply restricted versions of the other types. Certain operations are not allowed, which results in the simulation of a stack or queue: Stack LIFO data structure Queue FIFO data structure PriorityQueue queue that pops elements in a sorted order Associative containers are containers that provide fast retrieval of the elements based on keys. GJL has Sets, that deal with the key internally, and Maps, that allow the user to specify the key. The objects can be stored randomly or can be ordered based on the key. Duplicates can be allowed or disallowed, which gives us the functionality of multisets and multimaps of STL. This summarizes the available associative containers and their characteristics: GJL: The Generic Java Library Corine Hari

9 HashSet OrderedSet HashMap OrderedMap Stores elements by hash Stores and orders elements by hash Stores elements by key; 1-to-1 or 1-to-many mappings Stores and orders elements by key; 1-to-1 or 1-to-many mappings The following figure gives an overview of the different containers available and how they relate to each other. container sequence set map array deque dlist slist priority queue queue stack hashset ordered set hashmap ordered map Iterators In STL iterators are "a generalization of pointers that allow a programmer to work with different data structures (containers) in a uniform manner" 1. In Java the concept of pointers does not exist, but iterators do provide a way of abstracting the access to containers, making it possible to work with the different structures "in a uniform manner". Iterators are organized in five categories, each having a set of particular requirements that have to be satisfied. The two basic types of iterators are input and output iterators, which simply traverse the associated container and can read from, respectively write to, it. As those two abilities taken separately are not much use, forward iterators combine them both to produce an iterator that can traverse a container and read and/or write each element. This iterator cannot back up, however. This functionality is added to obtain a bidirectional iterator. The last type of iterator is the random access iterator. This iterator satisfies all the requirements of a bidirectional iterator, but also provides the ability to jump from any place to any other. The following figure illustrates the relationships between the different iterators: 1 Meng Lee, Alexander Stepanov : The Standard Template Library GJL: The Generic Java Library Corine Hari

10 input iterator output iterator forward iterator bidirectional iterator random-access iterator Each GJL container has an associated iterator class. Most are random access iterators, however some are limited to bidirectional, or even forward, iterators. That is because only the functions that are realizable in (amortized) constant time are defined. For example, random access in a list takes linear time, so random access is not provided. Only efficient functions are implemented. The following table shows the highest iterator category that can be used with each container: Array Deque Dlist HashMap HashSet OrderedMap OrderedSet PriorityQueue Queue Slist Stack RandomAccessIterator RandomAccessIterator BidirectionalIterator ForwardIterator ForwardIterator BidirectionalIterator BidirectionalIterator RandomAccessIterator Same as underlying sequence ForwardIterator Same as underlying sequence GJL: The Generic Java Library Corine Hari

11 Function objects Function objects are yet another essential tool for making algorithms generic. For example, there are algorithms that apply a function to each object in a container. They take a function object as parameter which specifies the function that has to be applied. The actual mechanism of traversing a container and applying the function to each element only has to be written once. There are two types of function objects: functions and predicates. Functions perform an operation on one or more arguments and return a result. This result is often reinserted into the container. Predicates return a Boolean and are generally used as the comparator for ordering elements or to trigger an action. GJL defines interfaces for unary and binary functions and predicates which simply have an execute method. Users can easily implement these interfaces to create their own function objects. A large set of standard functions and predicates is also provided in gjl.functions and gjl.predicates. See Appendix II for complete list and descriptions. Algorithms The GJL algorithms are designed to perform operations on containers. But to be kept as generic as possible they operate on iterators that specify all or part of a container. This way the algorithms can work on different types of containers, sub-ranges of containers and any object that satisfies the iterator interface. The algorithms can be divided into four categories: mutating operations, non-mutating operations, sorting and related operations and generalized numeric operations. Mutating operations include algorithms that modify the contents of the container, such as transforming, replacing, shuffling, etc. Non-mutating algorithms are those that do things like find elements or count the number of elements with a certain value, which doesn't modify the container. Sorting operations are of course sorts and related operations such as finding the minimum or maximum of a sequence. Examples of generalized numeric operations are summing the values or calculating the adjacent difference between the elements of a container. It is important to note that operations like comparisons for sorts, or even summing, are defined by a function object that can be specified by the user. A list of all the GJL algorithms with a short description of each is included in Appendix III. GJL: The Generic Java Library Corine Hari

12 Problems encountered and changes made Although the goal at first was to produce a library that would be fully backwards-compatible with JGL, some of the structures used were impossible to adapt in GJL. ObjectSpace sometimes took advantage of the fact that all elements were Objects, allowing them to reference different things depending on the dynamic context. This sort of thing is not possible with GJ which demands that types be specified at compile-time. Consequently, the implementation of GJL is sometimes a little more restrictive, but this also makes it safer. Although correct, JGL's implementation left more room for errors when using the library. Adding types detected these potentially dangerous situations which would otherwise have been more difficult to find. Adding parameterized types also helped to detect another flaw in JGL, this time in design. Here is the specific example: the Map containers implement both the Container and Dictionary (from JDK) interfaces. Both interfaces contained an elements() method which for a Container returned an Enumeration of elements (in this case key/value pairs) and for a Dictionary an Enumeration of values. In the JGL version, as both returned Objects, it was not apparent that the types were not compatible. When adding generic types however, it was obvious that this implementation was impossible and that one of the two methods had to be renamed. This led to one of the most noticeable differences between GJL and JGL: all GJL containers have a contents() method which return an Enumeration of their elements, whereas in JGL containers, this method is named elements(). From that moment on, full compatibility between GJL and JGL became impossible, so whenever little modifications could be made to improve the code, they were done even if they affected some method signatures. Some could have been avoided or worked around to be compatible with JGL, but as compatibility was not an option anymore, this was not done. A detailed list of all the changes that could affect programs written using JGL is in Appendix IV for reference. GJL: The Generic Java Library Corine Hari

13 Conclusion This library was first intended to be fully compatible with JGL. This, however, is not the case as some modifications were necessary to correct flaws in the design. The changes that have been made are minor, though, and users that are familiar with JGL would have no problem adapting to GJL. There are two parts of the JGL package that have not yet been ported to GJL. These are Adapters and Voyager objects. Adapters are used to allow native Java arrays and JDK data structures to behave like a JGL container, which allows algorithms to be applied to these structures. This was not implemented in this version of GJL, namely because of time constraints, but it could be a useful addition to make in the future. Until then this functionality can easily be replaced with GJL Arrays using the object equivalent of the primitives. The Voyager package is a version of the collection classes that can be used in a distributed fashion with ObjectSpace Voyager 1.0. This package was not considered during the course of this project, but it could be developed for a future version of GJL. What was produced in the course of this project is a safe version of the core functionalities of a Generic Java Library. Its modular design makes it easily extendable to incorporate new data structures, algorithms and function objects. However a very complete set of these is already provided. This project also demonstrated the usefulness of adding parameterized types to the Java programming language. While offering all the flexibility needed if properly used, GJ restricts programming styles that could lead to unsafe situations. GJL: The Generic Java Library Corine Hari

14 Bibliography [1] Gilad Bracha, Martin Odersky, David Stoutamire, PhilipWadler GJ: Extending the Java programming language with type parameters August [2] Gilad Bracha, Martin Odersky, David Stoutamire, Philip Wadler GJ Specification May 1998 [3] Philip Wadler GJ: A Generic Java Dr. Dobb's Journal February 2000 [4] Johannes Weidl The Standard Template Library Tutorial April 1996 [5] Jak Kirman A modest STL tutorial January 1998 [6] ObjectSpace JGL Documentation; GJL: The Generic Java Library Corine Hari

15 Appendix I: GJL package files gjl package: Containers Array.java Container.java DList.java Deque.java HashMap.java HashSet.java Map.java OrderedMap.java OrderedSet.java PriorityQueue.java Queue.java SList.java Sequence.java Set.java Stack.java Iterators ArrayIterator.java BidirectionalIterator.java DListIterator.java DequeIterator.java ForwardIterator.java HashMapIterator.java HashSetIterator.java InputIterator.java OrderedMapIterator.java OrderedSetIterator.java OutputIterator.java RandomAccessIterator.java SListIterator.java Function Objects BinaryFunction.java BinaryPredicate.java UnaryFunction.java UnaryPredicate.java Auxiliary Classes InvalidOperationException.java Opaque.java Pair.java PairIteratorFirst.java PairIteratorSecond.java Range.java Tree.java TreePair.java gjl.algorithms package Applying.java Comparing.java Copying.java Counting.java Filling.java Filtering.java Finding.java Hashing.java Heap.java MinMax.java OrderedSetOperations.java Permuting.java Predicates.java Printing.java Removing.java Replacing.java Reversing.java Rotating.java SetOperations.java Shuffling.java Sorting.java Swapping.java Transforming.java GJL: The Generic Java Library Corine Hari

16 gjl.functions package BinaryCompose.java BinaryPredicateFunction.java BindFirst.java BindSecond.java ConstantFunction.java DividesNumber.java Hash.java IdentityFunction.java LengthString.java MinusNumber.java ModulusNumber.java NegateNumber.java NumberHelper.java PlusNumber.java PlusString.java Print.java SelectFirst.java SelectSecond.java SwappedBinaryFunction.java TimesNumber.java ToString.java UnaryCompose.java UnaryPredicateFunction.java gjl.predicates package BinaryAnd.java BinaryComposePredicate.java BinaryNot.java BinaryOr.java BinaryTern.java BindFirstPredicate.java BindSecondPredicate.java ConstantPredicate.java EqualCollationKey.java EqualCollator.java EqualNumber.java EqualString.java EqualTo.java GreaterCollationKey.java GreaterCollator.java GreaterEqualCollationKey.java GreaterEqualCollator.java GreaterEqualNumber.java GreaterEqualString.java GreaterNumber.java GreaterString.java HashComparator.java IdenticalTo.java InstanceOf.java LessCollationKey.java LessCollator.java LessEqualCollationKey.java LessEqualCollator.java LessEqualNumber.java LessEqualString.java LessNumber.java LessString.java LogicalAnd.java LogicalNot.java LogicalOr.java NegativeNumber.java NotEqualCollationKey.java NotEqualCollator.java NotEqualNumber.java NotEqualString.java NotEqualTo.java NotIdenticalTo.java NumberHelper.java PositiveNumber.java SwappedBinaryPredicate.java UnaryAnd.java UnaryComposePredicate.java UnaryNot.java UnaryOr.java UnaryTern.java gjl.util package Benchmark.java ConditionalEnumeration.java InsertIterator.java ObjectOutputStreamIterator.java OutputStreamIterator.java Randomizer.java ReverseIterator.java GJL: The Generic Java Library Corine Hari

17 Appendix II: Functions Objects Predicates x and y represent arguments to execute() P, Q, and R represent other predicate objects C represents an instance of a java.lang.class object V represents a constant value Unary Predicates BindFirstPredicate P( V, x ) BindSecondPredicate P( x, V ) ConstantPredicate V InstanceOf x instanceof C LogicalNot!x NegativeNumber x < 0 PositiveNumber x > 0 UnaryAnd P( x ) && Q( x ) UnaryComposePredicate P( Q( x ) ) UnaryNot!P( x ) UnaryOr P( x ) Q( x ) UnaryTern P( x )? Q( x ) : R( x ) Binary Predicates BinaryAnd P( x, y ) && Q( x, y ) BinaryComposePredicate P( Q( x ), R( y ) ) BinaryNot!P( x, y ) BinaryOr P( x, y ) Q( x, y ) BinaryTern P( x, y )? Q( x, y ) : R( x, y ) ConstantPredicate V EqualCollationKey x.compareto( y ) == 0 EqualCollator collator.compare( x, y ) == 0 EqualNumber x == y EqualString x.tostring().equals( y.tostring() ) EqualTo x.equals( y ) GreaterEqualCollationKey (collator.getcollationkey(x.tostring())).compare( collator.getcollationkey( y.tostring() ) ) >= 0 GreaterEqualCollator collator.compare( x.tostring(), y.tostring() ) <= 0 GreaterEqualNumber x >= y GreaterEqualString x.tostring().compareto( y.tostring() ) >= 0 GJL: The Generic Java Library Corine Hari

18 GreaterCollationKey (collator.getcollationkey(x.tostring())).compare( collator.getcollationkey( y.tostring() ) ) > 0 GreaterCollator collator.compare( x.tostring(), y.tostring() ) > 0 GreaterNumber x > y GreaterString x.tostring().compareto( y.tostring() ) > 0 HashComparator x.hashcode() < y.hashcode() IdenticalTo x == y LessEqualCollationKey collator.getcollationkey(x.tostring())).compare( collator.getcollationkey( y.tostring() ) ) <= 0 LessEqualCollator collator.compare( x.tostring(), y.tostring() ) <= 0 LessEqualNumber x <= y LessEqualString x.tostring().compareto( y.tostring() ) <= 0 LessCollationKey (collator.getcollationkey(x.tostring())).compare( collator.getcollationkey( y.tostring() ) ) < 0 LessCollator collator.compare( x.tostring(), y.tostring() ) < 0 LessNumber x < y LessString x.tostring().compareto( y.tostring() ) < 0 LogicalAnd x && y LogicalOr x y NotEqualCollationKey x.compareto( y )!= 0 NotEqualCollator collator.compare( x, y )!= 0 NotEqualNumber x!= y NotEqualString!x.toString().equals( y.tostring() ) NotEqualTo!x.equals( y ) NotIdenticalTo x!= y SwappedBinaryPredicate P( y, x ) GJL: The Generic Java Library Corine Hari

19 Functions x and y represent arguments to execute() P, Q and R represent other function objects V represents a constant value Unary Functions BindFirst P( V, x ) BindSecond P( x, V ) ConstantFunction V Hash x.hashcode() IdentityFunction x LengthString x.tostring().length() NegateNumber -x SelectFirst x.first SelectSecond x.second ToString x.tostring() UnaryCompose P( Q( x ) ) UnaryPredicateFunction P( x ) Binary Functions BinaryCompose P( Q( x ), R( y ) ) BinaryPredicateFunction P( x, y ) ConstantFunction V DividesNumber x / y MinusNumber x - y ModulusNumber x % y PlusNumber x + y PlusString x.tostring() + y.tostring() SwappedBinaryFunction P( y, x ) TimesNumber x * y GJL: The Generic Java Library Corine Hari

20 Appendix III. Algorithms All algorithms are implemented as static methods of their class. Applying foreach() inject() apply a function to every item in a range iteratively apply a binary function to every item in a range Comparing equal() check that two sequences match lexicographicalcompare() lexicographically compare two sequences median() return the median of three values mismatch() search two sequences for a mismatched item Copying copy() copybackward() Counting accumulate() adjacentdifference() count() countif() Filling fill() filln() Filtering reject() select() unique() uniquecopy() Finding adjacentfind() detect() every() find() findif() some() Heap makeheap() copy a range of items to another area copy a range of items backwards to another area sum the values in a range calculate and sum the difference between adjacent values count items in a range that match a value count items in a range that satisfy a predicate set every item in a range to a particular value set n items to a particular value return all values that do not satisfy a predicate return all values that satisfy a predicate collapse all consecutive values in a sequence copy a sequence, collapsing consecutive values locate consecutive sequence in a range return first item that satisfies a predicate return true if every item in a range satisfies a predicate locate an item in a sequence locate an item that satisfies a predicate in a range return true if at least one item in a range satisfies a predicate make a sequence into a heap GJL: The Generic Java Library Corine Hari

21 popheap() pushheap() sortheap() MinMax minelement() maxelement() Permuting nextpermutation() prevpermutation() Printing print() println() tostring() Removing remove() removecopy() removecopyif() removeif() Replacing. replace() replacecopy() replacecopyif() replaceif() Reversing reverse() reversecopy() Rotating rotate() rotatecopy() pop the top value from a heap place the last element into a heap sort a heap return the minimum item within a range return the maximum item within a range change sequence to next lexicographic permutation change sequence to previous lexicographic permutation prints a sequence to standard output prints a sequence to standard output followed by a newline returns a description of a sequence remove all matching items from a sequence copy a sequence, removing all matching items copy sequence, removing all that satisfy predicate remove items that satisfy predicate from sequence replace specified value in a sequence with another copy sequence, replacing matching values copy sequence, replacing values that satisfy predicate replace specified values that satisfy a predicate reverse the items in a sequence create a reversed copy of a sequence rotate a sequence by n positions copy a sequence, rotating it by n positions SetOperations includes() search for one sequence in another sequence setdifference() create set of elements in 1st sequence that are not in 2nd setintersection() create set of ele ments that are in both sequences setsymmetricdifference() create set of elements that not in both sequences setunion() create set of elements that are in either sequence GJL: The Generic Java Library Corine Hari

22 Shuffling randomshuffle() Sorting itersort() sort() Swapping iterswap() swapranges() Transforming collect() transform() randomize sequence using random shuffles create iterators that will traverse a container in a sorted manner without reordering the container itself sort a sequence swap the values indicated by two iterators swap two ranges of items return result of applying a function to every item in a range transform one sequence into another GJL: The Generic Java Library Corine Hari

23 Appendix IV: Changes made gjl.container.java public Enumeration<A> elements() was changed to public Enumeration<A> contents() for reasons explained in the text. This change was applied to all the containers. gjl.*mapiterator.java In JGL these iterators were designed to be able to iterate over keys, values or key/value pairs. As it was not possible in GJL to have iterators over different types, they were restricted to the key/value pairs. This caused the disappearance of the 'mode' variable. As a value for this variable was passed into most constructors, the signature of these methods have changed. gjl.orderedmap.java int remove (A key) was changed to B remove (A key) to match the Dictionary interface B add () was changed to Pair<A,B> add() to match Map interface gjl.tree.java Class was made non final to be able to extend it to TreePair gjl.functions.*number.java The 'class' variable which was used to determine what type of number the function was being passed is now useless and was removed. This affected the signature of the constructors. New classes: gjl.treepair.java A class that extends the red-black tree implementation in Tree.java to adapt it for key/value pairs. Used for OrderedMaps gjl.pairiteratorfirst.java, gjl.pairiteratorsecond.java Iterators that iterate over the first, respectively second, elements of an iterator of Pairs. gjl.predicates.constantunarypredicate.java, gjl.predicates.constantbinarypredicate.java gjl.functions.constantunaryfunction.java, gjl.functions.constantbinaryfunctions.java Replace ConstantPredicate.java and ConstantFunction.java. Classes that were removed: gjl.algos.java gjl.algorithms.predicates.java gjl.xhashcomp.java gjl.xequalto.java These classes contained copies of methods from other packages. As the methods copied are publicly accessible and having the same code duplicated makes maintenance harder, these copies were removed. GJL: The Generic Java Library Corine Hari