I'll have to think about your question a bit, but I noticed right away your use of "float". DON'T DO IT. Use double. "float" should only be used to interface with legacy code that requires it. Today's CPUs typically handle a double in hardware whereas often floats have to be promoted to a double behind the scenes in order to perform operations. "float" is especially bad for anything financial because of its limited precision. For financial calculations BigDecimal is the preferred type, use double if you must, but never float.
Well, float could also be useful in arrays, where the size of a float array is generally half the size of the corresponding double array. For certain types of calculations it may be worthwhile to save space like that, but it's pretty rare nowadays.
For financial applications it can be nice to do everything in cents (or tenths of a cent or pesos or whatever minimal unit is required) and use an int or long. Can be faster, less memory-intensive, and above all, more readable, than BigDecimal code. Though you do have to watch out for overflow...
There was some critics about my reply being incomprehensible, so I like to give an explanation.
In your code snippet, you have
You now have only one Predicate that does the filtering. But you can use more than one Predicate to test. For instance:
What I did in my example was to put all these Predicates in a List, and have a method that processed all these Predicates. In this example I "and".ed the Predicates, but you can use "or" as well, or some other combination like
There are three kinds of actuaries: those who can count, and those who can't.
All lists have methods (actually declared in Collection) for the three bulk operations, which in Sets are called, ∩=intersection, which appears to be what you want here, ∪=union, and \=difference. You will probably find it quicker to use them than to write a Stream. You will of course have to override equals() and hashCode() correctly in your Student objects. The Collections Framework is written to depend on the correct functioning of equals() and hashCode().
The Java™ Tutorials link I gave you has five bulk operations (on the Collections interface page). It includes testing for containing lots of elements and removing everything. Note:-
1: The two code snippets are not equivalent to each other; they do different things.
2: You can't use both lines 4 and 5 in the first code block.
3: Neither version of toList() makes any guarantee about the runtime type of the List created. Links: 12.
Piet Souris wrote:. . . not leading to more error than 5M were okay. Doubles therefore.
You weren't using the figures to model money then. More like the way an engineer would use them to model the weight of the load on a bridge. If the engineer is within ±5% of the correct figures, they will be happy.
nitinram agarwal wrote:This works, however I am trying to find a solution where common attributes are not limited to a single field (say for example first and last name).
Not necessarily suggesting (a bit naive but easy to understand approach given current information), but just saying that also very similar to yours approach supporting 2 or more fields would be, just to concatenate all fields you want to check against, and then handle them in the same way as you do now.
But I see there are suggested much more sophisticated approaches than this.