I don't know why I don't understand the result from this question:
1.  
2.  
3.  
4.  
Answer 2 is right  
But I don't understand why?! I prefered number 1. Because of line 15 x2=x1! We give the reference from x1 to x2 (x2=x1) and thus x1 and x2 are = equal and x2 has a reference on s2 and x1 has a reference to s1?! Why I think so, because x1.push(new Integer("100")); will also change s1! But why can the assignement x2=x1; not change s2?? I know that in the method processStacks( Stack x1, Stacks x2) are only local variables but why can the push method on x1 change s1? Do I See something wrong or do I understand something really essential not?
When you invoke the method 'processStacks( Stack x1, Stack x2)' then two copies of the references s1 and s2 are sent as arguments.
The situation is then as follows:
the references s1 and x1 reference StackA, and s2 and x2 reference StackB.
Now, with 'x2 = x1' we let x2 reference StackA, but as you see, s2 is unchaged, so still references StackB. And since nothing has beem put in StackB, you get the  printed.
Edit: and since s1 and x1 are referencing the same StackA, a change via x1 changes StackA itself. This is only possible when the referenced object, here StackA, is mutable. Try it with immutable objects, like Strings instead of Stacks, and see the difference!
Mike Gualeni wrote:. . . the result from this question: . . .
Is that an old question bank? Nobody uses new Integer(...) any more. We would simply say s1.push(100) and let the int undergo boxing conversion.
Maybe another way to look at what Piet has told you: the assignment in line 15 only has effect inside the method it appears in. It has no effect in lines 9‑10. Look up pass by value and pass by reference, remembering that Java® only supports pass by value.
Many thanks for your explanation.
I brought the mock exam quesions on 9. Septemter 2019 also I could think this are new questions. But in Java 8 we can use this still x1.push(new Integer("100")); in the IDE is everything ok! ?! When I try it with Java 12.0.2 the Integer is showed as x1.push(new Integer ("100"));
Try writing new Integer("100") or new Integer(100) with Java9+. Both will compile but will throw warning messages. Just because those constructors have been deprecated doesn't mean they won't compile.
The reason for deprecating them was that nobody used them any more. If you use those constructors you get different objects every time, which is unnecessary for an immutable type. When boxing and unboxing were introduced in 2004, the Integer#valueOf(int) method was also introduced (it is sometimes used by the boxing mechanism behind the scenes). That method guarantees to return the same object for values with a small magnitude, as required by the Java® Language Specification (=JLS). If you reuse the same object you are going to save on memory use, and also get faster execution because you are not taking time unnecessarily creating new Integer instances. Once we realised there was that improvement in performance and memory use we stopped using those constructors, even before 2017 when they were deprecated.
Being old and deprecated doesn't have anything to do here. new Integer(100) is used in this question for two reasons:
1. The question is about passing references (instead of primitives). Using autoboxing takes the focus away from the fact that an object is being added to the stack. The usage of the new keyword makes that clear.
2. Wrapper classes are on OCA 8 exam. new Integer(100) is a valid way to create a valid wrapper class object. You need to learn it (among other things about wrapper classes) anyway.
Also, not all the questions on exam are about the right way to do things. The code that you will see on the exam is not necessarily the code that you will use in real life project. You will see questions with bad practices, bad indentation, and bad logic.
So yes, it is better to use just 100 instead of new Integer(100) in real life code, but that has no relevance in this question. The question is fine as it is.