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

Lambda calculus, Type theory, Formal semantics, Program analysis

    Prev     Next     All lectures

(Classic) Java Properties

    lightning speed (relative to functional)
incremental changes in state are easy to manage - students like it
side-effects have a negative impact on proving correctness, safety
performance and correctness becomes a problem in distributed and cloud computation
    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
    user-defined types do not break library classes and methods (hopefully)
    nothing really
Statically typed
    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
    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
    lambda is introduced to Java in v1.8
    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
    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
    risk of misplaced pointers is reduced
    no accidental double deletions
    wasted, unreferenced, unused space is reduced or eliminated
    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
    pointer arithmetic is not allowed
    avoids jumps to invalid data addresses and manipulation of code addresses
    buffer overflows are gone
    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);
    sure, why not
Threads run independent stacks
    having threads supports co-routining and introduces the possibility for distributed computation
    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
    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
    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.
    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