Java 9 programming by example

Title Page Java Programming By Example Your guide to software development Peter Verhas BIRMINGHAM - MUMBAI Java Programming By Example Copyright © 2017 Packt Publishing All rights reserved No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews Every effort has been made in the preparation of this book to ensure the accuracy of the information presented However, the information contained in this book is sold without warranty, either express or implied Neither the author, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals However, Packt Publishing cannot guarantee the accuracy of this information First published: April 2017 Production reference: 1240417 Published by Packt Publishing Ltd Livery Place 35 Livery Street Birmingham B3 2PB, UK ISBN 978-1-78646-828-4 www.packtpub.com Credits Author Copy Editors Peter Verhas Muktikant Garimella Zainab Bootwala Reviewer Project Coordinator Jeff Friesen Ulhas Kambali Commissioning Editor Proofreader Kunal Parikh Safis Editing Acquisition Editor Indexer Denim Pinto Mariammal Chettiyar Content Development Editor Graphics Nikhil Borkar Abhinash Sahu Technical Editor Production Coordinator Hussain Kanchwala Melwyn Dsa   About the Author Peter Verhas is a senior software engineer and software architect having electrical engineering and economics background from TU Budapest (MsC) and PTE Hungary (MBA), and also studied at TU Delft and TU Vienna He created his first programs in 1979, and since then he has authored several open source programs He has worked in several positions in the telecommunications and finance industries and was the CIO of the Hungarian start-up index.hu during its early days Peter works for EPAM Systems in Switzerland, participating in software development projects at various customer sites, and he supports talent acquisition by interviewing candidates, training programs for developers, and internal mentoring programs You can follow Peter on Twitter at @verhas, LinkedIn, and GitHub, or read his technical blog, Java Deep, at http://javax0.wordpress.com Acknowledgement is the section of a book that everybody ignores by turning the pages This time, this section is a bit different I will mention a few people and their roles in the making of this book but, at the same time, I will explain why and how it is important to rely on people, being a software developer Doing professional work is not possible without having a life It is quite obvious if you take that literally, but it is just as true figuratively If you not find the balance between your personal and professional life, you will burn out and will not operate professionally This is the place to mention my family, my parents whom I am lucky to still have around, my wife, and my already adult kids who never stopped believing in me being able to this work, who know more than well what a hypocrite I am, advocating personalprofessional life balance, and who continually pushed me closer to this equilibrium point in life so that I could keep performing professionally For professional work, coworkers are almost as important as family support It is important that you support your colleagues as much as you ask them for their support You learn a lot from books and from experience, but you learn the most from other people Pay attention to senior developers You can, however, learn just as much from juniors No matter how ace you are, from time to time, a rookie may shed light on a topic During the years, I learned a lot from juniors who brought a fresh view to the table, asking shocking questions that were absolutely valid I cannot name each and every junior who aided my work with fresh out-of-the-box thinking I can, and should, however, name some peer professionals who actively participated in the creation of this book with their advice, discussions, and suggestions I should certainly mention Károly Oláh who was very enthusiastic about my project, and he represented, supported, and encouraged the idea inside EPAM systems He actively discussed with the upper management that the support for writing a book well fits the innovation line and development of the company, and the people who work together Without the official support from the company providing extra time for the task, I would not have been able to create this book Good company attracts good people who are clever and also good to work with I had many discussions about the book, topics, and how to explain certain aspects with my fellow EPAMers: Krisztián Sallai, Peter Fodor, Sándor Szilágyi, Mantas Aleknavicius, Gábor Lénard, and many others I will separately mention István Attila Kovács from our Budapest office with whom I discussed Chapter in detail, and who gave me very valuable feedback about the topic If he does not know something about Java parallel computing, then that something does not exist As a summary and takeaway for the patient reader who read this section till the end, technology, knowledge, skills, and experience are extremely important for being a professional Java developer, but it is the people who really matter About the Reviewer Jeff Friesen is a freelance author and software developer who has taught Java in the classroom and by writing numerous articles and books since the late 1990s He holds a Bachelor of Science degree in Computer Science and Mathematics Prior to freelancing, Jeff worked for telecommunications, investment, and software development companies Jeff freelances as a Java author and software developer Jeff has written Java I/O, NIO and NIO.2 and Java Threads and the Concurrency Utilities for Apress Full details are available on his website (http ://javajeff.ca/cgi-bin/makepage.cgi?/books) I thank Nitin Dasan for the opportunity to tech review this book I also thank Ulhas Kambali for assisting me with the tech review process Documentation Documentation is an important aspect If the documentation is not appropriate, it will be hard to learn how to use the library Some of the team members may have already known the library, but, again, this may not be the case for later team members We should consider our colleagues, who are expected to be average programmers, and they will have to learn the use of the library Thus documentation is important When we speak about documentation, we should not only think about the JavaDoc reference documentation but also tutorials and books if they are available Project alive It is important not to select a library for use that is not alive Have a look at the roadmap of the library, the last time a release was shipped, and the frequency of the commits If the library is not alive, we should consider not using it Libraries work in an environment and the environment changes The library may connect to a database The new version of the database may provide new features that give us better performance only if the library is modified to accommodate these new features The library communicates over HTTP; will it support the new 2.0 version of the protocol? If nothing else, the version of the Java environment will change over the years and the library we use should sooner or later follow it to leverage the new features There is no guarantee that an alive library will always stay alive However, a library that is already dead will certainly not resurrect Even if the project is alive at the moment, there are some points that may give some hints about the future of the library If the company developing it is well-established and financially stable, and the library is developed with a reasonable business model, then there is a low risk that the project dies If there are a lot of companies who use the library, then it is likely that the project will stay alive even if the original team stops working on it or the original financing structure changes However, these are only small factors and not well-established facts There is no guarantee, and telling the future is more an art than a science Maturity Maturity is similar to the previous criterion A project may very well be alive just starting up, but if it is in its infancy, we better not use the library for a large project When a project is in its early phase, a lot of bugs can be in the code, the API may change radically, and presumably, there may only be a small number of companies relying on the code This also means that the community support is lower Of course, if all the projects select only mature open source code, then no open source project would ever get to the mature state We should assess the importance of the project Is the project business-critical? Will the project become business-critical? If the project is not business-critical, the company may afford to invent a fresh library that is not that mature It may be reasonable if there are no mature libraries for the purpose because the technology you are going to use is relatively new In such a case, the project in the company is probably also new and not business-critical yet It will be business-critical, we hope, after some time, but by that time, the library will be mature, or may just die and we can select a competing solution before the project becomes too expensive to switch Judging the maturity of a library is always difficult and has to be aligned with the maturity and importance of the project that we want to use the library for Number of users If the library is alive and mature but there are not many users, then something is smelly Why don't people use the library if it is good? If the number of users for a library or framework is low and there are no large corporations among the users, then it is probably not a good one Nobody using it may signal that our assessment of the other criteria may not be appropriate Also note that if there are only a few users of the library, then the knowledge in the community is also scarce and we may not be able to get community support The "I like it" factor Last but not least, the I like it factor is extremely important The question is not whether you like the library but rather how much the developers like it Developers will like a library that is easy to use and fun to work with, and this will result in low cost If the library is hard to use and developers not like it, then they will not learn to use it to the level of profession required for good quality, only to the level that is just needed The end result will be suboptimal software Continuous integration and deployment Continuous integration means that whenever a new version is pushed to the source code repository, the continuous integration server kicks in, pulls the code to its disk, and starts the build It compiles the code first, then runs the unit tests, fires the static code analysis tools, and, if all goes right, it packages a snapshot release and deploys it on a development server CI servers have web interfaces that can be used to create a release In such a case, the deployment can even go to the test servers or even to production depending on local business needs and on the policy that was created accordingly Automating the build and deployment process has the same advantages as any other automation: repeated tasks can be performed without manual intervention, which is tedious, boring, and, thus, error-prone if done by a human The outstanding advantage is that if there is some error in the source code that can be discovered by the automated build process, it will be discovered Novice developers say that it is cheaper and easier to build the code locally, which the developers anyway, and then push the code to the server if the build process is already checked It is partly true Developers have to check that the code is of good quality and builds well, before sending it to the central repo However, this cannot always be achieved Some errors may not manifest on local environments It may so happen that one developer accidentally uses a newer version of Java than the one supported and uses a new feature of the new version Enterprises not generally use the latest technology They tend to use versions that are proven, have many users, and are mature This year, in 2017, when Java is going to be released in July, huge enterprises still use Java 1.6 and 1.7 Since Java has many new features that are not trivial to implement, I expect that the adoption of the technology may take even longer than the adoption of Java 1.8, which gave us functional programming and lambda It may also happen that a new library is added to the dependencies of the build and the developer who added it to the build file (pom.xml, or build.gradle) could use it without any problem on her local machine It does not mean that the library is officially added to the project, and it may not be available in the central code repository (Artifactory, Nexus, or other implementations of the code repository) The library may have only been on the local repository of the developer, and she may have assumed that since the code compiles, the build is OK Some large organizations use different code repositories for different projects The libraries get into these repositories following meticulous examination and decisions Some libraries may get there, while others may not The reason to have different repositories could be numerous Some project is developed for one customer who has a different policy about an open source project than the other If the enterprise develops code for itself, it may so happen that some library is phased out or not supported anymore, and can only be used for projects that are old A maintenance release may not need to replace a library, but new projects may be not be allowed to use a dying software library The CI server can run on a single machine or it can run on several machines In case it serves many projects, it may be set up as a central server with many agents running on different machines When some build process has to be started, the central server delegates this task to one of the agents The agents may have different loads, running several different build processes, and may have different hardware configuration The build process may have requirements regarding the speed of the processor or about the available memory Some agent may run simpler builds for smaller projects but would fail to execute the build of a large project or of some small project that still has a huge memory requirement to execute some tests When a build fails, the build server sends out e-mails to the developers, and the person who sent the last update to the code repository is obligated to fix the bug without delay This encourages the developers to commit frequently The smaller the change, the fewer chances there are of a build problem The build server web interface can be used to see the actual state of the projects, which project is failing to build, and which is just fine If a build fails, there is a red sign in the line of the build, and if the build is OK, the sign is green Many times, these reports are continually displayed on some old machine using a huge display so that every developer or just anybody who enters the room can see the actual state of the builds There is even special hardware that you can buy that has red, yellow, and green lamps to follow the state of the build and ring a bell when the build fails Release management Developing software means a continuously changing code base Not every version of the software is supposed to be installed in production Most of the versions are pushed to the repository on a branch half complete Some versions are meant only for testing and a few are meant to be installed in production even if only some of those will finally get to production Almost all the time, the releases follow the semantic versioning that we discussed in an earlier section The versions that are meant only to be tested usually have the -SNAPSHOT modifier at the end of the version number For example, the 1.3.12-SNAPSHOT version is the version that was once debugged, and is going to become the 1.3.12 version The snapshot versions are not definite versions They are the code as it is by then Because a snapshot release never gets installed in production, it is not needed to reproduce a snapshot version for maintenance Thus, the snapshot versions are not increased continually Sometimes, they may be changed, but that is a rare exception It may so happen that we work on a bug fix, 1.3.12-SNAPSHOT, and during the development, we change so much code that we decide that it has to be 1.4.0 when it is released, and we rename the snapshot as 1.4.0-SNAPSHOT This is a rare case Many times, the release creation creates a 1.4.0 version from 1.3.12SNAPSHOT as the decision about the new release number is taken by the time the release is created When the release process is started, usually from the web interface of the CI server, the developer creating the release has to specify the release version This is usually the same as the snapshot version without the -SNAPSHOT postfix The build process not only creates the build in this case but also tags the source code repository version it was using and loads the packaged program (artifact) to the code repository The tag can be used later to access the exact version of the source code that was used to create the release If there is a bug in a specific version, then this version has to be checked out on a developer machine to reproduce the bug and find the root cause If the build of a release fails, it can be rolled back, or you better just skip that release number and note it as a failed release build An existing release can never have two versions The source code is the only one that is for that release and the generated code has to be exactly the one in any storage Subsequent compilation of the same source may result in slightly different code, for example, if a different version of Java is used to create the latter one Even in such a case, the one that was created by the build server in the first place is the version that belongs to the release When a bug is reproduced and the code is recompiled from the exact same source, it is already a snapshot version Multiple releases may be possible from the same source version, for example, compiled with Java versions from 1.5 to 1.8 and version but a single release always belongs to the exact same source code If a release that was supposed to be a release version fails during QA checks, then a new release has to be created and the failed release has to be noted as such The version that marketing uses to name the different versions should not have a relation to the technical version numbers we work with Many times, it is, and it causes much headache If you realize that the two are totally different things and one does not have to anything with the other, life gets simpler Look at the different versioning of the Windows operating system or Java As marketing, Java used 1.0 then 1.1, but Java 1.2 was advertised as Java and still the code contained 1.2 (which now seven major releases later also becomes instead of 1.9) The last part of release management is that deployments should register the version numbers The company has to know which release is installed on which server, and of which client Code repository Code repository stores the libraries and helps manage the dependencies of the different libraries In the old times, when Java projects used ANT as a build tool and without the later added Ivy dependency management, the libraries that were needed by a project were downloaded to the source code, usually to the lib library If a library needed another library, then those were also downloaded and stored manually, and this continued until all the libraries that one of the already downloaded libraries needed were copied to the source code tree This was a lot of manual work and, also, the library code was stored in the source code repository in many copies A compiled library is not source code and has nothing to in the source code repository Manual work that can be automated has to be automated Not because developers are lazy (yes, we are and we have to be) but because manual work is error prone and, thus, expensive This was when Apache Ivy was invented and Maven, following ANT, already supported repository management built in They all stored the libraries structured in directories and supported metadata that described the dependencies to other libraries Lucky that Gradle did not invent its own code repository Instead, it supports both Maven and Ivy repositories Using the repository, the build tools automatically download the libraries that are needed In case a library has a new version, then the developer only has to update the version of the needed library in the build configuration and all tasks, including downloading all the new versions of the other libraries that are needed by that version, are done automatically Walking up the ladder At this point, you have got a lot of information that will rocket your start as an enterprise Java developer You have got a base knowledge that you can build on There is a long way to become a professional Java developer There is a lot of documentation to read, a lot of code to scan and understand, and also a lot of code to write till you can claim to be a professional Java developer You may probably face many years of continuous education The good thing is that even after that, you can continue your journey and you can educate yourself, as being a professional Java developer is rarely a job people retire from No, no! Not because they die while at it! Rather, professional software developers gaining experience start to code less and less and support the development process in different ways, which leverages more of their experience They can become business analysts, project managers, test engineers, subject-matter experts, architects, scrum masters, automation engineers, and so on Is it a familiar list? Yes, these are the people you will work with as a developer Many of them may have started as a developer themselves The following diagram shows the relative position of these roles: Let's take a bit more detailed look into what these roles perform in enterprise development: Business analysts work with the client and create the documents, specifications, use cases, and user stories needed by the developers to develop the code Project managers administer the projects and help the team in getting things done in cooperation with other teams, caring for all the project matters that developers cannot attend to or would unnecessarily burn their time that they should have devoted to coding Subject-matter experts are more advanced in knowing the business needs, so it is a bit rare for a developer to become one, but in case the industry you work in is technology oriented, it may not be incredible to become one Test engineers control the QA process and understand not only the test methodologies and requirements of testing but also the development process so that they can support bug fixes and not only identify them, which would be poor Architects work with BAs and design a high-level structure of the applications and code, and document it in a way that helps the developers to focus on the actual tasks they have to perform Architects are also responsible for the solution to use technologies, solutions, and structures which fit the purpose, are future proof, affordable, and so on Scrum mates help the development team to follow the agile methodology and help the team in controlling the administration and resolving problems There are many ways to go as a software developer and I only listed some of the positions that you can find in an enterprise today As technology develops, I can imagine that in 20 years from today, software developers will teach and curate artificial intelligence systems and that will be what we refer to as programming today Who can tell? Summary Going in this direction is a good choice Being a Java developer and becoming a professional in it is a profession that will pay well in the coming 10 to 20 years for sure and perhaps even later At the same time, I personally find this technology fascinating and interesting, and after more than 10 years of Java programming and more than 35 years of programming, I still learn something new in it every day In this book, you learned the basics of Java programming From time to time, I also mentioned issues, suggested directions, and warned you about pitfalls that are not Java-specific However, we also did the homework of learning the Java language, the infrastructure, the libraries, development tools, and networking in Java You also learned the most modern approaches that came only with Java and 9, such as functional programming in Java, streams, and reactive programming If you know all that I have written in this book, you can start working as a Java developer What's next? Go, and find your treasure in programming and in Java! ...Title Page Java Programming By Example Your guide to software development Peter Verhas BIRMINGHAM - MUMBAI Java Programming By Example Copyright © 2017 Packt Publishing... purchase Downloading the example code You can download the example code files for this book from your account at https://github.com/PacktPublishing /Java- 9- Programming- By- Example If you purchased... Reactive streams Reactive programming in Java Implementing inventory Summary 10 Finalizing Java Knowledge to a Professional Level Java deep technologies Java agent Polyglot programming Polyglot configuration