History of Java 1/2

Copyright 2007 SpringSource. Copying, publishing or distributing without express written permission is prohibited.
Java: History and Outlook
Eberhard Wolff
Principal Consultant & Regional Director
SpringSource

Copyright 2007 SpringSource. Copying, publishing or distributing without express written permission is prohibited. 2
Before Java
•  C++ predominant
•  Easy adoption from C
•  Smalltalk: Clean dynamically typed object
oriented language with a VM
•  Eiffel: Statically typed language with
advanced type system

The Beginning…
•  Java was originally created for set top
boxes
•  Project OAK
•  Simple/ simplistic / good enough language
•  Hardware independent

Why was Java successful?
•  Easy language with clear migration path
from C/C++
•  Applets & the Rise of the Internet
•  SUN as an alternative to Microsoft
•  I meant to say: standards

What remains?
Focus on small devices
•  Mobile, embedded
•  Especially: phones
•  And lately: SUN Spots
•  For even smaller devices

What remains?
Standards
•  Standards are still used as a tool for
innovation in Java
•  Standard and innovation is otherwise
considered a contradiction
•  …but this is how it started
•  Community still looks at standards

What remains?
Simple Language
•  Primitive data types (int, long, float,
double) are no objects
•  Workaround: Autoboxing (i.e. a primitive
data type becomes an object if need to)
•  No parametric polymorphism (type
parameter / templates)
•  Workaround: Changed compiler but same
byte code

What remains?:
Simple Language
•  Checked Exceptions
•  Default: Exceptions have to be caught or
declared to be thrown
•  Java is the only popular language with this
concept

Checked Exceptions:
Output the error somewhere
•  Probably hard to find – not in the log file
•  Error makes the application just continue
try {
...
} catch (JMSException jmsex) {
jmsex.printStackTrace();
} finally {
qc.close();
}

Checked Exceptions:
Ignore the error
•  Error makes the application just continue
•  …and can never be detected
try {
...
} finally {
}

Checked Exceptions:
Wrap the exception
•  Lots of pointless code (wrapping)
•  Every method will throw MyException
try {
...
throw new MyException(jmsex);
} finally {
}

Take away
•  Checked exceptions are (almost) unique to
Java
•  …and should not be overused

Language
•  Parametric polymorphism was later added
(Java 5)
•  …and also Autoboxing to create object from
primitive types
•  Several other enhancements (var arg
methods)
•  Workarounds for initial design decisions
•  Java is not simplistic any more
•  Bytecode had to remain stable
(.NET decided differently)

First applications: Applets
•  Vision: From an HTML/HTTP based Web to
networked servers with rich clients
•  But:
–  Slow startup and bad performance
–  Incompatible JDKs
–  Often HTML is enough

Applets: No success
•  Even Online Office applications use HTML +
AJAX nowadays…
•  Much more JavaScript for Browser support
•  It is hard to even find an Applet
nowadays…

Example: Black
Hole Applet
http://gregegan.customer.netspace.net.au/
PLANCK/Tour/TourApplet.html
•  It is hard to even find an
Applet nowadays…
•  Niche: Graphics with
calculation on the client
•  But: The idea is not dead
yet…

What remains?
Applets
•  JavaFX tries to resurrect this idea
•  But: Fierce competition
–  Adobe Flash – better adoption than Windows
–  Microsoft Silverlight
•  And: Rather slow development of the
technology

Server
•  So the client side Java did not work out.
•  What now?
•  Let's try the server!
•  Evolution from shared
database to shared logic

Before Java
•  CORBA/C++ was predominant and very
complicated
–  No garbage collection
–  Manual thread and instance handling
–  Lots of technology, not too much focus on
business logic
–  Many standards for services, some very hard to
implement and use
–  Death by committee
•  So an alternative was needed

J2EE:
Java 2 Enterprise Edition
•  Web focus
–  Servlets/JSPs are even older
•  But also distributed 2PC
transactions, Message
Orientied Middleware (JMS)
•  Technical solution
•  Other approaches also defined
core Business Objects?
•  Anyone remember IBM San
Fancisco?
1999
J2EE 1.2 =
EJB 1.1+
JSP 1.1+
Servlets 2.2+
JDBC 2.0+
JNDI 1.2+
JMS 1.0.2+
JTA 1.0.1+
JTS 0.95+
JavaMail 1.1+
JAF 1.0

J2EE vs. C++/CORBA
•  Garbage Collection
•  Thread / Instance Pooling integrated (EJB)
•  Components define
–  Thread pooling
–  Instance handling

J2EE
•  Tremendous success
•  SAP, IBM, SUN, Oracle, BEA
•  Original vendors (Orion, WebLogic, …)
were bought
•  Microsoft had to create .NET

But…
•  This is before Hotspot, JIT, optimized
Garbage Collection etc.
•  Bad performance
•  Unstable middleware etc.
•  In retrospect the success is surprising

Why did J2EE succeed?
User
•  Thinking in the Java-Community: "J2EE is a
standard, is has to be suited for enterprise
problems."
•  …and Java is much simpler than what we
use at the moment
•  Open, standards based
•  …and then the middleware company
followed
•  The next big thing after CORBA

Back to the J2EE disaster
  "Up to when I left [a large consultancy]
in 2002, not one of our J2EE projects
had succeeded."
anonymous
  Translate that to the € / $ lost
  (Of course you can blame it on the
customers and the process)

The disaster: Distribution
•  "You have to be able scale the business
logic independently from the web to handle
high load."
•  So you must have a web server and an
separate EJB server
•  All EJBs (1.0/1.1) are remotely accessible
•  "I turn your software scalability problem in
a hardware scalability problem."
anonymous J2EE consultant

The disaster: Distribution
•  Complete and dangerous nonsense
•  A distributed call from the web server to
the EJB server is orders of magnitude
slower than a local call
•  "Don't distribute your objects!"
Martin Fowler

The disaster: Productivity
•  An Entity Bean (EJB 1.0-2.1) consists of:
–  Three Java classes / interfaces
–  A deployment descriptor (or part of it)
–  …which is so hard to write that most generate it
using XDoclet
•  Usually also a DTO (Data Transfer Object)
is needed
–  to transfer the data to the client / web tier
–  …and of course the data has to be copied into it
–  …so you need also a Stateless Session Bean
(three Java classes/ interfaces + Deployment
Descriptor)

The disaster: Productivity
•  All EJBs cannot really be tested without a
container
•  So people started to wrap POJOs (Plain Old
Java Objects) into EJBs
•  Even more code
•  Workaround: Generators
•  This hurt MDA
•  …was often perceived as an EJB work
around

The disaster: Persistence
•  Persistent objects
•  Can be remotely accessed
•  Synchronize state with database on each call
•  So with a naïve implementation every get/set
is a remote call (and a SQL query)
•  Now imagine you want to edit some data…
•  Reading n objects uses n+1 SQL queries
•  1 Entity Bean = 3 classes (each technology
dependent) + XML configuration
•  Total usability and performance disaster

But it has to be good for
something…
•  So you would need coarse grained
persistent object
•  With concurrent access by multiple users
•  Why don't we have that in our applications?
•  The standard cannot be wrong, right?
•  This concept is still around

It could have been avoided…
•  TopLink was around before that (even for
Smalltalk)
•  NeXT did the Enterprise Object Framework
before that
•  Problem persists: Standardization
committees do not look at prior art

What remains?
J2EE
•  J2EE's success is not based on superior
technology
•  J2EE has had very deep trouble and was
still a success
•  It is unlikely that it will go away
•  …as it survived this when it was much
weaker.

What remains?
J2EE
•  J2EE has been extended and renamed
•  But some concepts are still around
–  EJB very much resembles how CORBA servers
are created and takes bad garbage collection
performance into account

What remains?
J2EE
•  Examples:
–  instance pooling obsolete because of thread safe
Singletons and Hotspot VMs
–  two phase commit often unnecessary and slow
–  Still no good security concept: How do you
express that a customer can only see his
accounts?
–  EJB Security is largely unchanged and can't
handle a lot of common issues (instance based
security, Access Control Lists, integration with
common security technologies…)

Fundamental problems
J2EE
•  Concept is based on small cluster and
client/server
•  What about cloud / virtualization / grid?
•  Still not solved
•  J2EE is invasive i.e. your code depends on
the technology
•  Hard to test, develop and port
•  Object-oriented programming becomes
hard: The decline of OO

Early J2EE: Issues
•  Performance and productivity problems
•  Decline of OO
•  But: The predominant platform in
Enterprise
•  So: What now?
•  Fix the issues!

Persistence
•  The need for fast persistence solutions was
obvious
•  Work around: Use JDBC
•  Complex and error prone
•  With Entity Beans even harder
and a performance disaster
Database

Persistence: Really solve the
problem!
•  O/R mappers were already well known (as
mentioned)
•  …but not used in the Java community
•  Choosing the wrong persistence technology
will lead to many problems
–  Complex code
–  Bad performance

Persistence: Solving the
Problem
•  So: The usual approach: Create a standard
•  JDO: Java Data Objects
•  Technically sound
•  Lots of implementations
•  Some JSO vendors based their business on
JDO
•  But not adopted by any big vendor
•  …and did not become part of J2EE

Persistence
•  People choose Hibernate as an Open
Source product instead
•  …and other projects like iBATIS and OJB
were created
•  Open Source victory over two standards:
JDO and Entity Beans!

The stories continues…
•  JSR 220 (EJB 3) updated the Entity Bean
model
•  JPA – Java Persistence API
•  However:
–  New model was also usable outside a Java EE
server
–  Technically good, but why is it standardized as
part of EJB then?
–  Why are there two standards? JDO and JPA?

Persistence War
•  JPA won
•  Backing by large vendors
(Hibernate, Oracle, …)
•  Basically no JDO implementations
around any more
•  So the persistence problem is
solved
•  (sort of)

What remains?
Persistence Wars
•  Just a few years back JDBC was the (only)
persistence technology
•  Now O/R Mapper are the default
•  But: They are complex pieces of software
•  Caching, lazy loading, complex schema
mappings …
•  …and therefore a trade off
•  …but often a better one
•  Alternatives: Direct SQL with iBATIS, JDBC
•  Make your choice!
•  And: Open Source is a viable alternative.

The rise of Open Source
•  Struts: First Web Framework in 2000
•  (In retrospect it had a huge potential)
•  (for optimization that is)
•  …but much better than no framework at all
•  No standard for web frameworks

Open Source
•  Struts offers no solution to the general
productivity problem
•  Hibernate solves at least persistence issues
•  Spring appeared

What Spring offers
•  Dependency Injection to structure
applications
•  AOP to add transactions, security ...
•  Simplified APIs for JDBC etc

Why Spring was successful
•  Solved the productivity challenges: Much simpler
model
•  Very flexible: Support for EJB, JMS, JDBC,
Hibernate, JNDI, …
•  So you can use it in almost any context
•  …and you can use just parts of it
•  Application are more portable
•  Promotes best practices and makes them easy:
Testing, local access to objects…
•  The rerise of OO

Spring's impact
•  Helped to solve the productivity problem of
Java EE
•  Made parts of J2EE (especially EJB)
obsolete
•  A lot of projects used Tomcat + Spring
instead of J2EE

Open Source: Tomcat
•  Started as Servlet reference
implementation
•  Became an Apache project
•  Very fast and efficient Servlet container
•  Today: Infrastructure for most Java
projects
•  Another example of Open Source
•  Let's talk about Web for a while

The start for Web
•  Servlets: A standardized way to handle
HTTP with Java
•  Lots of code that outputs HTML

JSP
•  Java Server Pages
•  Coincidence: ASP by Microsoft are called
similar
•  HTML + embedded Java
•  + special tags
•  + your own tags
•  Easier: No need to output HTML

What remains:
JSP
•  Still predominant
•  Embedding Java in JSPs is considered a
Worst Practice nowadays
•  …but JSP are still compiled into Servlets /
Java to enable this
•  JSPs cannot easily be tested (Servlet /
Server dependencies)
•  You should consider other template engines

Next step: Struts
•  Web MVC framework
–  Model: The data
–  View: Renders data
–  Controller: Logic
•  Clear separation and much better
maintainability
•  Good fit for request-response based
processing

A quick look at other
approaches…
•  ASP.NET had a completely different
concept:
•  Components (buttons, text fields etc.) used
to set up web pages
•  Components send events
•  Developer can handle events
•  Much like traditional GUI development

Co evolution applied
•  JSF uses this approach
•  …and is a standard
•  Note: MVC or component-based is again a
trade off
•  Rich GUIs or request processing?
•  JavaScript allowed?

And…
•  Microsoft is working on MVC frameworks
(ASP.NET MVC)
•  So while Java travels from MVC to
component based
•  … .NET goes from component based to MVC

New issues…
•  Several pages are part of a business
process
•  Data should be shared during the process
•  Can not be put in the HTTP session:
Otherwise just one process can be
executed in parallel
•  Process should be explicitly handled

Conversations
•  Allow to model processes
•  Data can be stored with a process scope
•  Also benefits for O/R mappers: Caches /
Unit of work can be scoped in the
conversation
•  Spring Web Flow

Client
•  Remember: The origin (Applets)
•  Basic infrastructure: AWT
–  Abstract Windowing Toolkit
–  Every GUI element is shadowed by a native GUI
element
–  Better performance, better integration in the
platform
–  First version was done quickly
•  Portability issues for application and AWT
itself

Swing
•  Idea: Do every in Java
•  Much easier portability
•  Less integration with the platform
•  Became a viable solution after Java
performance issues were solved

Eclipse RCP
•  Eclipse created SWT framework
•  Architecture comparable to AWT
•  Ironic: IBM originally objected AWT
because they had the most platforms to
support
•  Eclipse also has a Plug In system (later
OSGi)
•  This created RCP
•  Widely used

RIA
•  Rich Internet Applications
•  Silverlight, Flex / Flash, JavaFX
•  I believe this will not be won

Copyright 2007 SpringSource. Copying, publishing or distributing without express written permission is prohibited.
Outlook

Java will stay
•  A lot of long running buy ins from vendors…
–  IBM, SAP, SUN, Oracle / BEA,
SpringSource 
•  ...and customers
–  "We are using Java / will be using it for 10
years."
•  I think this is unparalleled in the history

Open Source will become
more important
•  Better capabilities to innovate
•  Low risk: Commercial support, can be used
freely
•  Vivid Open Source Java commuity
•  Everything is Open Source now, even Java
itself.

Java EE will become less
important
•  Often already replaced by Tomcat + Spring
•  In some areas (Investement Banking) it
was never really used
•  Alternative approaches for cloud, grid etc.
needed and exist

OSGi might become
interesting
•  Basic infrastructure for many embedded systems
•  …and Eclipse
•  Strong modularity – better architecture
•  Modular middleware can be customized depending
on usage context
•  Individual updates for bundles
•  So for a fix in the customer module just this
module has to be replaced
•  Less testing, less complex build process, …
•  Heavy interest in the Enterprise
•  Come to my SpringSource dm Server talk!

The JVM is the real feature
•  Lots of engineering and research
•  Highly optimized
•  Ubiquitous
•  Often already the predominant platform
•  However, Google Android chose the
language but not the JVM

New languages will be
interesting
•  Java (the language) is not evolving fast
enough
•  …and was not a good language from the
start
•  …and only work-arounds were added
•  …and dynamically typed are becoming
fashionable now

Some examples for new
languages
•  But the JVM is very interesting
•  Scala: Better statically typed language
•  Groovy: Dynamically typed language with
clear migration path from Java
•  And of course JRuby with heavy investment
from SUN
•  Jython

History of Java 1/2

Recommended

More Related Content

What's hot (20)

Similar to History of Java 1/2 (20)

More from Eberhard Wolff (20)

History of Java 1/2