Oracle Certified Professional Java Programmer Exam Preparation

Foreword

On December 16 of this year, I scheduled myself to take the Oracle Certified Professional Java Programmer exam. He's a Sun Certified Programmer in the past. In addition, I pushed three more of my comrades to this important step. We begin to prepare. So far it’s sluggish, but still ... And in order to systematize the knowledge I gained, I decided to periodically draw up “squeezes” - a summary of what I found, read or tested on my own skin. What you are reading at the moment is squeeze number zero. Hope this helps someone avoid buying expensive books and turning over a huge number of articles. By the way, I am preparing myself from the book Sun Certified Programmer for Java 6: Study Guide , authored by Kathy Sierra and Bert Bates. Good book, great author, easy language. Recommend.

Please note that I do not pretend to be a full description of everything that you need to know before the exam. I won’t be able to do such a job without the help of habrozhitel, simply because I have not yet passed the exam itself. Much of the following may seem primitive to some. However, as the practice of testing tests shows, the devil is in the details. We will consider this an attempt to succinctly state what is needed, from identifier naming rules to pitfalls of method overloads during inheritance and beyond. In addition, I hope to draw on something useful from the comments of people who have already gone this way. In the best case, a successfull story appears on Habré with a full description of how it all began, grew and developed. Since the idea is that everything will be published in real time, approximately every two days, then those

Content for the entire series

1. Identifiers, naming rules, modifiers for classes and interfaces
2. Modifiers for methods and fields, vararg, enum and arrays

So, let's begin

It's no secret that all Java components - whether it be classes, variables, methods or something else - must have names or, which sounds a bit more scientific, identifiers. It should be borne in mind that there are two levels of "correctness" of the identifier. Firstly, it must satisfy the requirements of the language, namely:

1. The identifier must begin with a letter, currency symbol (for example, $) or an underscore. Please note that the identifier cannot begin with a digit.
2. After the first character, the identifier may contain any combination of letters, currency symbols, connecting characters or numbers.
3. From the point of view of the compiler, there are no restrictions on the number of characters contained in the identifier.
4. You cannot use Java keywords as an identifier.
5. Identifiers in Java are case sensitive. Thus, foo and FOO are not the same thing.

Secondly, the identifier must satisfy the Java Naming Convention. It is important to understand that even if the identifier is not correct from the point of view of conventions, it can still remain valid for the compiler. For example, the compiler eats the declaration of the variable int _ $ without even being indignant. During the exmen, it is important to understand whether it is necessary to determine the syntactic validity of the identifier, or whether it is necessary to determine whether it satisfies the generally accepted standard or not. By the way, nobody will ask the entire standard from you. It is important to remember only a few facts:

1. We write capital names of the classes. The rest is Camel Case .
2. The names of methods and identifiers are written with a small letter. The rest is Camel Case.
3. We declare constants as static and final variables. Their name is written entirely in capital letters, the words are separated using the underscore.
4. To get getter’s name for a property, simply change the first letter in its name to a capital letter and append the word get to the beginning.
5. To get the setter'a name for a property, simply change the first letter in its name to a capital letter and append the word set to the beginning.
6. If the property is Boolean, then it is permissible to use the is prefix instead of get.
7. The method used to register listeners should be assembled from the word add and the type of listener. For example, addActionListener.
8. The method that is used to remove listeners should be assembled from the word remove and the type of listener. For example, removeActionListener.

Here, in fact, are all the basic rules that you must adhere to. I note, however, that the authors of the book themselves do not always follow these rules, for which they wildly apologize at the very beginning. The reasons for this, as they say, are the features of the utility used in internationalizing the exam. Certified programmers, IMHO, could fix it))

Now let's talk a bit about the rules for using files with the source code of our classes.

1. An important fact. A single file can contain only one class with the public modifier. Classes with a default identifier, however, it can be any number in it.
2. If the file contains a class with the public access modifier, then the name of this file must match the name of the public class.
3. If the class is part of the package, then the package declaration must be the first line in the file.
4. If there are imports of other packages, then they go immediately after the package declaration and before the declaration of any classes. If there is no package declaration, at the beginning of the file.
5. Files that do not contain public classes may have a name that does not match any of the classes declared in it.

In Java, there are only four access modifiers. The first three are public, private and protected. The fourth is the lack of a modifier. At the same time, only two types of modifiers can be used to declare classes and interfaces: public or default. This restriction does not apply to nested classes, thanks for the tip of webkumo , however, this is a separate topic in the exam. About them - later.

1. If the class does not have any access modifier in its declaration, then it gets the default scope. This means that only classes located with it in the same package see it. And no other.
2. If the class has a public access modifier, then it is accessible and visible to the entire Java universe.

Access modifiers you can randomly alternate with a few more keywords: final, abstract or strictfp. You can easily declare a class with modifiers, say, public final strictfp if you want. Moreover, the order is not important. You can swap something: final public strictfp. All modifiers are absolutely equal. You should not just use final and abstract at the same time. This will cause a compiler error, since you use modifiers that are mutually opposite in meaning.

1. The strictfp modifier was a revelation for me. Frankly, you are unlikely to have to use it. But to know and remember is useful. If it is applied to a class, it ensures that all operations on floating-point numbers comply with the IEEE 754. standard. As it turned out, it is used to obtain a predictable result, since different processors can process floating-point numbers differently.
2. The final modifier forbids inheritance from the class. It is often used for classes containing only constants and a set of static methods for working on them. Well, let's say the String class is final.
3. The abstract modifier is used to denote abstract classes. In essence, it means that objects of this class should never be created directly. Only as part of the heirs. A class must contain this identifier if it contains at least one method designated as abstract.

Now let's talk a bit about interfaces. They should be thought of as completely abstract classes, which are used to describe what a class should do, but without imposing restrictions on how it will do it.

1. All interface methods are implicitly declared as public and abstract. That way, it doesn't matter if you wrote explicitly public abstract void foo(), public void foo() or just void foo() inside the interface. The compiler will perceive it as anyway public abstract void foo().
2. Since the interfaces are completely abstract, the concepts of final (simply meaningless), strictfp (there is simply nothing to follow the mysterious standard) or native are not applicable to them.
3. An interface can extend (extends) one or more other interfaces. And only them. He can expand nothing but interfaces.
4. An interface cannot implement (implements) other interfaces.

Keep in mind that you can declare indirect within the interface. Moreover, any field you draw in the interface will receive public, static, and final modifiers. It doesn't matter if you wrote int a = 48, public int a = 48or public static final int a = 48 inside the interface. All three ads will be perceived as public static final a = 48 with all the consequences.

That’s all for today. Next time I’ll try to examine in more detail the features of applying access modifiers to the fields and methods of the class. In addition, we will consider primitive types, arrays, and static variables, as well as pass the first test to check how well everything is digested and digested. I’ll formalize the test as a form in Google Docs.

If anyone is interested, I can also publish detailed instructions on how to register for this exam through the sites of authorized Oracle partners. I personally, in order to figure out where and what to choose, whom to write and with whom to negotiate, had to contact Oracle support.

Thank you for your attention and a successful exam!