Declarations & Access Control

1. Java source file structure 2. Class – level access modifiers

3. Member (variable + Method) Modifiers 4. Interfaces.

Entered into JAVA

1. Java source file structure

In Real-time situations, one file should contain only a single class. But in general, a film may contain more than one class.

A Java program may contain any number of classes. But, we r allowed to declare, atmost are class as the public.

If there is a public class, the name of the program and the name of the public class must be matched otherwise compile – time error.

If there is no public class, then we r allowed to keep any class name as the file name.

Class B { };

Eg 1: Class A { };

Public Class B { }; Saved with name A.java Class C { };

If we compile above pgm, we get compile-time error saying: Class B is public, should be declared in a file named B.java. Eg2: Public Class A { };

Class B { }; Saved with name A.java Public Class C { };

CTE : Class C is Public, should be declared in a file named C.java.

Note : According to real-time coding convention, a file should contain only one

class.

For every class in ur file including inner classes also a separate. Class file will be created.

At nun time it is not mandatory that the class name as argument, any class name within the file can be given.

class sample {

P S V M (S[ ] a) {

Array List a = new Array List ( ); }

}

CTE : Cannot resolve symbol Symbol : Class Array list.

1. But how compiler knows that Array List is a class ?

A : Because in stmt (1), we r doing object creation and that object creation is always done for a class. Hence that is why it is displayed as class AL.

Suppose if we give :

1 → Array List ( );

CTE : Can’t resolve symbol Symbol : Method Array list ( ) 1 → SOP (Array list);

CTE : Can’t resolve symbol Symbol : Variable Array list.

1 → Java.util. Array List l = new java. Util Array List ( ); NO CTE

Fully qualified name

Problem is, every time ur using Array List, U should mention the entire fully available name which is a tedious process. Instead if that, - Array List is unique, we can import that class from a package with import stmtl. in the file.

Such as import sava.util.ArrayList;

This import statement is not at all similar to the #include statement. because, in ‘c’ language # include < > loads all the header files in the current program, but in java that class file is not loaded into the current pgms memory one demand, only the required class is loaded at that particulars moment.

We can use the stmtl.. import java.util. *;

But in real time java.util *; Shouldn’t be used because it decreases the readability. In the util package, which class we r using we don’t know.

IDE always use java.util.ArrayList but not Java.util *

Instead of specifying fully qualified name every time, we can use import statements once and the corresponding classes by short name (or) (by its own name only) i.e. import statement is mean for typing short cut. It is not equal to c language # include < > statement.

import java.util. Array List – considered as

“Explicit class inport” (ECI)

import java.util * - considered a

“Implicit class import”; (ICI)

- ECI Improves readability of the code ICI reduces readability of the code

- ECI is highly recommended for real – time. (because the developer need not be maintained. To make it readable to everyone ECI is always preferable)

ICI is recommended for AMEERPET

(Indian S/w Engg is a perfect example of monkey)

Case 1 : class test extends java.rmi.uni cast remote object

{ }

which of the following is true ?

a) the code fails to compile because of lack of import b) valid

Because, once we r using fully qualified name, no need to specify any import stmt.

Case 2 : import java. util. *;

import java.sql. * ; class test

{

P S V m (S[ ] a) {

Date d = new Date ( ); }

}

Date is present in both util & sql packages. Compiler finds ambiguous from which package it has to take the date class.

Note : The same above problem may come in the case of ‘List’ also because it is available in both java.util and java.awt packages.

Not for SCJP

Note : For compiler :

i) ECI is always convenient

ii) The classes present in current working directory → no need of import

iii) ICI

The compiler searches for a class in the order :

i), ii) and iii) If it got in the 1st _{any only, it ignores remaining 2 cases.}

The compiler resolves the class names in the following order : i) Explicit class import

ii) Classes present in current working directory iii) Implicit class import

Eg : import java.util.date;

import java.sql.*; / j.sql.date; class test

{

P S V M (S[ ] a) {

Date d = new Date( ); }

}

No CTE & RTE

(Even we use import….. *; all the classes won’t be loaded only the required classes will be loaded)

Import statements totally effect or compile time not on runtime. I.e. more no. of import statements will increase the time for compilation but no effect on time to run (or) execute.

Illegal :

import java.util;

import java.util.Array List. *; import java.util.Array List, java. util.Date;

> java c verbose sample.java

Note : If we r using ECI, then the corresponding class files will be loaded even we

r not using those classes in our code. U can seen them with the command > javac – verbose <sample>.java.

Static imports :

- Math is a utility class which provides all static methods.

- This feature was introduced in 1.5 version. According to sun people, static imports improves the readability of the code. But, world wide java experts r not accepting this conclusion. It increases the confusion instead of readability. So, sun people told that to not to use static imports not very frequently.

- Static imports can be used to import static members of a class. But this static imports should be used only when it is compulsion.

- Usually, static members can be accessed by using class name. But, if we r using static import, no need to use class name. i.e. static imports can be used for importing static members of the class.

Eg 1 :