Identifiers:
(1)Identifiers must start with a letter, a currency character ($),underscore ( _ ).
(2)After the first character, identifiers can contain any combination of letters,currency characters, connecting characters, or numbers.
legal:
int _a;int $c;int ______2_w;int _$;int this_is_a_very_detailed_name_for_an_identifier;
illegal:
int :b;int -d;int e#;int .f;int 7g;
JavaBeans:
Examples of valid JavaBean method signatures arepublic void setMyValue(int v)public int getMyValue()public boolean isMyStatus()public void addMyListener(MyListener m)public void removeMyListener(MyListener m)
Examples of invalid JavaBean method signatures arevoid setCustomerName(String s) // must be publicpublic void modifyMyValue(int v) // can't use 'modify'public void addXListener(MyListener m) // listener type mismatch
Source File Declaration Rules:
There can be only one public class per source code file.
A file can have more than one nonpublic class.
If there is a public class in a file, the name of the file must match the name of the public class.
Files with no public classes can have a name that does not match any of the classes in the file.
Default Access:
Think of default access as package-level access.
package cert;class Beverage { }Now look at the second source file:package exam.stuff;import cert.Beverage;class Tea extends Beverage { }
Can't access class cert.Beverage.
you must never, ever, ever mark a class as both final and abstract.
strictfp is a keyword and can be used to modify a class or a method, but never a variable.
Final Classes:
the final keyword means the class can't be subclassed.
package cert;public final class Beverage {public void importantMethod() { }}Now, if we try to compile the Tea subclass:package exam.stuff;import cert.Beverage;class Tea extends Beverage { }We get an error something likeCan't subclass final classes.
Abstract Classes :
An abstract class can never be instantiated.
abstract class Car {private double price;private String model;private String year;public abstract void goFast();public abstract void goUpHill();public abstract void impressNeighbors();// Additional, important, and serious code goes here}
Notice that the methods marked abstract end in a semicolon rather than curly braces.
(1)All interface methods are implicitly public and abstract.
(2)All variables defined in an interface must be public, static, and final— in other words, interfaces can declare only constants, not instance variables.
(3)Interface methods must not be static.
(4)Because interface methods are abstract, they cannot be marked final, strictfp, or native.
(5)An interface cannot extend anything but another interface.An interface cannot implement another interface or class.
legal:
void bounce();public void bounce();abstract void bounce();public abstract void bounce();abstract public void bounce();The following interface method declarations won't compile:final void bounce(); // final and abstract can never be used// together, and abstract is impliedstatic void bounce(); // interfaces define instance methodsprivate void bounce(); // interface methods are always publicprotected void bounce(); // (same as above)
interface Foo {int BAR = 42;void go();}class Zap implements Foo {public void go() {BAR = 27;}}You can't change the value of a constant! Once the value has been assigned, the value can never be modified.
two different access issues:(1)Whether method code in one class can access a member of another class(2)Whether a subclass can inherit a member of its superclass
If class A has access to a member of class B, it means that class B's member is visible to class A.
To figure this out, first look at the access level of the class. If the class itself will not be visible to another class, then none of the members will be either, even if the member is declared public. Once you've confirmed that the class is visible, then it makes sense to look at access levels on individual members.
Comparison of inheritance vs. dot operator for member access.
For a subclass, if a member of its superclass is declared public, the subclass inherits that member regardless of whether both classes are in the same package:
Members marked private can't be accessed by code in any class other than the class.
package cert;
public class Roo {
private String doRooThings() {
// imagine the fun code that goes here, but only the Roo
// class knows
return "fun";
}
}
package notcert;
import cert.Roo;
class UseARoo {
public void testIt() {
Roo r = new Roo(); //So far so good; class Roo is public
System.out.println(r.doRooThings()); //Compiler error!
}
}
When a member is declared private, a subclass can't inherit it.
package cert;
public class Roo {
private String doRooThings() {
// imagine the fun code that goes here, but no other class
// will know
return "fun";
}
}
package cert; //Cloo and Roo are in the same package
class Cloo extends Roo { //Still OK, superclass Roo is public
public void testCloo() {
System.out.println(doRooThings()); //Compiler error!
}
}
A default member may be accessed only if the class accessing the member belongs to the same package, whereas a protected member can be accessed (through inheritance) by a subclass even if the subclass is in a different package.
package certification;
public class OtherClass {
void testIt() { // No modifier means method has default
// access
System.out.println("OtherClass");
}
}
In another source code file you have the following:
package somethingElse;
import certification.OtherClass;
class AccessClass {
static public void main(String[] args) {
OtherClass o = new OtherClass();
o.testIt();
}
}
No method matching testIt() found in class.
Default and protected behavior differ only when we talk about subclasses.
when you think of default access, think package restriction. No exceptions. But when you think protected, think package + kids.
a subclass-outside-the-package,It means the subclass inherits the member.the subclass cannot use the dot operator on the superclass reference to access the protected member.
Protected does not mean that the subclass can treat the protected superclass member as though it were public.
package certification;
public class Parent {
protected int x = 9; // protected access
}
package other;
import certification.Parent;
class Child extends Parent {
public void testIt() {
System.out.println("x is " + x); // No problem; Child
// inherits x
Parent p = new Parent(); // Can we access x using the
// p reference?
System.out.println("X in parent is " + p.x); // Compiler
// error!
}
}
For a subclass outside the package, the protected member can be accessed only through inheritance.
Once the subclass-outside-the-package inherits the protected member, that member (as inherited by the subclass) becomes private to any code outside the subclass, with the exception of subclasses of the subclass.
Can access modifiers be applied to local variables? NO!
class Foo {
void doStuff() {
private int x = 7;
this.doMore(x);
}
}
In fact, there is only one modifier that can ever be applied to local variables—final.
class SuperClass{
public final void showSample() {
System.out.println("One thing.");
}
}
It's legal to extend SuperClass, since the class isn't marked final, but we can't override the final method showSample(), as the following code attempts to do:
class SubClass extends SuperClass{
public void showSample() { // Try to override the final
// superclass method
System.out.println("Another thing.");
}
}
It is illegal to have even a single abstract method in a class that is not explicitly declared abstract!
public class IllegalClass{
public abstract void doIt();
}
You can, however, have an abstract class with no abstract methods.
public abstract class LegalClass{
void goodMethod() {
// lots of real implementation code here
}
}
Any class that extends an abstract class must implement all abstract methods of the superclass, unless the subclass is also abstract.
The first concrete subclass of an abstract class must implement all abstract methods of the superclass.
The following code won't compile:
public abstract class A {
abstract void foo();
}
class B extends A {
void foo(int I) { }
}
it is simply an overloaded method.
A method can never, ever, ever be marked as both abstract and final, or both abstract and private.