Slide 1: Beyond Java No Fluff, Just Stuff By Bruce A. Tate J2Life, LLC
Slide 2: Agenda • • • • • • Introduction Java success factors Java limitations Dynamic languages Killer apps? Conclusion
Slide 3: Progress Report • • • • • • Introduction Java success factors Java limitations Dynamic languages Killer apps? Conclusion
Slide 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
Slide 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
Slide 6: Progress Report • • • • • • Introduction Java success factors Java limitations Dynamic languages Killer apps? Conclusion
Slide 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
Slide 8: Key problems for C++ 1. Systems language for application development 3. Key productivity features missing • • Strings Garbage collection 4. Beginning of transition to OO 6. Maintenance impossible • • • Multiple inheritance #def, #include files Pointers
Slide 9: The perfect storm C++ backlash! Instant community Gore invents Internet! NetScape delivery Java features OO emerges! Microsoft backlash! Client/server deployment costs Need for portability C++ is hybrid Java improves OO
Slide 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
Slide 11: Remember: • The best technology doesn’t always win – Java wasn’t the best language, theoretically – C++ wasn’t either • Community, not technology, drove Java • Sun has been very conservative – Brand vs. language – Innovations in base
Slide 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)
Slide 13: Common Java understanding 1. 3. • Web-based designs Focus on integration Mostly in middle tier 5. 7. 9. • • • ORM over result sets Heavy XML influence EJB influence Dumb domain models Importance of facades XML configuration Strings!
Slide 14: Progress Report • • • • • • Introduction Java success factors Java limitations Dynamic languages Killer apps? Conclusion
Slide 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 entity.setHibernateKey(Integer(intKey)); OR myInteger = obj.getInteger(); myInt = myInteger.intValue(); • 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
Slide 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
Slide 17: It’s not all bad • Certain ideas extended Java’s success – Better transparency techniques – Aspect oriented programming – Service oriented architectures • Test driven development • Did I mention the community? • JVM
Slide 18: Transparency tools • Transparent persistence – JDO – Hibernate – Others • AOP • Proxy-driven approaches • Better reflection
Slide 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
Slide 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
Slide 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
Slide 22: But it’s not enough • Java is statically typed – Compile-time checks – Better reliability – At least, in theory • Java uses predominantly checked exceptions – But you can’t deal with them at lower levels • Java string handling is second class – Inferior regular expression support SLOW • Java iterators are awkward • Java doesn’t allow code blocks
Slide 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
Slide 24: Progress Report • • • • • • • Introduction Java success factors Java limitations Important missing features Dynamic Languages Killer apps? Conclusion
Slide 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
Slide 26: Consider Ruby 4.times {puts "hello"} Becomes class HelloWorldApp { public static void main(String[] args) { for (int i=0; i<4; i++) { System.out.println(“hello"); } } }
Slide 27: The difference 4 is an object With real methods No declarations needed; you can 4.times {puts "hello"} evaluate a fragment Code blocks for efficiency Strong typing Everything is declared Verbose iteration Must be compiled and run class HelloWorldApp { public static void main(String[] args) { for (int i=0; i<4; i++) { System.out.println(“hello"); } } }
Slide 28: Regular expressions • Strings are first class constructs • So are regular expressions • A simple Grep : File.open(ARGV[0]) do |file| while line=file.gets puts line if line =~ Regexp.new(ARGV[1]) end end
Slide 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\>irb irb(main):001:0> animals = ['cat', 'dog', 'elephant'] => ["cat", "dog", "elephant"] irb(main):002:0> animals.each {|a| puts a} cat dog elephant => ["cat", "dog", "elephant"]
Slide 30: Progress Report • • • • • • • Introduction Java success factors Java limitations Important missing features Dynamic languages Killer apps? Conclusion
Slide 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
Slide 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
Slide 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
Slide 34: Rails • Highly reflective • Meaningful defaults and conventions • ORM through Active Record – class User < ActiveRecord::Base; 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
Slide 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)
Slide 36: What’s 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
Slide 37: What’s 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
Slide 38: Progress Report • • • • • • • Introduction Java success factors Java limitations Important missing features Dynamic languages Killer apps? Conclusion
Slide 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 – That’s most productive in Java space – And happy to be there
Slide 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)
Slide 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
Slide 42: Progress Report • • • • • • • Introduction Java success factors Java limitations Important missing features Innovations Embracing alternatives Conclusion
Slide 43: Resources • Ruby – Programming Ruby by Dave Thomas – Rails • Continuations – Seaside – Iowa • AOP • springframework.com
Slide 44: Wrap up • Evaluations! • J2Life, LLC – bruce.tate@j2life.com – Design reviews and architecture – Persistence and performance consulting – Project jump starts – Process and product consulting