Beyond Java JavaZone 2005, OSLO

1. Beyond JavaJavaZone 2005, OSLO 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 • Jolt-winning Better, faster, lighter Java • Bitter Java, Bitter EJB • Beyond Java (Sept 20) • Speaker (NoFluff series, JavaGroupen keynote, JUGs worldwide) • Currently: Independent consultant • Reviews to improve designs and development processes • Training • Persistence, lightweight development in Java and Ruby • Customers include FedEx, Great West Life, IHS, many others • 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 showing early signs of decline • Competition is emerging • 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. 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)

12. Progress Report • Introduction • Java success factors • Java limitations • Dynamic languages • Killer apps? • Conclusion

13. Java limitations • Java is not fully OO • Java does not express data very well • Java web development frameworks are not productive • Important abstractions are missing • Code blocks • Continuations • Java is designed to be safe for all developers • Exceptions • Typing • Java’s ramp up is slow • Java is slow, but clean

14. Extending Java Java’s core emphasis: • Better transparency techniques • Aspect oriented programming • Proxies, interceptors • Service oriented architectures • Test driven development • Did I mention the community? • JVM

15. Other languages compensate • Metaprogramming in Ruby, Lisp, Python and Smalltalk • Interceptor: rename a method • And put another method in front of it • AOP is not as important • Dynamic languages accomplish the same things in different ways • Dependency injection • Better metaprogramming (open classes) • Beter expression of data (not as much XML)

16. Like running in tar… • Most productive application languages have: • Immediate feedback • Dynamic typing • Higher abstractions • Better string handling • Regular expressions • Better reflective power • More dynamic models • Code blocks • Cleaner exceptions

17. Progress Report • Introduction • Java success factors • Java limitations • Important missing features • Dynamic Languages • Killer apps? • Conclusion

18. 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

19. A demo • Classes • Typing • Code blocks • Continuations • Arrays, hashes

20. Progress Report • Introduction • Java success factors • Java limitations • Important missing features • Dynamic languages • Killer apps? • Conclusion

21. 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 • Wee • Lots of examples in LISP

22. A demo: • Seaside (Avi Bryant)

23. Continuation Server Summary • Excellent productivity for complex flow • Seamlessly handles back button • Because context flows with a page • And threading • Incredible debugging • The state is frozen and accessible • But Ruby versions are immature • And templating is weak

24. 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

25. Rails demo • Rails (David Heinemeier Hansson)

26. 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), Subway (Python), and others • But nothing really captures the essence of Rails

27. What’s missing? • The JVM (but JRuby is coming fast) • No subclassing yet • 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

28. 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

29. Progress Report • Introduction • Java success factors • Java limitations • Important missing features • Dynamic languages • Killer apps? • Conclusion

30. 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

31. 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)

32. How might you push Java? • Emerging programming models • Aspect oriented programming • Frameworks like Trails • Leverage ideas • Less XML (annotations, parsed text) • More emphasis on defaults and convention (Rails) • Inversion of control (code blocks, seaside) • 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

33. Progress Report • Introduction • Java success factors • Java limitations • Important missing features • Innovations • Embracing alternatives • Conclusion

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

35. Wrap up • J2Life, LLC • bruce.tate@j2life.com • Design reviews and architecture • Ruby and Rails training • Persistence and performance consulting • Project jump starts • Process and product consulting