Concise update for Java SE 9

Reference arrays are bad. For this case we are after a set. Since Java SE 9 we have Set.of.

private static final Set<String> VALUES = Set.of(
    "AB","BC","CD","AE"
);

"Given String s, is there a good way of testing whether VALUES contains s?"

VALUES.contains(s)

O(1).

The right type, immutable, O(1) and concise. Beautiful.*

Original answer details

Just to clear the code up to start with. We have (corrected):

public static final String[] VALUES = new String[] {"AB","BC","CD","AE"};

This is a mutable static which FindBugs will tell you is very naughty. Do not modify statics and do not allow other code to do so also. At an absolute minimum, the field should be private:

private static final String[] VALUES = new String[] {"AB","BC","CD","AE"};

(Note, you can actually drop the new String[]; bit.)

Reference arrays are still bad and we want a set:

private static final Set<String> VALUES = new HashSet<String>(Arrays.asList(
     new String[] {"AB","BC","CD","AE"}
));

(Paranoid people, such as myself, may feel more at ease if this was wrapped in Collections.unmodifiableSet - it could then even be made public.)

(*To be a little more on brand, the collections API is predictably still missing immutable collection types and the syntax is still far too verbose, for my tastes.)

If Arrays is a static object already initialized, or declared at global scope, it may be OK, I don't know for sure. Can't call asList() on an uninitialized object, it must be allocated first.

Now I know, Arrays is a member of the utils package, can be OK. But not anything that looks fine in code, actually works also. As a matter of fact, I don't like the way in which Java calls a function. But it would be more easier and handy like this.

I don't know, if you had included the util package in your code. util, or utils ? Can be 2 different packages, this is important. You can try another way:

import java.util.*;

public static List<Integer> arraysIntersection(int[] nums1, int[] nums2){ 
   List<Integer> answer = new ArrayList<>();
   for (int i = 0; i < nums1.length; i++) {
      int u = nums1[i]; 
      for (int j = 0; j < nums2.length; j++) { 
         if (u == nums2[j]) {  
            answer.add(u); 
            break; 
         }
      } 
   }
   return answer;
} 

A break could be necessary, if the values must be added only once. ( a number can be found more times into an array ) The break was meant just for ending the inner loop. The outer loop should continue up to the end of the search.

But the same number can be find more times in the first array. Before returning the answer, the result should be checked for duplicate values. And this is another problem.

It would be more convenient to check before adding number to list. Check if the answer list already contains the number value. And then add the number to the list, if a match is not found. So this can be done more easier:

if (!answer.contains(u)) answer.add(u); 

Since you check this condition, the break is not anymore needed. But searching the list so many times, can slow down your code.

From this reason, the u value is read only once, before starting to compare with the another array. So you don't have to read manytimes the same array item, just store it in a temporary variable, u.

In another point of view, when iterating over a collection object, the current value for the current position index could change. It also depends on the basic interface implementation for this object.

If this function would have been written in C, it would have been a very serious problem, to get the value of an item in array, because the current position of the pointer changes. And here is the same, the current read value changes, excepting that we can't see all the underlying mechanism. And if I am not wrong too much, the original Java first time was based also on the C code.

Best regards, Adrian Brinas. Have a nice day.