In C++, inheritance and polymorphism could be considered practically an afterthought by comparison to languages like Java and C# which were designed as object oriented from the ground up. In Java, you never write programs; you write classes (objects). It's not possible to write a function that is not encapsulated as part of a class--in other words, all ``functions'' in Java are more appropriately methods. Writing Java code that isn't written with careful attention to its design as an object is a crime against the language; no more should you write C style code in Java than you should write Lisp style code in C. It's sufficient to remember that when you're writing Java code, you're writing OO code. Don't forget that. Following is a brief outline of a few of Java's OO features that differ from C++.
In C++, to inherit from any other class, the syntax looks like this:
class Foo : Parent1, Parent2 { ... };
In Java, the colon is subsumed by the keyword extends. Also note that every class-level and package-level declaration requires an access modifier, so an entire Java class must be marked as being either public, protected, or private. So in Java, the syntax for inheritance looks like this:
public class Foo extends Parent1 { ... }
Java does not allow multiple inheritance in this manner. Every class (except Object) has exactly one parent. If a class is not defined to explicitly extend some other class, by default it extends Object. Every class you write in Java will extend Object. Clearly Object is the only class in the Java language that does not have a parent class.
However, Java does allow multiple inheritance, but that inheritance is restricted. Java introduces the concept of interfaces. An interface could be defined as being a class which may contain only public abstract methods and static fields of any kind. (In Java, ``abstract'' means the same thing as ``pure virtual'' in C++ speak; ``static'' means the same thing as in C++). A class is free to inherit from as many interfaces as it wants, however a different keyword is used when describing inheritance from an interface:
class Foo extends Bar implements Interface1, Interface2 { ... }
class Foo implements Interface1 { ... }
Note that in Java all methods (except static methods) are virtual. This has two consequences: the first is that you are not required to qualify your methods as ``virtual'' and the second is that you cannot deliberately make a method non-virtual. Static methods are not virtual but they also behave differently and have added restrictions (for instance, you cannot refer to the class's fields inside a static method since the magic ``this'' pointer does not exist in static methods), so don't use static methods expressly to prevent a method from being treated as virtual. (In case you are rusty on your OO slang, a virtual method in C++ is one whereby if you assign a child class to a parent class pointer and invoke an inherited method on that pointer, the child's method will be executed. A more eloquent description, which uses even more OO jargon, would be to say that a virtual method is invoked based on a variable's actual type irrespective of its declared type).
In Java, methods can be explicitly marked as being ``pure virtual'' (in C++, a pure virtual method is a virtual method that doesn't have a body). However, recall that in Java the term for ``pure virtual'' is instead ``abstract''. If you wish to declare a method ``abstract'', do so like this:
public abstract void foo();
If a class contains a single abstract method, the class itself must also be marked abstract. Abstract classes are not allowed to be instantiated (i.e., their constructors are not allowed to be invoked). Abstract classes are still allowed to have constructors since their non-abstract child classes might wish to invoke the parent constructor from within their own constructors. To mark a class abstract:
public abstract class Foo { ... }
Although the presence of a single abstract method in the body of the class would suggest that the entire class is abstract and therefore marking it explicitly is basically unnecessary, no compliant compiler will allow you to compile a class that contains an abstract method but is not itself declared abstract.