Recommended
More Related Content
Viewers also liked
Viewers also liked (20)
Similar to What's My Modularity
Similar to What's My Modularity (20)
More from Bob Paulin
More from Bob Paulin (12)
Recently uploaded
Recently uploaded (20)
What's My Modularity
- 3. “The bearing of a child takes nine months, no matter how many women are assigned” - Fred Brooks
- 4. But could we make 9 babies in 9 Months….
- 7. UNIX Rule of Modularity Developers should build a program out of simple parts connected by well defined interfaces, so problems are local, and parts of the program can be replaced in future versions to support new features. This rule aims to save time on debugging code that is complex, long, and unreadable. - Eric Raymond
- 8. What makes a module?
- 9. Java Application Architecture Kirk Knoernschild Testable Deployable Manageable Natively Reusable Composable Stateless
- 11. The modularizations include the design decisions which must be made before the work on independent modules can begin. - David Parnas
- 12. Changeability
- 18. Containable https://www.niaid.nih.gov/SiteCollectionImages/topics/im munesystem/humanTCellSlide.jpg
- 19. Java Out of the Box
- 20. What's Missing in Java?
- 21. Versioning 1.0.0
- 22. Protection for Internal Classes
- 23. Security from unwanted classes
- 24. How Do We Deal?
- 26. A good start but…. It doesn't actually stop us from doing bad things
- 27. Project Jigsaw ➔ JEP 200: The Modular JDK ➔ JEP 201: Modular Source Code ➔ JEP 220: Modular Run-Time Images ➔ JSR 376: Java Platform Module System
- 29. Early Release Stuff working! https://jdk9.java.net/jigsaw/
- 30. Inside a Module module-info.java module java.security.sasl { requires java.logging; exports javax.security.sasl; exports com.sun.security.sasl.util to jdk.security.jgss; provides java.security.Provider with com.sun.security.sasl.Provider; }
- 31. No more JRE vs JDK Distinction
- 32. jlink Build your own minimalist runtime!
- 33. Promised but not yet delivered https://www.nlm.nih.gov/medlineplus/magazine/issues/fall10/articles/fall10pg5.html
- 34. OSGi
- 35. OSGi provides runtime modularity
- 36. Converting the Ball Of Mud to OSGi
- 39. Consolidate cycle to one Jar
- 40. Consolidate cycle to separate Jar
- 44. Virtualization
- 45. Docker
- 46. Demo Converting single JVM OSGi to Containers
- 48. Add Docker File Generation to Gradle
- 50. Build Docker Images and Start
- 51. When to use….
- 52. Parting thoughts for good modular code….
- 54. Know how your modules need to scale
- 55. Keep External Interfaces simple
- 57. Bob Paulin Email bob@bobpaulin.com Or bob@apache.org Twitter @bobpaulin GitHub https://github.com/bobpaulin CJUG Meetup http://www.meetup.com/ChicagoJUG/ Twitter @cjug Devoxx4Kids Chicagoland Website http://devoxx4kids.org/usa/chicago/ http://www.meetup.com/Devoxx4Kids- Chicagoland-Area/ Twitter @devoxx4kids_chi Off Heap Java Pubhouse Website http://www.javaoffheap.com/ http://www.javapubhouse.com/ Twitter @offheap
- 58. References Parnas, D. L. On the criteria to be used in decomposing systems into modules. Commun. ACM 15, 12 (December 1972), 1053-1058. DOI=10.1145/361598.361623 http://doi.acm.org/10.1145/361598.361623 Knoernschild, Kirk. Java Application Architecture: Modularity Patterns with Examples Using OSGi Addison-Wesley Professional 2012 Brooks, Fred. The Mythical Man-Month: Essays on Software Engineering Addison-Wesley 1975 Raymond, Eric S. The Art of Unix Programming Addison-Wesley 2003 Perlis, Alan. Epigrams in Programming ACM SIGPLAN Notices 17 (September 1982) http://www.cs.yale.edu/homes/perlis-alan/quotes.html
- 59. Links ● Sonar http://www.sonarqube.org/ ● Sonar Source Dashboard http://nemo.sonarqube.org/dashboard/index ● Docker https://www.docker.com/ ● Apache Felix http://felix.apache.org/ ● Amdatu Remote http://www.amdatu.org/components/remote.html ● Gradle https://gradle.org/ ● Gradle Templates https://github.com/townsfolk/gradle-templates ● Apache Tika https://tika.apache.org/ ● Tesseract OCR https://github.com/tesseract-ocr/tesseract ● Project Jigsaw http://openjdk.java.net/projects/jigsaw/
Editor's Notes
- So today's talk isn't really about anything new and sexy like Microservices or Data Science. However I've found many of the most interesting problems to work with are the ones that we've known about since the dawn of Computer Science and still grapple with today. For example how many people here have been on a project that has fallen behind schedule. Be honest. Ok how many times has the solution been to add more people? An how many of you are still not done? Well this quote should ring pretty true.
- 1975 – Mythical Man Month I use it. Leads to the next question
- It Depends Can the project actually be broken down It depends on Modularity
- So let talk about what I mean by this.
- Here's one definition from the Unix Philosophy. I think this answers it pretty well for 2 sentences. But that doesn't really give me enough to work with. Lets go deeper. Lets talk about what makes a module.
- Anyone care to take a stab at this? Kirk Knoewschild Definition different Deployable Manageable Testable Natively Reusable Composable Stateless
- Simple – need to name Name = purpose Version – software evolves Together should be unique Developer should be able to identify and integrate
- Useless if it can only be used in one place It should also be easily removable from an application.
- Protect inner workiings from the public Sounds bad but helps with refactoring If exposed people will write code with it Once that happens Piss community off or dance around the problems Ever create a admin interface that a client found?
- David Parnas – Module design.
- We need to think about this Existing or new we have a tendency towards the ball of mud. (one big class. One big program) Here are some things he mentions we need to think about in his paper
- Hard – Fortune telling Where do we have questions. Where are we unclear Good candidate for change Encapsulate things that might change
- Loose coupling. The key to making 9 babies Separate deployable units Independent function - Manageable
- Cohesion Understood without the rest of the system Lets talk about Java… Java has a number of features that help with modularity ootb
- Packages - Groups of classes Imports – Allow classes from other groups into other classes
- Ways of protecting implementation details
- Currently packages can't be versioned Neither can jars
- By default classes are public No good way to restrict people from using them This is why Java never removes anything
- Interfaces and Spring Contexts
- We need to go beyond this. DI is only a start not a solution Still have public classes. No versioning.
- No more rt.jar or tools.jar
- Is a upcoming new technology based upon a number of older technologies A lot like virtualization but no hypervisor
- Native Libraries Similar Network ports Shared file systems But with this comes added complexity Discovery Orchestration What were code issues are now spread over the whole system