Study of Java

Our reference here is the Java Language Specification, 3rd Edition. Part of the goal of this lecture is for you to gain expertise in "spec reading". Some of the examples below are taken from the Java spec.

Subtyping

Must be declared via extends/implements, except for primitive type subtyping
Used to be there was no "deep" subtyping on objects, but now you can also refine the type in a subclass - see here.
- former is our record subtyping rule where type components must be SAME; now they support some aspects of our rule.
Still, all subtype relationships must be declared as mentioned in the first bullet; in STFb subtyping only depended on the structure of the underlying records. STFb subtyping is thus purely structural and Java's is not.
Summary: STFb is more expressive but Java's is easier to use due to names being given.

Inner Classes

Lets start with reviewing what FbOB had in this area:

In FbOB we had the ability to declare classes anywhere, including inside other class methods, etc. Those classes could also be returned as result values of methods, to be new-ed in a completely different context.
FbOB also has syntax for directly defining objects: Object Inst ... Meth ...
In general, this is an example of fully higher-order classes and objects -- no restrictions on where they can be defined, used or passed to.

Java inner classes give much but not all of the FbOB functionality.

They do allow local classes to be defined just about anywhere.
They do support something similar to the Object syntax of FbOB (and the blocks of Smalltalk and the ..), via anonymous local classes which are immediately new-ed.
They do support multiple levels of nesting: inner classes can have inner classes insde them.
The main lack is the ability for classes to be passed around as data items, e.g. methods returning classes.
The JVM is not "aware" of inner classes, they are implemented as regular classes with mangled names like Foo$1Boo for an inner class Boo inside Boo.

We will go through the inner classes specification and look at some of the crufty issues, e.g.

How fields in the parent objects can be accessed
How static fields in a superclass of an inner class may not be extended

Generics

Generics are Java's version of parametric types. These notes assume familiarity with them; read a tutorial if you are not. Here are some comparisons with the Caml-style parametric types that we studied:

Caml infers generic types 'a automatically; in Java, you must declare them as <T>.
Java generics have some features not found in Caml due to the combination of polymorphism and subtyping.

Bounded subtyping

Recall with generics you cannot have List<String> <: List<Object> kinds of things (see here for description)
The root of this in subtpying theory is that String/Object may occur both positively and negatively in List's signature, so it needs to be invariant.
In STFb we could in fact have such subtypings holding for the case they were positive only -- imagine some list which you could only get the head of, nothing else:
```
{ head : {} -> String } <: { head : {} -> Object }
      
```
would be a legal subtyping in our STFb rules assuming String <: Object. But a full list type would be at least like
```
{ add: String -> {}; head : {} -> String } <: { add: Object -> {}; head : {} -> Object }
      
```
and this relation fails because it also requires Object <: String due to the add parameter. Java is basically assuming that List will have T both as argument and return type of methods and so always forces invariance here. But, we know you can do better than that.

To get around this weakness, Java 5 adds bounded subtyping

In generics you can write things like <T extends C & I> void test(T t)
the "extends C & I" means T can be any type which extends both class C and interface I.
In other words, T <: C and T <: I in our subtyping terminology.
This adds more flexibility, T need not be any type, but from a restricted range of types which gives added flexibility later.
Our constraint-based CFbR with let-polymorphism also allows such sorts of types to be expressed:
```
 test : 'a -> void \ { 'a <: C, 'a <: I }
```
Java also allows type variable wildcards, ? - this is a form of existential type -- the typing holds for some ?.

Method Overloading

The take-home message here is brief:

Java method overloading can be viewed as concatenating all of the argument types onto the method name.
So it is really just a simple form of sugar.
We will briefly look at the examples in the above spec.

Constructors

Java constructors are not that different from the encoding of constructors that we covered in the book - various convenient sugar is added.
Java by default inserts super(); in front of the constructor if another constructor is not invoked at the start; this is a bit of a hack.
There is a default constructor w/ body super(); if none is declared.
Inner classs and generics add a whole load of complications to constructors.

Immutable Data

One of the key lessons of Caml is the importance of known immutable data: it has universal meaning.

Java allows fields to not mutate if qualified with final.
Caml analogy: a let-defined variable.
Like Caml, immutability is only shallow - the field could contain components that mutate.

Public/Private/package protected/Protected

Compare this with Caml modules.

Caml allows arbitrary multiple views of the same module (different things seen by different code given the same module)
Java has fixed forms of multiple view: subclasses may see more (protected) and within vs without a package may see more (package protected)
Caml is more flexible, but Java approach is simpler (on the surface at least).

Concurrency

See the concurrency lecture notes for this topic.

Other issues of comparison between Java and Caml / Fb family of languages

Variant types analogue -- used to not exist but now there are enums at least; "use inheritance instead"
Inference -- generally types are declared; avoids all the glitches in the OCaml design to support inference but requires more programmer typing.
Exceptions -- same

Last modified: Mon Apr 20 13:29:14 EDT 2009