Reflective = x ~ x

Transitive = x ~ y && y ~ z == x ~ z

Symmetric = x ~ y == y ~ x

Associative = (x ~ y) ~ z == x ~ (y ~ z)

 

2s Complement:

 

0101 0101 0101 0101 = 21845

1010 1010 1010 1010 = -21846

 

1s Complement:

0101 0101 0101 0101 = 21845

1010 1010 1010 1010 = -21845

 

Overriding – dynamic dispatch

Hiding – hide base class static function with empty function

Overloading – same function name different arguments

Shadowing – hide name of another type in another context

Obscuring – use same name for both variable and function

 

Instantiating BigDecimal with limited precision:

 

Create shared math context

    static MathContext mc = new MathContext(2, RoundingMode.HALF_UP);

Specify math context with all BigDecimal instantiation

 

 

Java 1.5 Enhancements:

Generics

Enhanced for loop - for (String s : map.values())

Autoboxing/Unboxing

Annotations

Varargs

java.util.concurrent.*

Arrays.deepToString (Returns a string representation of the "deep contents")

Integer.BitCount, rotateLeft, reverse…

Static Import

Typesafe Enums

 

Java 6 Enhancements:

Wildcard class path

Enhanced jConsole

 

Annotations:Modifier, three types: marker, single element, and multi-value.

 

Simple annotations: Override, Deprecated, Suppresssarnings.

 

Meta-Annotations: Target, Retention, Documented, Inherited.

 

@Target – define the targeted element in which the annotation is applicable.

ElementType.TYPE, FIELD, METHOD, PARAMETER, CONSTRUCTOR, LOCAL_VARIABLE, ANNOTATION_TYPE.

@Retention – scope – RententionPolicy.SOURCE, CLASS, or RUNTIME.

@Documented – processed by javadoc.

 

Example:

for (Method m : Class.forName(args[0]).getMethods()) {

  if (m.isAnnotationPresent(Test.class)) {

    try {

      m.invoke(null);

      passed++;

    } catch (Throwable ex) {

      System.out.printf("Test %s failed: %s %n", m, ex.getCause());

      failed++;

    }

  }

}

 

 

J2EE services

XML- XSL and DOM

JDBC- Data Access

JSP and Servlet

JMS

EJB

JNDI & RMI- directory technology

 

 

AnalysisRequirements: Is it possible? Viable? Validation plan?

System-context: Use case and scenario, integration and synchronization.

Model: Classes and objects and associations.

 

DesignArchitectural: Physical, hardware and software.

Mechanistic: Sequence and collaboration.

Detailed: Classes. Activities and notations.

 

Development

ImplementationIntegration

Validation

Deployment

 

JDBC

 

Type 1  JDBC-ODBC Bridge

Type 2  Native API

Type 3  Middleware vendor API

Type 4  Pure Java

 

 

Container Types:

 

EJB container running on a JEE server manages execution of all EJBs.

Web container manages execution of JSP and servlet.

 

 

Non-function system requirements

 

Scalability

Security

Adaptability

Compatibility

Manageability

Availability

 

 

EAR file =

 

.war file + Enterprise Beans (Remote and Home interface classes) + JEE applications

 

 

Distributed applications

 

Pros

 

• The ability to support many clients (possibly of different types) that require a shared "middle tier" of business objects. This consideration doesn't apply to web applications, as the web container provides a middle tier.
• The ability to deploy any application component on any physical server. In some applications, this is important for load balancing. (Consider a scenario when a web interface does a modest amount of work, but business objects do intensive calculations. If we use a J2EE distributed model, we can run the web interface on one or two machines while many servers run the calculating EJBs. At the price of performance of each call, which will be slowed by the overhead of remote invocation, total throughput per hardware may be improved by eliminating bottlenecks.)

 

Cons

 

• Remote invocations are many times slower than local invocations.
• Distributed applications are hard to develop, debug, deploy, and maintain.
• Constraints on practicing OO design
• Most J2EE architectures using remote interfaces tend to be deployed with all components on the same servers, to avoid the performance overhead of true remote calling. This means that the complexity of a distributed application is unnecessary
• EJB applications - whether they use remote or local interfaces - are hard to test, as they are heavily dependent on container services.
• Complex classloader issues. Complex deployment descriptors.
• Need tools to manage complexity instead of avoiding them.
• Potential for excessive network round trip hamper practicing OO design.
• Interface granularity dictated by desire to minimize number of remote method calls.
• Cost of development-deployment-test cycle does not deliver compensating benefits.
• RMI/IIOP is the natural remoting protocol.
• EJB container is to manage server side objects.

 

Hibernate

 

Pros

 

• Data access through an abstraction layer.

 

Cons

 

• Shoehorn an object model onto a relational database.

 

Garbage Collection

 

• GC usually runs in “stop the world” mode
• All allocations done in the Eden area
• Garbage collection ensures when Eden is full
• All freed objects in Eden are marked
• All active objects are copied to Survivor Space
• There are two Survivor Spaces
• In every pass all live objects are copy to one of two Survivor Space
• Copying are made as soon as live objects are found – no need for mark and sweep
• The other Survivor Space and Eden are blanked out
• For J2E 1.2, use two Survivors without Eden
• Permanent Space = system objects
• Throughput is total time – Pauses, the less often the collector needs to pause, the higher the throughput
• Size of young generation has the typical size-throughput trade-off
• Committed space is real space, virtual space is reserved
• Throughput Collector is default on server class machine
• Two basic approaches are used to distinguish live objects – reference counting and tracing all reachable objects from the root
• Reference counting is out of favor because it cannot deal with circular reference

 

To make GC most effective

 

• Make objects short lived – so they would not survive first GC and don’t need to be moved
• Make smallest young generation to minimize number of objects to be checked

 

Types of Garbage Collectors

 

• Serial Collector – default
• Throughput Collector – for large memory and multiprocessor
• takes no longer than maximum pause time
• throughput
• minimum footprint
• Concurrent Low Pause Collector (XX:+UseConcMarkSweepGC)
• Also known as CMS
• Good for shorter collector pauses and multiple CPUs
• Trades processor resource for collection time
• Two pauses – mark and remark
• Garbage are collected concurrently
• Since garbage is collected in place, no need to “stop the world”
• Incremental Low Pause Collector – no longer supported