15 things you learn about Java for OCA exam

It is fairly controversial to take Oracle’s Java certificates. One of the very vocal opponents of them in the local Java scene is Wojciech Seliga, who claims that he noticed that people with certificates performed worse at job interviews at Spartez than those that don’t have them (around 4:15). Even with such claims, I decided that I want to pass OCJP this year as I thought that it might be a good idea to review my Java fundamentals knowledge and make sure I don’t miss anything. What surprised me a bit is that with Java 8, the certification process is different than a few years ago and now one needs to first pass an OCA exam. At first, I was a bit dismissive – come on, this is just an exam that shows you how to write for loops – but then I took an example exam and scored… 25%.

So I learned. One important thing to notice is that Oracle’s Java exams test if you can be a compiler – there are multiple cases where they aim to trick you into parsing something that won’t compile. One can be surprised how much caveats there might be and that’s where a good point is to read a good book that prepares for an exam. I read a book by Jeanne Boyarsky and Scott Selikoff and highly recommend that one. The benefit of those preparations is that I structured some of the core Java knowledge – some things I haven’t yet seen in practice (thanks to Flying Spaghetti Monster!) as they aren’t usually good code examples – but at least when I see it in some legacy project in future I won’t run away screaming. Some of them are just something that’s easy and quite obvious, yet it can surprise.

Examples below aim mostly for junior/wannabe developers, but they might be a good refresher also for a developer with some experience. You can see all examples in my Github repository.

1. Can we use a different args name in main() method?

Yes, we can! The name can be any valid Java identifier.

2. Will that code compile?

Yes. We can have only one public class in the file and the file is named just as the public class.

3. What will be the output?

The output is 1. Number variable will be first assigned 2, then 3, then 1. With 3 you can see a static block initialization.

4. That’s a legal number?

A nice, fancy way to write 1000000.000222. Usually used to separate by three numbers, like int result = 1_000_000. Underscores cannot be at the beginning, end and around dot sign.

5. What will that code print?

A trick one. We abuse the fact that assigning a variable returns the variable. The result will be Hello!. It would work that way only with boolean. I highly discourage you from doing that.

6. Which statements are valid?

Line 5 is fine. Same with line 6 – we assign a value to s1 and s2 is declared without a value. Line 7 does not compile – we cannot declare variables with two types in one statement – even if the type is actually the same. Line 8 is okay, it’s just two statements in one line. Line 9 – does not compile. We didn’t provide a type for i4. If we declared i4 somewhere above with a type, it would be fine.

7. Why doesn’t this compile?

Division of two shorts gives us an int that cannot be implicitly cast to short. We need to explicitly do the casting:

8. Does this compile?

Nope. The first line is an int because it’s outside short’s range. Second one lacks an L sign at the end and is too large to be an int. BTW, did you know that you can add plus signs before numbers? Not that it’s helpful, but you can 馃槈

9. What will that code return?

Well, it won’t return anything because it won’t compile! In Java 8, one cannot switch on long and boolean types. In Java 7, switch on String was added that also previously wasn’t possible.

10. What will be the output?

The output here is:


Note that we use a static code block for the output. The main trick is that we put default not as the last one (as you would expect) and we forgot to put a break; there.

11. What does this code output?


We use a label to break out of two for loops at once. Feels a bit like goto, but can be used only in certain cases.

12. Are these strings the same? What will be the output here?


In this case I’ll guide you to a good answer on string constant pool from StackOverflow. One more thing to notice is that this pool is an implementation of Flyweight design pattern.

13. Can we get a new dog? What will be the result of running this code?

Exception in thread "main" java.lang.UnsupportedOperationException
	at java.util.AbstractList.add(AbstractList.java:148)
	at java.util.AbstractList.add(AbstractList.java:108)
	at pl.mmkay.oca.Level13ListFromArray.main(Level13ListFromArray.java:12)

Arrays.asList creates an array-backed List implementation. In that one we cannot add or remove elements. We could only replace an element. That’s why we needed to create a new ArrayList to add a dog.

(That one is actually a real-life example, in a flat that I currently rent with my wife, we have a contract saying that we cannot have more than 2 pets at a time ;))

14. What will be the output here?


It’s good to know what Arrays.binarySearch return values are. If an element is found, it will return an element’s index. If not, it will return a negative number that is

 -1 * index - 1 

where index is what would be the index of this element if it was in the array.

Important thing here is that array must be sorted beforehand! If it’s not, the results might be quite surprising.

15. Which element will stay in the list?

The only one that will stay will be 1. There are two remove methods in List class:

remove(int index)
remove(Object o)

For the first removal, the best match was the one with index. The second one looked for the right object.

That’s all, folks!

Hope you liked the examples. Now you know a bit more on how to act like a compiler.

Spring Boot: Saving OAuth2 login data in DB using PrincipalExtractor

This post is a continuation of configuring OAuth2 login in Spring Boot. If you want to know how to configure the login itself, please take a look at the previous post.

As I mentioned previously, we want to save user login data in our database to be able to connect matches data with their users. We’re going to save only some basic data – the external id of the user from the provider to distinguish the user, her full name (that I want the user to be able to replace it with the nickname in the future), avatar and e-mail address. Let’s start with the database. As we already configured Liquibase, we are able to add a migration that will create the table in the DB:

As we have only one provider now, we could as well skip the login_type column. That would mean that if we add a new provider, we’d likely need to add this column and prepare migration that adds the value for existing records, so I decided that it’s a good idea to start with it. When we now start the application, the table is created in the database:

Next step is adding User entity class and its related Repository interface we’ll be using for DB access. As I wanted to use LocalDateTime for managing dates, but JPA doesn’t work that well with it yet, I needed to add Jsr310JpaConverters class to @Entityscan in my MatchloggerApplication class.

The last part was using PrincipalExtractor to obtain the data we want, actually save them into the database and mark that they will be used as principal data. The documentation of this class is virtually non-existent, but I found this example. I added a similar section to my WebSecurityConfiguration.java with just returning the same I received to check which data I am able to obtain.

That was the set of data provided by PrincipalExtractor. It appears that everything that I wanted to get is available here, but there is one potential issue I may come up with in future – as long as I have only one authentication provider, I know that those data come from Google, but if I have several providers and they provide different data, it might be the case that I’ll need to find out the provider based on some keys’ existence. Not the best option, but seems I need to stick with it for now (if anybody knows a better option, please let me know).

My WebSecurityConfiguration class looks like this now:

After adding the PrincipalExtractor, I am able to see that on successful login I have my first user in the database.

Let’s then modify the code that returns user data to use my new configuration:

After login, this is a current message that we see:

One note to add is that Java 8 LocalDateTime doesn’t look too nice in generated JSON response. I’ll likely convert the returned value into a timestamp in the future, depending on view layer’s needs.

Capturing and comparing entire objects with Mockito and AssertJ

Let’s say we have a project in which we have the following classes:

We don’t yet have an implementation of the Runway interface (that will be created by another team), but we would like to test if our code creates a correct Plane object and passes it to the Runway. We’ll be using Mockito to mock the Runway implementation to test only the Airport class (so, write an actual unit test). I really like AssertJ so I’ll be using that one for assertions instead of usual JUnit assertions.

Let’s start with testing if plane departs correctly:

We now know that a plane departed, but we don’t yet know if that was the right plane. Let’s try comparing to the plane we expect:

The result is a failing test – not that we wouldn’t expect that.

There are two separate instances of Plane created here. While their fields are all the same, they are different objects and Mockito’s verify method checks that. Moreover, if we wanted to check only if a specific field of passed object has an expected value, we wouldn’t have an ability to check that with Mockito’s verify. There is a class called ArgumentCaptor though that can help us. Also, AssertJ has a neat method for comparing if all fields of two objects are the same:

The dish is ready to be served, enjoy.