20-CS-4003-001 Organization of Programming Languages Fall 2017
Java Properties

Lambda calculus, Type theory, Formal semantics, Program analysis

    Prev     Next     All lectures

(Classic) Java Properties

   
Imperative
    good:
    lightning speed (relative to functional)
incremental changes in state are easy to manage - students like it
bad:
side-effects have a negative impact on proving correctness, safety
performance and correctness becomes a problem in distributed and cloud computation
 
Object-oriented
    good:
    make use of classes from vast libraries
    handle non-deterministic behavior via callbacks - great for graphical apps - students like it
    services do not have to be inherited due to the concept of interface
    speed to a (semi) working product is excellent relative to C/C++
    no so good:
    very verbose
    huge API, must frequently check documentation when prototyping
    complexity and scope of applications has led to some security concerns
 
Polymorphism via virtual functions
    good:
    user-defined types do not break library classes and methods (hopefully)
    bad:
    nothing really
 
Statically typed
    good:
    typing errors are found at compile time increasing chance of successful deployment
    less type checking can be done at runtime improving performance
    not so good:
    some expressibility is lost - examples to follow in Scheme
 
Not type safe (although it is claimed to be under conditions)
   the absence of erroneous or undesirable behavior caused by a
   discrepancy between differing data types
    not so bad:
    Generics helps out considerably
 
Primitive types are first class objects
  1. can be assigned a value
  2. can be composed with other entities in composites (3 * (4 * 2))
  3. can be passed as an argument to a function
  4. can be returned as a function result
 
Reflection supports impressive applications
    good:
    although classes are not actually first class due to 2., they can be constructed and returned by Reflection which satisfies 4.
    a remote host can receive a collection of bytes and turn it into a class from which objects may be instantiated and methods run, even though it may not have access to the class source or byte code.
    no so bad:
    requires significant expertise to use correctly
 
Closures are not in classical java
    good:
    lambda is introduced to Java in v1.8
    bad:
    the power of lambda is enormous as will be seen in Scheme and Haskell but this is missing in classical Java.
 
When calling a method, only primitives are copied
   references to class objects are passed
    good:
    no copy constructor to write or worry about
    can easily copy fields of passed, referenced object, if necessary
    not too bad:
    some care is necessary when handling fields of a passed reference
 
Has garbage collection
    good:
    risk of misplaced pointers is reduced
    no accidental double deletions
    wasted, unreferenced, unused space is reduced or eliminated
    bad:
    garbage collection may take a significant amount of time
    garbage collection causes non-deterministic behavior and must be turned off for some applications
 
Nearly memory safe
    good:
    pointer arithmetic is not allowed
    avoids jumps to invalid data addresses and manipulation of code addresses
    buffer overflows are gone
    bad:
    casting is allowed - however, careful coding can avoid it
    out-of-memory errors are possible (considered a memory safety violation)
 
Allocation via stack and heap
   int i = 4; vs. Integer i = new Integer(4);
    good:
    sure, why not
 
Threads run independent stacks
    good:
    having threads supports co-routining and introduces the possibility for distributed computation
    bad:
    interprocess communication must be synchronized
    care must be taken to avoid deadlock
    care must be taken to ensure serializability
 
Statically scoped
   the scope of a declaration is the region of the program where that variable can be referenced
    good:
    scope is known at compile time and can be completely determined from the text of the code.
    application programmer understands scope as it is made clear in the syntax of the language through { and }, for example.
    not so bad:
    loss of flexibility - e.g. set up display variable at some particular point of execution, then reference it from anywhere later
 
Call-by-value
    good:
    understood semantics - chance of verifying or validating correctness is increased because less about what is happening inside the function is known to or accessible by the caller.
    hmmm:
    but only references to objects are passed instead of the objects
    not too bad:
    loss of flexibility - e.g. call-by-name, value-result, etc. are not available but this can be worked around.
 
Applicative order evaluation of parameters, left to right
   reduces terms within a function body as much as possible before
   the function is applied
 
Strict evaluation of parameters
   all parameters are evaluated before entering body