Oracle Certified Professional Java Programmer Exam Preparation

Foreword

On December 16 of this year, I assigned myself an Oracle Certified Professional Java Programmer exam. He is a Sun Certified Programmer in the past. In addition, I pushed three more comrades to this important step. We start to prepare. So far sluggish, but still ... And in order to systematize the knowledge gained, I decided to periodically compose “husks” - a summary of what I found, read, or tested in my own skin. What you are reading at the moment is squeezing by number zero. I hope that this will help someone avoid buying expensive books and turning over a huge number of articles. I am preparing, by the way, from the book Sun Certified Programmer for Java 6: Study Guide by Kathy Sierra and Bert Bates. Good book, great author, easy language. Recommend.



I draw your attention to the fact that I do not pretend to have a complete description of all that I need to know before the exam. Without the help of hacks, I cannot do this kind of work, simply because I have not passed the exam myself. Much of the following may seem primitive to someone. However, as the practice of testing tests shows, the devil is in the details. We will consider this an attempt to succinctly set forth the necessary from the rules of identifier naming to the pitfalls of overloading methods during inheritance and beyond. In addition, I hope to learn something useful from the comments of people who have already traveled this path. At best, a successfull story will appear on Habré with a complete description of how it all began, grew and developed. Since, according to the idea, everything will be published in real time, approximately once every two days, then those who will have to pass the exam will be able to compare their learning pace with ours and date and pass the checkpoint much faster.

')

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, be they classes, variables, methods, or something else, should have names or, which sounds a bit more scientific, identifiers. It should be borne in mind that there are two levels of "correct" identifier. Firstly, it must meet the requirements of the language, namely:

1. The identifier must begin with a letter, a currency symbol (for example, $) or an underscore. Note that an identifier cannot begin with a digit.
2. After the first character, an identifier can 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. Java identifiers are case sensitive. So 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 agreements, it can still remain valid for the compiler. For example, the compiler consumes the declaration of the variable int _ $ without even being indignant. In the course of exmen it is important to understand whether it is necessary to determine the syntactic correctness of the identifier, or whether it is necessary to understand whether it satisfies the generally accepted standard or not. The whole standard, by the way, no one will ask you. It is important to remember only a few facts:

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

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



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

1. An important fact. One file can contain only one class with the public modifier. Classes with a default identifier, however, it can be as many as you want.
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 a package, then the package declaration must be the first line in the file.
4. If there are imports of other packages, they go immediately after the package declaration and before declaring 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 absence of a modifier. In this case, 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 , but 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 receives the default scope. This means that only classes located with it in the same package can see it. And no other.
2. If a class has a public access modifier, then it is available 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. And the order is not important. You can swap something: final public strictfp. All modifiers are equal. Do not just apply final and abstract at the same time. This will cause a compiler error, since you use mutually opposite modifiers.

1. The strictfp modifier was a discovery for me. Frankly, you hardly have to use it. But to know and remember is useful. If it is applied to a class, it ensures compliance of all operations on floating point numbers with the IEEE 754 standard. As it turned out, it is used to obtain a predictable result, since different processors can handle floating point numbers in different ways.
2. The final modifier prohibits inheritance from the class. Often used for classes that contain 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 designate 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 little about interfaces. They should be thought of as completely abstract classes that are used to describe what a class should do without imposing however restrictions on how it will do it.

1. All interface methods are implicitly declared public and abstract. Thus, it does not matter whether you explicitly wrote public abstract void foo() , public void foo() or just void foo() inside the interface. The compiler will still take it as public abstract void foo() .
2. Since the interfaces are completely abstract, the concepts of final (meaningless), strictfp (there is simply nothing to follow the mysterious standard) or native are not applicable to them.
3. An interface can extend one or more other interfaces. And only them. He cannot expand anything except interfaces.
4. An interface cannot implement other interfaces.

Note that within the interface you can declare a contact. Moreover, any field that you draw in the interface will receive the public, static and final modifiers. It doesn't matter if you wrote int a = 48 , public int a = 48 or 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 will try to consider in more detail the features of the use of access modifiers to the fields and methods of the class. In addition, we will look at primitive types, arrays, and static variables, as well as pass the first test to check how well everything is digested and digested. Test will issue 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 understand where and what to choose, who to write and with whom to negotiate, had to contact Oracle support.



Thank you for your attention and have a good exam!