Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (10)
Similar a Java 9, JShell, and Modularity
Similar a Java 9, JShell, and Modularity (20)
Más de Mohammad Hossein Rimaz
Último
Último (20)
Java 9, JShell, and Modularity
- 1. Java & Beyond Java 9 Mohammad Hossein Rimaz K. N. Toosi University of Technology KNTU Java User Group
- 2. Outline: •JShell •Modularity •Other Java 9 Features •Road Ahead
- 3. JShell
- 4. What? • JShell is a REPL (Read-Evaluate-Print Loop), a command line tool which allows developer to coding in java without building projects in IDEs or compiling and running their short code which is quite lengthy task • If you are familiar with interpreted language like Python or other JVM languages like Groovy or Scala the concept of JShell is familiar to you.
- 5. Why? • Good for new programmers and beginners • Good for testing language features
- 6. JShell Commands: • /list [all] • /vars, /methods, /classes • /edit • /reset • /set editor [notepad, gedit, …] • /imports • /exit • /env [add module, classpath, …] • /save, /open [mysession.jsh]
- 7. DEMO Web Scraping with JSOUP and JShell
- 8. Modularity
- 9. Outline: •What? & Why? •How? •Details •Transitive Dependency •Aggregator Module •Services •JDeps
- 10. What? & Why? • Java 9 was delayed so many times because of Project Jigsaw. • You might have been hearing a lot about modules, modularity, and other stuff. • What it’s all about? • What the heck is modularization and what do we mean by a modularized platform? • What's the Java Platform Module System (JPMS) all about? • Is it going to be a revolution in Java ecosystem?
- 11. What? & Why? • Maintainability is one of the most significant concerns in software design and evolution. • We want a code base that is loosely coupled, highly cohesive, extremely readable, and can be understandable at a glance. • We design our classes and organize them in packages. • When we have hundreds of packages, the dependencies between them are not visible at one look. • We need something more than packages to organize our code base to make it more maintainable.
- 12. What? & Why? • Another problem is the Java classpath and how it runs our codes. • All JAR classes and libraries are flattened into the classpath. When these JAR files have multiple version of a class on the runtime, the Java ClassLoader can load only one version of that class. In this way, there is ambiguity about how your program is going to work, and ambiguity is a bad thing. This issue is so frequent that you might know it as “JAR Hell.” • Inefficient, Insecure, and even Dangerous!
- 13. What? & Why? • Another problem with the classpath is that it doesn’t follow the “Fail First” principle. • You may have missing classes that exist in the classpath, but not in the production environment. Until you get the JavaClassDefError exception at runtime, you can’t be sure what is missing.
- 14. What? & Why? • Finally, the big issue with the classpath is encapsulation. Every class on the classpath has access to each other, and this is an encapsulation violation. • We want to hide our internal APIs, and that’s why we need another level of encapsulation (“Strong Encapsulation”) and control over the access to our classes in our packages.
- 15. Uses of JDK Internal APIs: Taken from: https://www.slideshare.net/haochenglee/prepare-for-jdk-9
- 16. Uses of JDK Internal APIs:
- 17. What? & Why? • Modules are going to fix these issues. • What is a module? A module has a name, it groups related code, and is self-contained. • A module describes explicitly what it needs from other modules and which part of it is visible to other modules.
- 18. What? & Why? • In this manner, dependencies between modules are crystal clear. • We have Strong Encapsulation, which means we can hide our internal APIs, and finally • We now follow the “Fail First” principle. Therefore, when there is a missing module or a conflict, you will get an error.
- 19. What? & Why? • Modularizing the JDK allows JDK developers to manage the huge complexity of it. • When you write a tiny and straightforward application that doesn’t use RMI, CORBA, Java EE, and other stuff, why do you need a full, huge, and heavy JRE? • Isn’t it wiser to have your runtime image only contain the modules you need? • Now with a modularized platform, it’s possible.
- 20. • Modularizing the JDK allows JDK developers to manage the huge complexity of it. • When you write a tiny and straightforward application that doesn’t use RMI, CORBA, Java EE, and other stuff, why do you need a full, huge, and heavy JRE? • Isn’t it wiser to have your runtime image only contain the modules you need? • Now with a modularized platform, it’s possible. What? & Why?
- 21. What? & Why? • This is how the JDK now looks. • On the bottom, we have the “java.base” module that every other module implicitly or explicitly depends on. • As you can see, this dependency graph is a DAG, which means no circular dependencies allowed [at compile-time!].
- 22. What? & Why?
- 23. What? & Why? Review •Strong Encapsulation. •Handling Complexity through Modularization. •Fail-First: No JAR HELL, No Conflict, No ClassDefFoundError Exception. •Custom Runtime Images, Smaller Footprint, Better Performance.
- 24. How? • The picture shows essentially what a module is. • Each module has a module descriptor called “module-info.java.”
- 25. How? • In the module-info.java file, you describe the name of your module, what it requires to work, and which packages are visible outside this module. • So in its simplest form, the module-info.java looks like this image:
- 26. How? Commands • java --list-modules List of JDK’s modules
- 27. How? Commands • java --describe-module Show module’s descriptor
- 28. DEMO Create Our First Modular Application Using Command-Line
- 29. How? Create Our First Modular Application Using Command-Line • Project Structure
- 30. How? Create Our First Modular Application Using Command-Line • Compiling javac --module-source- path src -d out srckntujug.hellomodulei rackntuHelloWorld.java srckntujug.hellomodule module-info.java
- 31. How? Create Our First Modular Application Using Command-Line • Running java --module-path out -m kntujug.hellomodule/ir.ac.kntu.HelloWorld -> Hello World
- 32. How? Create Our First Modular Application Using Command-Line • Create Custom Runtime Image jlink --module-path "%JAVA_HOME%jmods;out" --add-modules kntujug.hellomodule --output runtimeimage
- 33. How? Create Our First Modular Application Using Command-Line
- 34. How? Create Our First Modular Application Using Command-Line $ runtimeimagebinjava --describe-module kntujug.hellomodule kntujug.hellomodule requires java.base mandated contains ir.ac.kntu $ runtimeimagebinjava --module kntujug.hellomodule/ir.ac.kntu.HelloWorld Hello World $ runtimeimagebinjava --list-modules java.base@9.0.1 kntujug.hellomodule
- 36. Details Transitive Dependency java.sql java.xml java.logging Application Requires Transitive Requires Transitive Requires
- 38. Details Naming • For Application Modules • Short & memorable names • Example: applicationname.modulename • For Library Developer • Global Uniqueness • Reverse DNS • Example: ir.ac.kntu.applicationname.modulename
- 39. Details Aggregator Module java.se java.logging java.sqlApplication java.desktop Requires Transitive Requires Transitive Requires
- 42. Details Services • Suppose we have an application that requests to all online taxi services and request the cheapest taxi service. chipsi.napsi chipsi.tapsi chipsi.maxsi chipsi.taxifinder
- 43. Details Services chipsi.napsi chipsi.tapsi chipsi.maxsi chipsi.taxifinder chipsi.discovery module chipsi.taxifinder{ requires chipsi.discovery; requires chipsi.maxsi; requires chipsi.tapsi; requires chipsi.napsi; }
- 44. DEMO Show Chipsi Modular Application
- 45. Details Services • All of these approaches are wrong. • Two known approach • Factory Pattern : Still we should know about implementations name. • Dependency Injection • But we can use Services and ServiceLoader
- 46. Details Services chipsi.napsi chipsi.tapsi chipsi.maxsi chipsi.taxifinder chipsi.discovery module chipsi.taxifinder{ uses chipsi.discovery.Service; } module chipsi.discovery{ exports chipsi.discovery; } module chipsi.napsi{ provides chipsi.discovery.Service with com.napsi.NapsiServiceProvider; }
- 47. DEMO Show Chipsi Modular Application Using Services and ServiceLoader
- 48. Details • And so many advance features like • Optional Dependencies • Add Modules at Runtime • Resource Encapsulation • ServiceLoader Life Cycle • Auto Modules • Unnamed Modules • You can refer to the provided references to learn about them.
- 49. Other Features
- 50. Other New Features •Collections Factory •HTTP/2, WebSocket, HTTP/1.1 •Stream API Improvements •Reactive Streams with Flow API •StackWalker
- 51. Other New Features •JavaFX Enhancement and new APIs •G1 Garbage Collector as Default GC •Multi-Release JAR Files [JEP-238] •Enhanced Deprecation •HTML5 JavaDoc •And so many other features and enhancements …
- 53. Road Ahead
- 54. Resources • Java 9 Modularity Patterns and Practices for developing maintainable applications By Sander Mak & Paul Bakker • Many examples and descriptions of this slides taken from this book
- 55. Resources • Java 9 Recipes A Problem-Solution Approach By Josh Juneau • A General Book about Java 9
- 56. Resources • Java 9 Modularity Revealed Project Jigsaw and Scalable Java Applications By Alexandru Jecan • Yet another in depth java 9 modularity book.
- 57. JavaOne 2017 Talks: • Modules in One Lesson by Mark Reinhold • Migration to Modules by Mark Reinhold • Modules and Services by Alex Buckley • Designing for Modularity with Java 9 by Sander Mak and Paul Bakker
- 58. Hands On Code: Work with this GitHub repository. https://github.com/AdoptOpenJDK/jdk9-jigsaw
- 59. Q&A