How to use Equivalence.wrap() to dedupe a Set? - java

I must be missing something about Equivalence.wrap() but the following test fails for me - using guava 18.0 at the very last line only. Why? What am I doing wrong? My aim is to deduplicate equivalent objects by adding them to a set.
#Test
public void testEquivalenceWrap()
{
final Equivalence<Program2> eq = EquivalentIfIDsEven.INSTANCE;
Program2 p1 = new Program2();
p1.setId(2L);
Program2 p2 = new Program2();
p2.setId(4L);
//sanity-test equivalence impl
assertFalse(p1.equals(p2));
assertTrue(eq.equivalent(p1, p2));
assertTrue(eq.wrap(p1).equals(eq.wrap(p2)));
//dedupe in set
final Set<Equivalence.Wrapper<Program2>> set = new HashSet<>();
set.add(eq.wrap(p1));
set.add(eq.wrap(p2));
assertEquals(1, set.size()); //FAIL: size == 2
}

You'd get this behavior if your Equivalence doesn't implement hashing correctly. Without seeing more code, I can't suggest something more specific, but that's almost certainly what's happening.

If I were you, I try to use this class (example EqualsEquivalence from javadoc in Equivalent class) in you test:
static final class EquivalentIfIDsEven extends Equivalence<Program2>
implements Serializable {
static final EquivalentIfIDsEven INSTANCE = new EquivalentIfIDsEven();
#Override protected boolean doEquivalent(Program2 a, Program2 b) {
return a.equals(b);
}
#Override protected int doHash(Program2 o) {
return o.hashCode();
}
private Program2 readResolve() {
return INSTANCE;
}
private static final long serialVersionUID = 1;
}

Related

Mocking a DAO in Mockito

I'm just getting into testing of code. I have done unit tests before but haven't really isolated them. So they were more like integration test (indirectly). I want to give Mockito a try and I have added it to my Intellij IDE.
But I have no idea of how to actually implement mocking at all. There are examples on their website but I just can't wrap my head around the concept of mocking. I know that one uses mocking to isolate the unit testing to ensure that the errors are in the unit itself and not in a dependency.
I wrote the following:
#Test
public void testChangeMemberReturnsTrue() throws Exception {
Member tempMem = new Member();
tempMem.setMemberFirstName("Swagrid");
tempMem.setMemberLastName("McLovin");
tempMem.setMemberID("SM666");
SQLDUMMY.saveMember(tempMem); //Save member to dummy DB.
Member checkMem = new Member();
ArrayList<Member> memArr = SQLDUMMY.getAllMembers();
for (Member m : memArr) { // Look through all saved members
if (m.equals(tempMem)) { // If match, save to checkMem
checkMem = m;
}
}
assertTrue(tempMem.equals(checkMem)); // Make sure they are really equal.
String newfirstname = "Darius";
String newlastname = "DunkMaster";
assertTrue(memhandling.changeMember(tempMem, newfirstname, newlastname));
}
And here is the actual method:
public boolean changeMember(Member mem, String n1, String n2) {
try {
ArrayList<Member> memArr = SQLDUMMY.getAllMembers();
for (Member m : memArr) {
if (m.equals(mem)) {
m.setMemberFirstName(n1);
m.setMemberLastName(n2);
m.setMemberID(ensureUniqueID(m, m.getMemberID())); //Just a method call to another method in the same class to ensure ID uniqueness.
return true;
}
else {
return false;
}
}
}
catch (Exception e) {
System.out.println("Error4.");
}
return false;
}
I'd like to mock the SQLDUMMY (Which I created just to see if my tests would pass at all, which they do.) The SQLDUMMY class looks like this:
public class SQLDUMMY {
private static ArrayList<Member> memberList = new ArrayList<>();
private static ArrayList<Ship> shipList = new ArrayList<>();
public static ArrayList<Member> getAllMembers() {
return memberList;
}
public static void saveMember(Member m) {
memberList.add(m);
}
public static void deleteMember(Member memIn) {
memberList.remove(memIn);
}
public static void saveShip(Ship newShip) {
shipList.add(newShip);
}
public static ArrayList<Ship> getAllShips() {
return shipList;
}
public static void deleteShip(Ship s) {
shipList.remove(s);
}
}
It basically just consists of getters and add/remove for the ArrayLists that act as a contemporary DB storage.
Summary: How can I mock the SQLDUMMY class (DAO), so it is no longer a dependency for the Unit tests?
You need to read on how Mockito works.
The basic idea is that it extends you class and and overrides all methods and allows you to return what ever you want it too.
Syntax is :
SQLDummy sqlDummy = Mockito.mock(SQLDummy.class);
Mockito.when(sqlDummy.getAllShips()).thenReturn(new ArrayList< Ship >())

Generic static factory

I am getting a compilation error. I want my static method here to return a factory that creates and return Event<T> object. How can I fix this?
import com.lmax.disruptor.EventFactory;
public final class Event<T> {
private T event;
public T getEvent() {
return event;
}
public void setEvent(final T event) {
this.event = event;
}
public final static EventFactory<Event<T>> EVENT_FACTORY = new EventFactory<Event<T>>() {
public Event<T> newInstance() {
return new Event<T>();
}
};
}
Generic parameters of a class do not apply to static members.
The obvious solution is to use a method rather than a variable.
public static <U> EventFactory<Event<U>> factory() {
return new EventFactory<Event<U>>() {
public Event<U> newInstance() {
return new Event<U>();
}
};
}
The syntax is more concise in the current version of Java.
It is possible to use a the same instance of EventFactory stored in a static field, but that requires an unsafe cast.
You have:
public final class Event<T> {
...
public final static EventFactory<Event<T>> EVENT_FACTORY = ...
}
You cannot do this. T is a type that is associated with a specific instance of an Event<T>, and you cannot use it in a static context.
It's hard to give you good alternate options without knowing more about what exactly you are trying to do, as this is sort of an odd-looking factory implementation. I suppose you could do something like (put it in a method instead):
public final class Event<T> {
...
public static <U> EventFactory<Event<U>> createEventFactory () {
return new EventFactory<Event<U>>() {
public Event<U> newInstance() {
return new Event<U>();
}
};
};
}
And invoke it like:
EventFactory<Event<Integer>> factory = Event.<Integer>createEventFactory();
Or, if you don't want to be explicit (you don't really need to be, here):
EventFactory<Event<Integer>> factory = Event.createEventFactory();
Why don't you get rid of the whole static member of Event thing and either keep the factories separate, e.g.:
public final class GenericEventFactory<T> extends EventFactory<Event<T>> {
#Override public Event<T> newInstance() {
return new Event<T>();
}
}
And use, e.g., new GenericEventFactory<Integer>() where appropriate?

Mocking objects that encapsulate collections

I'm wondering how to go about checking that a method returns a container encapsulating some collection which is the aggregate of multiple other containers returned by mock objects. That is, it contains all the elements of the individual containers. I have some tests elsewhere that check the container 'works' (add/addAll/etc), so I know that works, but I'm not sure how go about with the test below 'createsRoadUsersAccordingToAllAddedCreators'.
I have a RoadUserCreationDaemon class which I call create upon which returns a RoadUserContainer according to added RoadUserCreator's. A simplified version:
public class RoadUserCreationDaemon {
private SimulationManager simulationManager;
private List<RoadUserCreator> roadUserCreators;
public RoadUserCreationDaemon(SimulationManager simulationManager) {
this.simulationManager = simulationManager;
roadUserCreators = new ArrayList<RoadUserCreator>();
}
public void addRoadUserCreator(RoadUserCreator roadUserCreator) {
roadUserCreators.add(roadUserCreator);
}
public RoadUserContainer createRoadUsers() {
RoadUserContainer roadUsers = new RoadUserContainerImpl();
for (RoadUserCreator creator : roadUserCreators) {
roadUsers.addAll(createRoadUsers(creator));
}
return roadUsers;
}
public RoadUserContainer createRoadUsers(
RoadUserCreator roadUserCreator) {
return roadUserCreator.create();
}
}
I started by writing a test (JUnit4 / JMock2.5.1) for createRoadUsers which returns a RoadUserContainer with a supplied creator. Then I started writing a test for a non-parameterised createRoadUsers to see if it returns a container with all the elements of the individual containers returned by the creators:
#RunWith(JMock.class)
public class TestRoadUserCreationDaemon {
Mockery context = new JUnit4Mockery();
private RoadUserCreationDaemon daemon;
private RoadUserCreator roadUserCreator;
private SimulationManager simulationManager;
private RoadUserContainer createdRoadUsers;
#Before
public void setUp() {
simulationManager = context.mock(SimulationManager.class);
daemon = new RoadUserCreationDaemon(simulationManager);
roadUserCreator = context.mock(RoadUserCreator.class);
createdRoadUsers = context.mock(RoadUserContainer.class);
}
#Test
public void createsRoadUsersAccordingToAllAddedCreators() throws Exception {
final RoadUserCreator anotherRoadUserCreator = context.mock(RoadUserCreator.class, "anotherRUC");
final RoadUserContainer moreCreatedRoadUsers = context.mock(RoadUserContainer.class, "moreCRU");
context.checking(new Expectations() {{
oneOf (roadUserCreator).create(); will(returnValue(createdRoadUsers));
oneOf (anotherRoadUserCreator).create(); will(returnValue(moreCreatedRoadUsers));
oneOf (createdRoadUsers).roadUsersAsList();
oneOf (moreCreatedRoadUsers).roadUsersAsList();
}});
daemon.addRoadUserCreator(roadUserCreator);
daemon.addRoadUserCreator(anotherRoadUserCreator);
daemon.createRoadUsers();
//how to easily check that the two lists are equivilant - have same items, but not the same object?
//assertEquals(createdRoadUsers, daemon.createRoadUsers() );
}
#Test
public void createsRoadUsersAccordingToCreator() throws Exception {
context.checking(new Expectations() {{
oneOf (roadUserCreator).create(); will(returnValue(createdRoadUsers));
}});
assertEquals(createdRoadUsers, daemon.createRoadUsers(roadUserCreator));
}
}
As the comment says...I'm not sure how to proceed in a non-ugly way.
The 'RoadUserContainer' interface:
public interface RoadUserContainer extends Iterable<RoadUser> {
public void add(RoadUser roadUser);
public Iterator<RoadUser> iterator();
public void addAll(RoadUserContainer createRoadUsers);
public List<RoadUser> roadUsersAsList();
public boolean equals(RoadUserContainer otherContainer);
...
}
I am new to TDD and mocking, and this is my first Java project for >6 years, so feel free to comment on ancillary aesthetics!
I would probably initially use real containers and mock the other objects. Then use hamcrest to interrogate the resulting object.
The test I would want to create would look something like this:
final RoadUser roadUser0 = context.mock(RoadUser.class, "roadUser0");
final RoadUser roadUser1 = context.mock(RoadUser.class, "roadUser1");
final RoadUser roadUser2 = context.mock(RoadUser.class, "roadUser2");
final RoadUserCreator roadUserCreator0 = context.mock(RoadUserCreator.class, "roadUserCreator0");
final RoadUserCreator roadUserCreator1 = context.mock(RoadUserCreator.class, "roadUserCreator1");
final RoadUserCreationDaemon daemon = new RoadUserCreationDaemon(null);
daemon.addRoadUserCreator(roadUserCreator0);
daemon.addRoadUserCreator(roadUserCreator1);
context.checking(new Expectations() {{
oneOf(roadUserCreator0).create(); will(returnValue(roadUsers(roadUser0, roadUser1)));
oneOf(roadUserCreator1).create(); will(returnValue(roadUsers(roadUser2)));
}});
assertThat(daemon.createRoadUsers(), contains(roadUser0, roadUser1, roadUser2));
you will need these imports from hamcrest:
import static org.hamcrest.MatcherAssert.assertThat;
import static org.hamcrest.Matchers.contains;
If order is not important you could use containsInAnyOrder instead of contains
you would also need to create the utility method "roadUsers"
public static RoadUserContainer roadUsers(final RoadUser... roadUsers)
{
return new RoadUserContainerImpl(roadUsers);
}
An alternative design would be to change the interface of the RoadUserCreationDaemon
public void createRoadUsers(final RoadUserContainer roadUsers) {
for (final RoadUserCreator roadUserCreator : roadUserCreators) {
roadUsers.addAll(roadUserCreator.create());
}
}
Then you could write the tests like this:
final RoadUserContainer roadUserContainer0 = context.mock(RoadUserContainer.class, "roadUserContainer0");
final RoadUserContainer roadUserContainer1 = context.mock(RoadUserContainer.class, "roadUserContainer1");
final RoadUserContainer resultRoadUserContainer = context.mock(RoadUserContainer.class, "resultRoadUserContainer");
final RoadUserCreator roadUserCreator0 = context.mock(RoadUserCreator.class, "roadUserCreator0");
final RoadUserCreator roadUserCreator1 = context.mock(RoadUserCreator.class, "roadUserCreator1");
final RoadUserCreationDaemon daemon = new RoadUserCreationDaemon(null);
daemon.addRoadUserCreator(roadUserCreator0);
daemon.addRoadUserCreator(roadUserCreator1);
context.checking(new Expectations() {
{
oneOf(roadUserCreator0).create();
will(returnValue(roadUserContainer0));
oneOf(roadUserCreator1).create();
will(returnValue(roadUserContainer1));
oneOf(resultRoadUserContainer).addAll(roadUserContainer0);
oneOf(resultRoadUserContainer).addAll(roadUserContainer1);
}
});
daemon.createRoadUsers(resultRoadUserContainer);
If the order of the calls to "addAll" is important you can use a jmock sequence
I think I would mock the Creator but have it return real Containers. The idea of the test is to make sure that the Daemon invoked all of the creator's create methods, right? So your test condition would look like
RoadUserContainer result = daemon.createRoadUsers();
// Check that the result contains both creator's users
Assert.assertEquals(createdRoadUsers.size() + moreCreatedRoadUsers.size(), result.size());
for (RoadUser user : createdRoadUsers)
Assert.assertTrue(result.contains(user));
for (RoadUser user : moreCreatedRoadUsers)
Assert.assertTrue(result.contains(user));

java compare to different options

I have implemented compareTo to allow me to compare my class' based on some criteria and it is working fine.
However, at some point I want to compare the class' on one thing and at another point in the code I want to compare the class based on another thing.
Is it possible to have two different implementations of compareTo and using one at some point and one at another?
In general the mechanism to do this is to implement one or more Comparators and use the appropriate one as needed.
Since your Class is "Comparable" you can use the compareTo, you can't - however - create more then one implementation of that function to be used at different points in the same Class (you have one function to override, and you can't do that twice).
You can, however, take a look at the Comparator Interface; and implementation of that interface can allow you to implement and use a different compareTo for your object.
We achieved something similar by writing a utility comparator for our class - something like this:
public class FooComparator implements Comparator<Foo> {
public static String COMPARE_FIELD1 = "COMPARE_FIELD1";
public static String COMPARE_FIELD2 = "COMPARE_FIELD2";
public static String COMPARE_FIELD3 = "COMPARE_FIELD3";
private String compareBy = COMPARE_FIELD1;
private boolean reverse = true;
public FooComparator(){}
public FooComparator(String sort){
compareBy = sort;
}
public void reverse() {
if(reverse) {reverse = false;
} else {reverse = true;}
}
public void field1Sort() {compareBy = COMPARE_FIELD1;}
public void field2Sort() {compareBy = COMPARE_FIELD2;}
public void field3Sort() {compareBy = COMPARE_FIELD3;}
public int compare(Foo foo1, Foo foo2) {
if(compareBy.equals(COMPARE_FIELD2)) {
return compareByField2(foo1, foo2);
} else if(compareBy.equals(COMPARE_FIELD3)) {
return compareByField3(foo1, foo2);
}
return compareByField1(foo1, foo2);
}
private int compareByField1(Foo foo1, Foo foo2) {
if(reverse) {return foo1.getField1().compareTo(foo2.getField1());}
return foo1.getField1().compareTo(foo2.getField1());
}
private int compareByField2(Foo foo1, Foo foo2) {
if(reverse) {return foo1.getField2().compareTo(foo2.getField2());}
return foo1.getField2().compareTo(foo2.getField2());
}
private int compareByField3(Foo foo1, Foo foo2) {
if(reverse) {return foo1.getField3().compareTo(foo2.getField3());}
return foo1.getField3().compareTo(foo2.getField3());
}
}
We then can use it like this:
List<Foo> foos = new ArrayList<Foo>();
FooComparator comparator = new FooComparator(FooComparator.COMPARE_FIELD1);
Collections.sort(foos, comparator);

Provide an iterator over the contents of two lists simultaneously?

Suppose I have this:
public class Unit<MobileSuit, Pilot> {
...
List<MobileSuit> mobileSuits;
List<Pilot> pilots;
...
}
And I would like to iterate through the pair of each in the simplest way outside of that class. How should I go about doing that? I thought about doing this:
public class Unit<MobileSuit, Pilot> {
...
Iterator<MobileSuit> iteratinMechas;
Iterator<Pilot> iteratinPeople;
class IteratorCustom<MobileSuit, Pilot> implements Iterator {
public boolean hasNext() {
return iteratinMechas.hasNext() && iteratinPeople.hasNext();
}
public void remove() {
iteratinMechas.remove();
iteratinPeople.remove();
}
public Object next() {
// /!\
}
}
public Iterator iterator() {
return new IteratorCustom<MobileSuit, Pilot>(mobileSuits, pilots);
}
}
Something along those lines.
Anyway, the problem is that I can't really return just a single object from next(), and I also can't have a Iterator take more than one type. So, any thoughts?
Also, I can't make a new class to combine MobileSuit and Pilot. I need to keep them separate, even though I'm iterating through both at a time. The reason is that there might be Mobile Suits that have no pilots, and I'm not sure how to fix that by keeping them at the same class. This class needs to be processed in other places, so I'd have to unify a interface around that and a lot of other stuff. Basically, assume MobileSuit and Pilot need to be separated.
Anyway, the problem is that I can't really return just a single object from next(), and I also can't have a Iterator take more than one type. So, any thoughts?
Obviously you are going to need a light-weight "pair" class. This is roughly analogous to the Map.Entry inner class.
Here's a rough cut at a generic solution:
public class ParallelIterator <T1, T2> implements Iterator<Pair<T1, T2>> {
public class Pair<TT1, TT2> {
private final TT1 v1;
private final TT2 v2;
private Pair(TT1 v1, TT2 v2) { this.v1 = v1; this.v2 = v2; }
...
}
private final Iterator<T1> it1;
private final Iterator<T2> it2;
public ParallelIterator(Iterator<T1> it1, Iterator<T2> it2) {
this.it1 = it1; this.it2 = it2;
}
public boolean hasNext() { return it1.hasNext() && it2.hasNext(); }
public Pair<T1, T2> next() {
return new Pair<T1, T2>(it1.next(), it2.next());
}
...
}
Note: this doesn't explicitly deal with cases where the lists have different lengths. What will happen is that extra elements at the end of the longer list will be silently ignored.
This is copied+edited from Stephen C's answer. Feel free to use:
public class Pair<T1, T2> {
private final T1 v1;
private final T2 v2;
Pair(T1 v1, T2 v2) {
this.v1 = v1;
this.v2 = v2;
}
public T1 first(){
return v1;
}
public T2 second(){
return v2;
}
}
public class ParallelIterator <T1, T2> implements Iterator<Pair<T1, T2>> {
private final Iterator<T1> it1;
private final Iterator<T2> it2;
public ParallelIterator(Iterator<T1> it1, Iterator<T2> it2) {
this.it1 = it1; this.it2 = it2;
}
#Override
public boolean hasNext() { return it1.hasNext() && it2.hasNext(); }
#Override
public Pair<T1, T2> next() {
return new Pair<T1, T2>(it1.next(), it2.next());
}
#Override
public void remove(){
it1.remove();
it2.remove();
}
}
public class IterablePair <T1, T2> implements Iterable<Pair<T1,T2>> {
private final List<T1> first;
private final List<T2> second;
public IterablePair(List<T1> first, List<T2> second) {
this.first = first;
this.second = second;
}
#Override
public Iterator<Pair<T1, T2>> iterator(){
return new ParallelIterator<T1,T2>( first.iterator(), second.iterator() );
}
}
void someFunction(){
IterablePair<X,Y> listPair = new IterablePair<X,Y>( x, y );
for( Pair<X,Y> pair : listPair ){
X x = pair.first();
...
}
}
This stops as soon as either list is out of elements, so you might want to check lists have equal size before creating an IterablePair.
Also, I can't make a new class to combine MobileSuit and Pilot.
That doesn't sound correct. It sounds like you can't replace MobileSuit and Pilot by a single class, but I don't see any reason why you can't have a single class that combines them - i.e. one which just has a getPilot() method and a getMobileSuit() method. You could use a generic Pair class for the same purpose, but a custom class would be easier to use.
On the other hand, if you want to do this sort of "zipping" operation in multiple places, it might be one solution. Alternatively, you could write a generic interface to represent the act of combining the two distinct items - which could return a SuitedPilot or whatever your combination class is.
The reason is that there might be Mobile Suits that have no pilots, and I'm not sure how to fix that by keeping them at the same class.
You can use null values, right? Which is the correct way of doing it - have each suit keep track of its pilot. If it has no pilot, then indicate that with a null value there.
But, if you're dead set on not doing that for some reason...
public class SuitAndPilot
{
public MobileSuit suit;
public Pilot pilot;
public SuitAndPilot(Suit s, Pilot p) {
suit = s;
pilot = p;
}
}
Why not have a class MannedMobileSuit as a subclass of MobileSuit that contains an instance of a pilot ? That would solve your problem by having a getPilot method.
Usually when you get such problems (needing to return two instances) it is because your Object model is not appropriate and should be changed. Keep your options open
Came across this page trying to solve this issue, and turns out that there's a library out there that's already solved it using Java 8 streams (check out the Zip function).
You can convert a list to a stream just by calling list.stream()
https://github.com/poetix/protonpack
Stream<String> streamA = Stream.of("A", "B", "C");
Stream<String> streamB = Stream.of("Apple", "Banana", "Carrot", "Doughnut");
List<String> zipped = StreamUtils.zip(streamA,
streamB,
(a, b) -> a + " is for " + b)
.collect(Collectors.toList());
assertThat(zipped,
contains("A is for Apple", "B is for Banana", "C is for Carrot"));
Basically, assume MobileSuit and Pilot need to be separated.
That's fine, but here you're trying to treat them as a unit, so structure your code that way. The suggestions above use a Pair class or Map.Entry, but it's much better to provide a clearly-named object that represents a MobileSuit with a Pilot, e.g.:
public class OccupiedSuit {
private final MobileSuit suit;
private final Pilot pilot;
public OccupiedSuit(MobileSuit suit, Pilot pilot) {
this.suit = checkNotNull(suit);
this.pilot = checkNotNull(pilot);
}
// getters, equals, hashCode, toString
// or just use #AutoValue: https://github.com/google/auto/tree/master/value
}
Then, rather than constructing a custom Iterator/Iterable, just write a helper function that zips up the two lists. For example:
public static List<OccupiedSuit> assignPilots(
Iterable<MobileSuit> suits, Iterable<Pilot> pilots) {
Iterator<MobileSuit> suitsIter = suits.iterator();
Iterator<Pilot> pilotsIter = pilots.iterator();
ImmutableList.Builder<OccupiedSuit> builder = ImmutableList.builder();
while (suitsIter.hasNext() && pilotsIter.hasNext()) {
builder.add(new OccupiedSuit(suitsIter.next(), pilotsIter.next()));
}
// Most of the existing solutions fail to enforce that the lists are the same
// size. That is a *classic* source of bugs. Always enforce your invariants!
checkArgument(!suitsIter.hasNext(),
"Unexpected extra suits: %s", ImmutableList.copyOf(suitsIter));
checkArgument(!pilotsIter.hasNext(),
"Unexpected extra pilots: %s", ImmutableList.copyOf(pilotsIter));
return builder.build();
}
Now you don't need to maintain a complex custom Iterator implementation - just rely on one that already exists!
We can also generalize assignPilots() into a generic utility that works for any two inputs, like so:
public static <L,R,M> List<M> zipLists(
BiFunction<L,R,M> factory, Iterable<L> left, Iterable<R> right) {
Iterator<L> lIter = left.iterator();
Iterator<R> rIter = right.iterator();
ImmutableList.Builder<M> builder = ImmutableList.builder();
while (lIter.hasNext() && rIter.hasNext()) {
builder.add(factory.apply(lIter.next(), rIter.next()));
}
checkArgument(!lIter.hasNext(),
"Unexpected extra left elements: %s", ImmutableList.copyOf(lIter));
checkArgument(!rIter.hasNext(),
"Unexpected extra right elements: %s", ImmutableList.copyOf(rIter));
return builder.build();
}
Which you'd then invoke like so:
List<OccupiedSuit> occupiedSuits = zipLists(OccupiedSuit::new, suits, pilots);
Example code uses Guava's Preconditions and ImmutableList - if you don't use Guava it's easy enough to inline and swap to ArrayList, but just use Guava :)
for(int i=0; i < mobileSuits.size(); i++) {
MobileSuit suit = mobileSuits.get(i);
Pilot pilot = pilots.get(i);
...
}
You could just use a Map<MobileSuit, Pilot>, where a null value mapped to a MobileSuit indicates no pilot. The Iterator could just be an Iterator<Map.Entry<MobileSuit, Pilot>> retrieved by map.entrySet().iterator().
Improving on the answer by user2224844, here is a simple version that will try no to run into an exception:
final Iterator<String> pilotIterator = pilots.iterator();
mobileSuits.forEach(m -> {
Pilot p = pilotIterator.hasNext()? pilotIterator.next():nullOrWahtever;
<Now do your work with m and p variables>
...
});
Isn't that enough ?
for(MobileSuit ms : MobileSuits) {
for(Pilot p : pilots){
//TODO
}
}

Categories

Resources