Beyond Java No Fluff, Just Stuff

1
Beyond JavaNo Fluff, Just Stuff

• By Bruce A. Tate
• J2Life, LLC

2
Agenda

• Introduction
• Java success factors
• Java limitations
• Dynamic languages
• Killer apps?
• Conclusion

3
Progress Report

• Introduction
• Java success factors
• Java limitations
• Dynamic languages
• Killer apps?
• Conclusion

4
About Me

• Author and speaker
• 6 books, including
• Better, faster, lighter Java Developer Notebooks
• Founder of Bitter series at Manning
• Frequent speaker
• NoFluff series for 4th year TSS symposium,
  keynote for JavaGroupen, etc.
• Independent consultant
• Focus on design reviews
• Founder and president of J2Life, LLC
• Customers include FedEx, Great West Life, IHS,
  many others
• Frequent speaker
• Programmer, consultant, sales specialist for IBM
• Databases, OO infrastructure, Java
• CTO, director, architect for startups
• Pervado, IronGrid,Alloquent

5
Motivation?

• Programming languages have limited life
• Java is becoming a golden hammer
• Java is showing early signs of decline
• JCP problems
• Backlash against core frameworks
• Emergence of competition
• We need to increase our awareness as Java starts
  to decline

6
Progress Report

• Introduction
• Java success factors
• Java limitations
• Dynamic languages
• Killer apps?
• Conclusion

7
The world before Java

• Early to mid 1990s
• Transition was from Cobol
• C and C were dominant languages
• CORBA has 15 minutes of fame
• Performance was overriding concern
• Downsizing Client server development
• Simple high-level AD environments rose
• Budgets move from glass house
• Power Builder
• Visual Basic
• Big swing toward Microsoft AD

8
Key problems for C

• Systems language for application development
• Key productivity features missing
• Strings
• Garbage collection
• Beginning of transition to OO
• Maintenance impossible
• Multiple inheritance
• def, include files
• Pointers

9
The perfect storm
Gore invents Internet! NetScape delivery Java
features
C backlash! Instant community
OO emerges! C is hybrid Java improves OO
Microsoft backlash! Client/server deployment
costs Need for portability
10
Why Java won

• C community
• Deployment costs
• Internet focus
• Language features
• Reduced pointers
• Portability promises
• Strings (at least, better than C)
• Garbage collection
• Adaptability
• Applets to servlets
• Broad enterprise focus

11
Remember

• The best technology doesnt always win
• Java wasnt the best language, theoretically
• C wasnt either
• Community, not technology, drove Java
• Sun has been very conservative
• Brand vs. language
• Innovations in base

12
Compromises

• C community (forcing C legacy)
• Syntax
• Typing
• Primitives
• Systems language
• Portability (giving up access to platform)
• Type safety (giving up efficiency)
• A more dynamic foundation (losing performance)

13
Common Java understanding

• Web-based designs
• Focus on integration
• Mostly in middle tier
• ORM over result sets
• Heavy XML influence
• EJB influence
• Dumb domain models
• Importance of facades
• XML configuration

Strings!
14
Progress Report

• Introduction
• Java success factors
• Java limitations
• Dynamic languages
• Killer apps?
• Conclusion

15
OOP in Java

• Java is not fully OO
• It has primitives, arrays and objects
• int, float, char
• Introduces need for awkward wrappers
• Especially painful in mapping or binding
  frameworks
• Java does not support mix-ins
• A mix in is an interface plus its implementation
• And not a complete hierarchy
• Languages like Smalltalk and Ruby do
• Java makes it harder to introduce a capability to
  a class

entity.setHibernateKey(Integer(intKey))
OR myInteger obj.getInteger() myInt
myInteger.intValue()
16
OO?

• Java language is increasingly procedural
• Many pure procedure constructs
• Servlet
• Commands (Struts actions)
• Façade layers
• Many pure data models
• EJB influence
• Value objects
• XML is data only
• This dumbs down the language

17
Its not all bad

• Certain ideas extended Javas success
• Better transparency techniques
• Aspect oriented programming
• Service oriented architectures
• Test driven development
• Did I mention the community?
• JVM

18
Transparency tools

• Transparent persistence
• JDO
• Hibernate
• Others
• AOP
• Proxy-driven approaches
• Better reflection

19
Crosscutting concerns

• OOP manages code in one dimension
• But what happens when many issues crosscut the
  model?

Facade
Domain
DAO
Security
Security
Transactions
Security
Security
Transactions
Transactions
Security
Security
Transactions
Security
Security
Security
Security
Transactions
Transactions
20
AOP

• Define aspects, or advice, in one place
• Attach them to events, called pointcuts
• To transparent code
• Usually at compile time

Facade
Domain
DAO
Security
Transactions
21
Lightweight containers

• Simplify dependencies
• Relieves complexity of J2EE services
• More dynamic, and testable
• Spring
• Converts to unchecked exceptions
• Improves organization
• Uses crosscutting concerns
• Hive Mind
• Assists in documentation of dependencies

22
But its not enough

• Java is statically typed
• Compile-time checks
• Better reliability
• At least, in theory
• Java uses predominantly checked exceptions
• But you cant deal with them at lower levels
• Java string handling is second class
• Inferior regular expression support
• Java iterators are awkward
• Java doesnt allow code blocks

23
Like running in tar

• Most productive application languages have
• Immediate feedback
• Dynamic typing
• Higher abstractions
• Better string handling
• Regular expressions
• Better reflective power
• Code blocks
• Cleaner exceptions

24
Progress Report

• Introduction
• Java success factors
• Java limitations
• Important missing features
• Dynamic Languages
• Killer apps?
• Conclusion

25
Consider Ruby

• Developed in 1995 by Yukihiro Matsumoto (a.k.a.
  Matz)
• Designed as scripting language
• But Matz found Python and Perl wanting
• Perl not powerful enough
• Python not OO enough
• Evolved through use
• Strengths grass-roots community, simplicity,
  power

26
Consider Ruby
4.times puts "hello"

• Becomes

class HelloWorldApp public static void
main(String args) for (int i0 ilt4 i)
System.out.println(hello")

27
The difference
4 is an object
With real methods
No declarations needed you can evaluate a
fragment
4.times puts "hello"
Must be compiled and run
Code blocks for efficiency
Strong typing - Everything is declared
class HelloWorldApp public static void
main(String args) for (int i0 ilt4 i)
System.out.println(hello")

Verbose iteration
28
Regular expressions

• Strings are first class constructs
• So are regular expressions
• A simple Grep

File.open(ARGV0) do file while
linefile.gets puts line if line
Regexp.new(ARGV1) end end
29
Code blocks, iteration, types

• Code blocks allow inversion of control
• Continuations are blocks that preserve context
• Iteration is easier
• For the most part, types can be inferred
• Immediate feedback! (Productivity)

D\ruby\work\gtirb irb(main)0010gt animals
'cat', 'dog', 'elephant' gt "cat", "dog",
"elephant" irb(main)0020gt animals.each a
puts a cat dog elephant gt "cat", "dog",
"elephant"
30
Progress Report

• Introduction
• Java success factors
• Java limitations
• Important missing features
• Dynamic languages
• Killer apps?
• Conclusion

31
Continuations

• Keeping state in a stateless protocol is hard
• Especially in highly dynamic web sites
• What if the application could manage state?
• Programming would be much more natural

Class application method main If (user
logonPage.display) MainPage.display
else BadAuthPage.display end end end

• App remembers state
• Across pages
• Server manages details

32
Continuation server impls

• Seaside
• Probably the most prolific
• Written in Small Talk
• Iowa
• Written in Ruby
• Gaining some traction
• Borges (Seaside port)
• Small but active community
• Some memory problems

33
Continuation Server Summary

• Excellent productivity for complex flow
• Works better with complex sites
• Seamlessly handles back button
• Because context flows with a page
• And threading
• But Ruby versions are immature
• And templating is weak

34
Rails

• Highly reflective
• Meaningful defaults and conventions
• ORM through Active Record
• class User lt ActiveRecordBase end
• Maps class User to a table called user
• And creates properties for the columns in user
• Handles associations through naming conventions
• Action Pack for templating and action mapping

35
Rails characteristics

• Extraordinary productivity
• Very quick ramp up
• Through automated scaffolding
• And reflection
• And pervasive Ruby
• Sweet spot is fairly large
• Focus is on web-based apps
• On a persistent domain model
• Very rapid growth
• Duplicated with limited success by Trails (Java)

36
Whats missing?

• The JVM
• The incredible community
• That may not ever happen again
• Libraries for everything
• Some key examples
• Rich object relational mapping (Kodo, Hibernate)
• Low-level interop (Java Native Interface)
• Tapestry

37
Whats in place?

• Excellent language
• Excellent productivity
• Good library support
• Web development basics
• Templating
• Scripting
• Continuations
• Database basics (Active Record)
• XML, SOAP, REST
• Transactions
• Files
• Text, parsing

38
Progress Report

• Introduction
• Java success factors
• Java limitations
• Important missing features
• Dynamic languages
• Killer apps?
• Conclusion

39
When is Java right?

• Safe decision
• With limited productivity
• Large teams (Community choice)
• Teams need portability across problems domains
• Specialized requirements
• High-powered ORM, for example
• Fine-grained integration
• Java plug-ins
• RPC with serialized objects
• High-powered team
• Thats most productive in Java space
• And happy to be there

40
When might you use alternatives?

• Productivity is the overriding concern
• Especially in startup environments
• Small highly productive teams
• Coarse-grained integration is OK
• Web services (REST or Soap style), Database only,
  HTTP-based RPC with primitives
• Emphasize the most crucial part
• User interfaces, text processing (parsing, etc)

41
How might you push Java?

• Emerging programming models
• Aspect oriented programming
• Frameworks like Trails
• Progressive frameworks that shun convention
• Establish a role for scripting languages
• Spring over EJB
• Tapestry over Struts
• Parsed text over XML
• REST over SOAP
• Scripting languages over XML config

42
Progress Report

• Introduction
• Java success factors
• Java limitations
• Important missing features
• Innovations
• Embracing alternatives
• Conclusion

43
Resources

• Ruby
• Programming Ruby by Dave Thomas
• Rails
• Continuations
• Seaside
• Iowa
• AOP
• springframework.com

44
Wrap up

• Evaluations!
• J2Life, LLC
• bruce.tate_at_j2life.com
• Design reviews and architecture
• Persistence and performance consulting
• Project jump starts
• Process and product consulting