Bibliography Software Engineering

The Pragmatic Programmer

See: The Pragmatic Programmer – Your journey to mastery, 20th Anniversary Edition, 2nd Edition, by Thomas David and Hunt Andrew, 1999, 2019, B07VRS84D1 (PragProg)

Fair Use Source: B07VRS84D1 (PragProg)

The Pragmatic Programmer: From Journeyman to Master is a book about computer programming and software engineering, written by Andrew Hunt and David Thomas and published in October 1999.[1] It is used as a textbook in related university courses.[2] It was the first in a series of books under the label The Pragmatic Bookshelf. A second edition, The Pragmatic Programmer: Your Journey to Mastery was released in 2019 for the book’s 20th anniversary, with major revisions and new material reflecting changes in the industry over the last twenty years.” (WP)

“One of the most significant books in my life.” –Obie Fernandez, Author, The Rails Way

“Twenty years ago, the first edition of The Pragmatic Programmer completely changed the trajectory of my career. This new edition could do the same for yours.” –Mike Cohn, Author of Succeeding with Agile , Agile Estimating and Planning , and User Stories Applied

“. . . filled with practical advice, both technical and professional, that will serve you and your projects well for years to come.” –Andrea Goulet, CEO, Corgibytes, Founder, LegacyCode.Rocks

“. . . lightning does strike twice, and this book is proof.” –VM (Vicky) Brasseur, Director of Open Source Strategy, Juniper Networks
The Pragmatic Programmer is one of those rare tech books you’ll read, re-read, and read again over the years. Whether you’re new to the field or an experienced practitioner, you’ll come away with fresh insights each and every time.

Dave Thomas and Andy Hunt wrote the first edition of this influential book in 1999 to help their clients create better software and rediscover the joy of coding. These lessons have helped a generation of programmers examine the very essence of software development, independent of any particular language, framework, or methodology, and the Pragmatic philosophy has spawned hundreds of books, screencasts, and audio books, as well as thousands of careers and success stories.

Now, twenty years later, this new edition re-examines what it means to be a modern programmer. Topics range from personal responsibility and career development to architectural techniques for keeping your code flexible and easy to adapt and reuse. Read this book, and you’ll learn how to:

  • Fight software rot
  • Learn continuously
  • Avoid the trap of duplicating knowledge
  • Write flexible, dynamic, and adaptable code
  • Harness the power of basic tools
  • Avoid programming by coincidence
  • Learn real requirements
  • Solve the underlying problems of concurrent code
  • Guard against security vulnerabilities
  • Build teams of Pragmatic Programmers
  • Take responsibility for your work and career
  • Test ruthlessly and effectively, including property-based testing
  • Implement the Pragmatic Starter Kit
  • Delight your users

Written as a series of self-contained sections and filled with classic and fresh anecdotes, thoughtful examples, and interesting analogies, The Pragmatic Programmer illustrates the best approaches and major pitfalls of many different aspects of software development. Whether you’re a new coder, an experienced programmer, or a manager responsible for software projects, use these lessons daily, and you’ll quickly see improvements in personal productivity, accuracy, and job satisfaction. You’ll learn skills and develop habits and attitudes that form the foundation for long-term success in your career.

You’ll become a Pragmatic Programmer.

The pragmatic programmer.jpg
AuthorsAndrew HuntDavid Thomas
SubjectsEducation, teaching
Published1999 by Addison Wesley

“The book does not present a systematic theory, but rather a collection of tips to improve the development process in a pragmatic way. The main qualities of what the authors refer to as a pragmatic programmer are being an early adopter, to have fast adaptation, inquisitiveness and critical thinking, realism, and being a jack-of-all-trades.[3]” (WP)

“The book uses analogies and short stories to present development methodologies and caveats, for example the broken windows theory, the story of the stone soup, or the boiling frog.[4] Some concepts were named or popularised in the book, such as code katas, small exercises to practice programming skills,[5] and rubber duck debugging, a method of debugging whose name is a reference to a story in the book.[6]” (WP)

Andy Hunt and David Thomas gave a GOTO Book Club interview celebrating the 20th anniversary release of the book, covering their journey to writing the book, how the content has evolved since the first release and what’s remained unchanged in the last two decades.” (WP)

Editorial Reviews


“To participate in the next generation of professional product delivery you have to be pragmatic but disciplined. Otherwise, you are fated to be ungrounded dreamers whose products endanger people and whose ideas never become successfully integrated into the world. Andy and Dave described a pragmatic but disciplined approach which is a key step towards professionalism.”
Ken Schwaber, co-creator of Scrum and founder of, agile manifesto signatory, and author of Software in 30 Days.

“Picking adjectives is hard work. In The Pragmatic Programmer, Dave and Andy set the tone for their work–thoughtful, expert, aspirational, and full of care for themselves and those they touch through their programs. From its publication, this was the book to read if you wanted to work to improve.”
Kent Beck, Gusto, author of Extreme Programming Explained: Embrace Change, Test-Driven Development: By Example, and The Smalltalk Best Practice Patterns
“Some say that with The Pragmatic Programmer, Andy and Dave captured lightning in a bottle; that it’s unlikely anyone will soon write a book that can move an entire industry as it did. Sometimes, though, lightning does strike twice, and this book is proof. The updated content ensures that it will stay at the top of “best books in software development” lists for another 20 years, right where it belongs.”
―VM (Vicky) Brasseur, Director of Open Source Strategy, Juniper Networks

“If you want your software to be easy to modernize and maintain, keep a copy of The Pragmatic Programmer close. It’s filled with practical advice, both technical and professional, that will serve you and your projects well for years to come.”
―Andrea Goulet, CEO, Corgibytes; Founder, LegacyCode.Rocks

” The Pragmatic Programmer is the one book I can point to that completely dislodged the existing trajectory of my career in software and pointed me in the direction of success. Reading it opened my mind to the possibilities of being a craftsman, not just a cog in a big machine. One of the most significant books in my life.”
―Obie Fernandez, Author, The Rails Way

“First-time readers can look forward to an enthralling induction into the modern world of software practice, a world that the first edition played a major role in shaping. Readers of the first edition will rediscover here the insights and practical wisdom that made the book so significant in the first place, expertly curated and updated, along with much that’s new.”
―David A. Black, Author, The Well-Grounded Rubyist

“I have an old paper copy of the original Pragmatic Programmer on my bookshelf. It has been read and re-read and a long time ago it changed everything about how I approached my job as a programmer. In the new edition everything and nothing has changed: I now read it on my iPad and the code examples use modern programming languages―but the underlying concepts, ideas, and attitudes are timeless and universally applicable. Twenty years later, the book is as relevant as ever. It makes me happy to know that current and future developers will have the same opportunity to learn from Andy and Dave’s profound insights as I did back in the day.”
―Sandy Mamoli, Agile coach; Author of How Self-Selection Lets People Excel
–This text refers to the hardcover edition.

From the Back Cover

The bestselling software development guide – more than 200,000 sold – now thoroughly updated by its world-class author team

  • Today’s best approaches to transforming requirements into working, maintainable code that delights users
  • Thoroughly revised with 10 new sections, extensive new coverage, new examples throughout – and future-proofed with greater technology-independence
  • Brings together pragmatic advice on everything from personal career fulfillment to more effective architecture

“One of the most significant books in my life.” ―Obie Fernandez, Author, The Rails Way

“Twenty years ago, the first edition of The Pragmatic Programmer completely changed the trajectory of my career. This new edition could do the same for yours.” ―Mike Cohn, Author of Succeeding with Agile, Agile Estimating and Planning, and User Stories Applied

“. . . filled with practical advice, both technical and professional, that will serve you and your projects well for years to come.” ―Andrea Goulet, CEO, Corgibytes, Founder, LegacyCode.Rocks

“. . . lightning does strike twice, and this book is proof.” ―VM (Vicky) Brasseur, Director of Open Source Strategy, Juniper Networks

Book details

  • ASIN : B07VRS84D1
  • Publisher : Addison-Wesley Professional; 2nd edition (July 30, 2019)
  • Publication date : July 30, 2019
  • Print length : 460 pages


  • Andrew Hunt and David Thomas, The Pragmatic Programmer, Addison-Wesley, 2000.
  • David Thomas and Andrew Hunt, The Pragmatic Programmer, 20th Anniversary Edition, Addison-Wesley, 2020.
  1. ^
  2. ^ “CSE 331 17sp Software Design & Implementation: Information and Syllabus”.
  3. ^ Hunt and Thomas, pp. xviii–xix.
  4. ^ Hunt and Thomas, pp. 7-9.
  5. ^ Steve Fenton (2014). Pro TypeScript: Application-Scale JavaScript Development. Apress. p. 209. ISBN 1430267909.
  6. ^ Pete Goodliffe (2014). Becoming a Better Programmer: A Handbook for People Who Care About Code. O’Reilly Media. p. 82. ISBN 1491905581.

External links



Fair Use Sources:

Cloud DevOps History Software Engineering

Agile Manifesto – The Manifesto for Agile Software Development

See also: Agile software development and DevOps

The Manifesto for Agile Software Development

Agile software development values

“Based on their combined experience of developing software and helping others do that, the seventeen signatories to the manifesto proclaimed that they value:[5]” (WP)

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is to say, the items on the left are valued more than the items on the right.

As Scott Ambler elucidated:[21]

  • Tools and processes are important, but it is more important to have competent people working together effectively.
  • Good documentation is useful in helping people to understand how the software is built and how to use it, but the main point of development is to create software, not documentation.
  • A contract is important but is no substitute for working closely with customers to discover what they need.
  • A project plan is important, but it must not be too rigid to accommodate changes in technology or the environment, stakeholders’ priorities, and people’s understanding of the problem and its solution.

Some of the authors formed the Agile Alliance, a non-profit organization that promotes software development according to the manifesto’s values and principles. Introducing the manifesto on behalf of the Agile Alliance, Jim Highsmith said,

The Agile movement is not anti-methodology, in fact many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment. Those who would brand proponents of XP or SCRUM or any of the other Agile Methodologies as “hackers” are ignorant of both the methodologies and the original definition of the term hacker.— Jim Highsmith, History: The Agile Manifesto[22]

Agile software development principles

The Manifesto for Agile Software Development is based on twelve principles:[23]” (WP)

  1. Customer satisfaction by early and continuous delivery of valuable software.
  2. Welcome changing requirements, even in late development.
  3. Deliver working software frequently (weeks rather than months)
  4. Close, daily cooperation between business people and developers
  5. Projects are built around motivated individuals, who should be trusted
  6. Face-to-face conversation is the best form of communication (co-location)
  7. Working software is the primary measure of progress
  8. Sustainable development, able to maintain a constant pace
  9. Continuous attention to technical excellence and good design
  10. Simplicity—the art of maximizing the amount of work not done—is essential
  11. Best architectures, requirements, and designs emerge from self-organizing teams
  12. Regularly, the team reflects on how to become more effective, and adjusts accordingly



Fair Use Sources:

DevOps Software Engineering

Software engineer

software engineer is a person who applies the principles of software engineering to the design, development, maintenance, testing, and evaluation of computer software.” (WP)

Occupation typeProfession
Activity sectorsInformation technologySoftware industry
CompetenciesRequirements analysis, specification development, algorithm design, software quality assurance, documentation tasks.
Education requiredVaries from bachelor’s degree to advanced degree in software engineering or related field


Half of all practitioners today have degrees in computer scienceinformation systems, or information technology.[citation needed] A small, but growing, number of practitioners have software engineering degrees. In 1987, the Department of Computing at Imperial College London introduced the first three-year software engineering Bachelor’s degree in the UK and the world; in the following year, the University of Sheffield established a similar program.[1] In 1996, the Rochester Institute of Technology established the first software engineering bachelor’s degree program in the United States, however, it did not obtain ABET accreditation until 2003, the same time as Rice UniversityClarkson UniversityMilwaukee School of Engineering and Mississippi State University obtained theirs.[2] In 1997, PSG College of Technology in Coimbatore, India was the first to start a five-year integrated Master of Science degree in Software Engineering.[citation needed]

Since then, software engineering undergraduate degrees have been established at many universities. A standard international curriculum for undergraduate software engineering degrees, SE2004, was defined by a steering committee between 2001 and 2004 with funding from the Association for Computing Machinery and the IEEE Computer Society. As of 2004, in the U.S., about 50 universities offer software engineering degrees, which teach both computer science and engineering principles and practices. The first software engineering Master’s degree was established at Seattle University in 1979. Since then graduate software engineering degrees have been made available from many more universities. Likewise in Canada, the Canadian Engineering Accreditation Board (CEAB) of the Canadian Council of Professional Engineers has recognized several software engineering programs.

In 1998, the US Naval Postgraduate School (NPS) established the first doctorate program in Software Engineering in the world.[citation needed] Additionally, many online advanced degrees in Software Engineering have appeared such as the Master of Science in Software Engineering (MSE) degree offered through the Computer Science and Engineering Department at California State University, Fullerton. Steve McConnell opines that because most universities teach computer science rather than software engineering, there is a shortage of true software engineers.[3] ETS (École de technologie supérieure) University and UQAM (Université du Québec à Montréal) were mandated by IEEE to develop the Software Engineering Body of Knowledge (SWEBOK), which has become an ISO standard describing the body of knowledge covered by a software engineer.[4]

Other degrees

In business, some software engineering practitioners have CS or Software Engineering degrees. In embedded systems, some have electrical engineeringelectronics engineeringcomputer science with emphasis in “embedded systems” or computer engineering degrees, because embedded software often requires a detailed understanding of hardware. In medical software, practitioners may have medical informatics, general medical, or biology degrees.[citation needed]

Some practitioners have mathematicsscienceengineering, or technology (STEM) degrees. Some have philosophy (logic in particular) or other non-technical degrees.[citation needed] For instance, Barry Boehm earned degrees in mathematics. And, others have no degrees.[citation needed]



See also: Software engineering demographics

Most software engineers work as employees or contractors. Software engineers work with businesses, government agencies (civilian or military), and non-profit organizations. Some software engineers work on their own as consulting software engineers. Some organizations have specialists to perform all of the tasks in the software development process. Other organizations separate software engineers based on specific software-engineering tasks. These companies sometimes hire interns (possibly university or college students) over a short time. In large projects, software engineers are distinguished from people who specialize in only one role because they take part in the design as well as the programming of the project. In small projects, software engineers will usually fill several or all roles at the same time. Specializations include:

Impact of globalization

Most students in the developed world have avoided degrees related to software engineering because of the fear of offshore outsourcing (importing software products or services from other countries) and of being displaced by foreign visa workers.[5] Although government statistics do not currently show a threat to software engineering itself; a related career, computer programming does appear to have been affected.[6][7] Often one is expected to start out as a computer programmer before being promoted to software engineer. Thus, the career path to software engineering may be rough, especially during recessions.

Some career counselors suggest a student also focus on “people skills” and business skills rather than purely technical skills because such “soft skills” are allegedly more difficult to offshore. Reasonable command over reading, writing & speaking English is asked by most of employers.[8] It is the quasi-management aspects of software engineering that appear to be what has kept it from being impacted by globalization.[9]


There are several prizes in the field of software engineering:[10]

  • The Codie awards is a yearly award issued by the Software and Information Industry Association for excellence in software development within the software industry.
  • Jolt Awards are awards in the software industry.
  • Stevens Award is a software engineering award given in memory of Wayne Stevens.

Use of the title “Engineer”

Main articles: Software engineering professionalism and Regulation and licensure in engineering

Origin of the term

Margaret Hamilton promoted the term “software engineering” during her work on the Apollo program. The term “engineering” was used to acknowledge that the work should be taken just as seriously as other contributions toward the advancement of technology. Hamilton details her use of the term:

When I first came up with the term, no one had heard of it before, at least in our world. It was an ongoing joke for a long time. They liked to kid me about my radical ideas. It was a memorable day when one of the most respected hardware gurus explained to everyone in a meeting that he agreed with me that the process of building software should also be considered an engineering discipline, just like with hardware. Not because of his acceptance of the new “term” per se, but because we had earned his and the acceptance of the others in the room as being in an engineering field in its own right.[11]

Suitability of the term

In each of the last few decades, at least one radical new approach has entered the mainstream of software development (e.g. Structured ProgrammingObject Orientation), implying that the field is still changing too rapidly to be considered an engineering discipline. Proponents argue that the supposedly radical new approaches are evolutionary rather than revolutionary.[citation needed]

Individual commentators have disagreed sharply on how to define software engineering or its legitimacy as an engineering discipline. David Parnas has said that software engineering is, in fact, a form of engineering.[12][13] Steve McConnell has said that it is not, but that it should be.[14] Donald Knuth has said that programming is an art and a science.[15] Edsger W. Dijkstra claimed that the terms software engineering and software engineer have been misused[improper synthesis?] and should be considered harmful, particularly in the United States.[16]

Regulatory classification


In Canada the use of the job title Engineer is controlled in each province by self-regulating professional engineering organizations who are also tasked with enforcement of the governing legislation. The intent is that any individual holding themselves out as an engineer has been verified to have been educated to a certain accredited level and their professional practice is subject to a code of ethics and peer scrutiny. It is also illegal to use the title Engineer in Canada unless an individual is licensed.

In Ontario, the Professional Engineers Act[17] stipulates a minimum education level of a three-year diploma in technology from a College of Applied Arts and Technology or a degree in a relevant science area.[18] However, engineering undergraduates and all other applicants are not allowed to use the title of engineer until they complete the minimum amount of work experience of four years in addition to completing the Professional Practice Examination (PPE). If the applicant does not hold an undergraduate engineering degree then they may have to take the Confirmatory Practice Exam or Specific Examination Program unless the exam requirements are waived by a committee.[19][20]

IT professionals with degrees in other fields (such as computer science or information systems) are restricted from using the title Software Engineer, or wording Software Engineer in a title, depending on their province or territory of residence.[citation needed]

In some instances, cases have been taken to court regarding the illegal use of the protected title Engineer.[21]


Throughout the whole of Europe, suitably qualified engineers may obtain the professional European Engineer qualification.


In France, the term ingénieur (engineer) is not a protected title and can be used by anyone, even by those who do not possess an academic degree.

However, the title Ingénieur Diplomé (Graduate Engineer) is an official academic title that is protected by the government and is associated with the Diplôme d’Ingénieur, which is one of the most prestigious academic degrees in France.


The use of the title tölvunarfræðingur (computer scientist) is protected by law in Iceland.[22] Software engineering is taught in Computer Science departments in Icelandic universities. Icelandic law state that a permission must be obtained from the Minister of Industry when the degree was awarded abroad, prior to use of the title. The title is awarded to those who have obtained a BSc degree in Computer Science from a recognized higher educational institution.[23]

New Zealand

In New Zealand, the Institution of Professional Engineers New Zealand (IPENZ), which licenses and regulates the country’s chartered engineers (CPEng), recognizes software engineering as a legitimate branch of professional engineering and accepts application of software engineers to obtain chartered status provided they have a tertiary degree of approved subjects. Software Engineering is included whereas Computer Science is normally not.[24]

United States

The Bureau of Labor Statistics (BLS) classifies computer software engineers as a subcategory of “computer specialists”, along with occupations such as computer scientist, Programmer, Database administrator and Network administrator.[25] The BLS classifies all other engineering disciplines, including computer hardware engineers, as engineers.[26]

Many states prohibit unlicensed persons from calling themselves an Engineer, or from indicating branches or specialties not covered licensing acts.[27][28][29][30][31][32][33][34][35][36] In many states, the title Engineer is reserved for individuals with a Professional Engineering license indicating that they have shown minimum level of competency through accredited engineering education, qualified engineering experience, and engineering board’s examinations.[37][38][29][30][31][32][33][34][35][36]

In April 2013 the National Council of Examiners for Engineering and Surveying (NCEES) began offering a Professional Engineer (PE) exam for Software Engineering. The exam was developed in association with the IEEE Computer Society.[39] NCEES ended the exam in April 2019 due to lack of participation.[40]

See also

Wikimedia Commons has media related to Software engineers.


  1. ^ Cowling, A. J. 1999. The first decade of an undergraduate degree program in software engineering. Ann. Softw. Eng. 6, 1–4 (Apr. 1999), 61–90.
  2. ^ “ABET Accredited Engineering Programs”. April 3, 2007. Retrieved April 3,2007.
  3. ^ McConnell, Steve (July 10, 2003). Professional Software Development: Shorter Schedules, Higher Quality Products, More Successful Projects, Enhanced CareersISBN 978-0-321-19367-4.
  4. ^ Software Engineering — Guide to the software engineering body of knowledge (SWEBOK), International Organization for Standardization, 2015, retrieved January 11, 2020
  5. ^ “IT news, careers, business technology, reviews”Computerworld.
  6. ^ “Computer Programmers”.
  7. ^ “Software developer growth slows in North America | InfoWorld | News | 2007-03-13 | By Robert Mullins, IDG News Service”. Archived from the original on April 4, 2009.
  8. ^ “Hot Skills, Cold Skills”. Archived from the original on February 22, 2014.
  9. ^ Dual Roles: The Changing Face of IT
  10. ^ Some external links:
  11. ^ Lawrence, Snyder (2017). Fluency with information technology : skills, concepts, & capabilities ([Seventh edition] ed.). NY, NY. ISBN 978-0134448725OCLC 960641978.
  12. ^ Parnas, David L. (1998). “Software Engineering Programmes are not Computer Science Programmes”Annals of Software Engineering6: 19–37. doi:10.1023/A:1018949113292S2CID 35786237., p. 19: “Rather than treat software engineering as a subfield of computer science, I treat it as an element of the set, {Civil Engineering, Mechanical Engineering, Chemical Engineering, Electrical Engineering,….}.”
  13. ^ Parnas, David L. (1998). “Software Engineering Programmes are not Computer Science Programmes”Annals of Software Engineering6: 19–37. doi:10.1023/A:1018949113292S2CID 35786237., p. 20: “This paper argues that the introduction of accredited professional programs in software engineering, programmes that are modelled on programmes in traditional engineering disciplines will help to increase both the quality and quantity of graduates who are well prepared, by their education, to develop trustworthy software products.”
  14. ^ McConnell, Steve (August 2003). Professional Software Development: Shorter Schedules, Better Projects, Superior Products, Enhanced Careers. Boston, MA: Addison-Wesley. ISBN 0-321-19367-9., p. 39: “In my opinion, the answer to that question is clear: Professional software development should be engineering. Is it? No. But should it be? Unquestionably, yes. “
  15. ^ Knuth, Donald (1974). “Computer Programming as an Art” (PDF). Communications of the ACM17 (12): 667–673. doi:10.1145/361604.361612S2CID 207685720.Transcript of the 1974 Turing Award lecture.
  16. ^ Dijkstra, Edsger W; transcribed by Mario Béland (November 23, 2004) [First published December 3, 1993]. “There is still a war going on (manuscript Austin, 3 December 1993)”E. W. Dijkstra Archive. The University of Texas at Austin, Department of Computer Sciences. Retrieved February 17, 2007. When the term was coined in 1968 by F.L. Bauer of the Technological University of Munich, I welcomed it. [. . .] I interpreted the introduction of the term “software engineering” as an apt reflection of the fact that the design of software systems was an activity par excellence for the mathematical engineer. [. . .]. As soon the term arrived in the USA, it was relieved of all its technical content. It had to be so for in its original meaning it was totally unacceptable [. . .] In the meantime, software engineering has become an almost empty term, as was nicely demonstrated by Data General who overnight promoted all its programmers to the exalted rank of “software engineer”!
  17. ^ “Professional Engineers Act”. July 24, 2014.
  18. ^ “Academic Requirements”
  19. ^ “Confirmatory Exam Program”
  20. ^ “”
  21. ^ ‘Professional Engineers of Ontario’ – “Quebec Engineers win court battle against Microsoft”
  22. ^ “Lög um löggildingu nokkurra starfsheita sérfræðinga í tækni- og hönnunargreinum” (in Icelandic). Parliament of Iceland – Althing. March 11, 1996. Retrieved August 25, 2014.
  23. ^ “Lög um breytingu á lögum nr. 8/1996, um löggildingu nokkurra starfsheita sérfræðinga í tækni- og hönnunargreinum, með síðari breytingum”Alþingi. Retrieved October 3, 2016.
  24. ^ “Good Practice Guidelines for Software Engineering in New Zealand” (PDF). IPENZ.
  25. ^ U.S Department of Labor and Statistics The 2000 Standard Occupational Classification (SOC) System: 15-0000 Computer and Mathematical Occupations
  26. ^ U.S Department of Labor and Statistics The 2000 Standard Occupational Classification (SOC) System: 17-0000 Architecture and Engineering Occupations
  27. ^ Florida Board of Professional Engineering. “The 2019 Florida Statutes”.
  30. a b SC Engineering Law. “Code of Laws – Title 40 – Chapter 22 – Engineers and Surveyors”.
  31. a b AL Engineering Law. “Alabama Law Regulating Practice of Engineering and Land Surveying” (PDF).
  32. a b VW Engineering Law. “West Virginia Engineering Law Statutes and Rules”(PDF).
  33. a b OK Engineering Law. “Oklahoma Statutes, Rules and Ethics for Professional Engineers” (PDF).
  34. a b NV Engineering Law. “NRS: Chapter 625 – Professional Engineers and Land Surveyors”Unlawful practice of engineering.
  35. a b MS Engineering Law. “Part 901: Rules and Regulations of the Mississippi Board of Licensure for Professional Engineers and Surveyors” (PDF).
  36. a b IL Engineering Law. “225 ILCS 325/ Professional Engineering Practice Act of 1989”.
  37. ^ Florida Board of Professional Engineering. “Chapter 471” (PDF).
  39. ^ “New Software Engineering Exam Approved for Licensure”. IEEE Computer Society. May 4, 2012. Retrieved August 6, 2018.
  40. ^ “NCEES discontinuing PE Software Engineering exam”. National Council of Examiners for Engineering and Surveying. March 13, 2018. Retrieved August 6,2018.



Fair Use Sources:

Software Engineering

ISP – Interface segregation principle of SOLID object-oriented design

In the field of software engineering, the interface-segregation principle (ISP) states that no client should be forced to depend on methods it does not use.[1] ISP splits interfaces that are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them. Such shrunken interfaces are also called role interfaces.[2] ISP is intended to keep a system decoupled and thus easier to refactor, change, and redeploy. ISP is one of the five SOLID principles of object-oriented design, similar to the High Cohesion Principle of GRASP.[3]” (WP)

Principles of Object-Oriented Design
SSingle responsibility principle – SRP
LLiskov substitution principle – LSP
IInterface segregation principle – ISP
DDependency inversion – DI

” (WP)


Fair Use Sources:

Software Engineering

LSP- Liskov substitution principle of SOLID object-oriented design

” (WP)

Substitutability is a principle in object-oriented programming stating that, in a computer program, if S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e., an object of type T may be substituted with any object of a subtype S) without altering any of the desirable properties of the program (correctness, task performed, etc.). More formally, the Liskov substitution principle (LSP) is a particular definition of a subtyping relation, called (strongbehavioral subtyping, that was initially introduced by Barbara Liskov in a 1987 conference keynote address titled Data abstraction and hierarchy. It is a semantic rather than merely syntactic relation, because it intends to guarantee semantic interoperability of types in a hierarchy, object types in particular. Barbara Liskov and Jeannette Wing described the principle succinctly in a 1994 paper as follows:[1]

Subtype Requirement: Let {\displaystyle \phi (x)}\phi (x) be a property provable about objects {\displaystyle x}x of type T. Then {\displaystyle \phi (y)}{\displaystyle \phi (y)} should be true for objects {\displaystyle y}y of type S where S is a subtype of T.

In the same paper, Liskov and Wing detailed their notion of behavioral subtyping in an extension of Hoare logic, which bears a certain resemblance to Bertrand Meyer‘s design by contract in that it considers the interaction of subtyping with preconditionspostconditions and invariants.

Principles of Object-Oriented Design
SSingle responsibility principle – SRP
LLiskov substitution principle – LSP
IInterface segregation principle – ISP
DDependency inversion – DI

” (WP)


Fair Use Sources:

Software Engineering

Open–closed principle of SOLID object-oriented design

” (WP)

In object-oriented programming, the open–closed principle states “software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification“;[1] that is, such an entity can allow its behaviour to be extended without modifying its source code.

The name open–closed principle has been used in two ways. Both ways use generalizations (for instance, inheritance or delegate functions) to resolve the apparent dilemma, but the goals, techniques, and results are different.

Open–closed principle is one of the five SOLID principles of object-oriented design.

Principles of Object-Oriented Design
SSingle responsibility principle – SRP
LLiskov substitution principle – LSP
IInterface segregation principle – ISP
DDependency inversion – DI

” (WP)


Fair Use Sources:

Software Engineering

SRP – Single-responsibility principle of SOLID object-oriented design

“The single-responsibility principle (SRP) is a computer-programming principle that states that every moduleclass or function in a computer program should have responsibility over a single part of that program’s functionality, and it should encapsulate that part. All of that module, class or function’s services should be narrowly aligned with that responsibility.[1]” (WP)

Robert C. Martin, the originator of the term, expresses the principle as, “A class should have only one reason to change,”[1] although, because of confusion around the word “reason” he more recently stated “This principle is about people.”[2]” (WP)

Principles of Object-Oriented Design
SSingle responsibility principle – SRP
LLiskov substitution principle – LSP
IInterface segregation principle – ISP
DDependency inversion – DI

” (WP)


Fair Use Sources:

Software Engineering

SOLID (object-oriented design)

This article is about the SOLID principles of object-oriented programming. For the fundamental state of matter, see Solid. For other uses, see Solid (disambiguation).

Principles of Object-Oriented Design
SSingle responsibility principle – SRP
LLiskov substitution principle – LSP
IInterface segregation principle – ISP
DDependency inversion – DI

“In object-oriented computer programmingSOLID is a mnemonic acronym for five design principles intended to make software designs more understandable, flexible, and maintainable. The principles are a subset of many principles promoted by American software engineer and instructor Robert C. Martin,[1][2][3] first introduced in his 2000 paper Design Principles and Design Patterns.[2][4]” (WP)

The SOLID concepts are:

The SOLID acronym was introduced later, around 2004, by Michael Feathers.[11]

“Although the SOLID principles apply to any object-oriented design, they can also form a core philosophy for methodologies such as agile development or adaptive software development.[3]” (WP)

See also


  1. ^ Robert C. Martin“Principles Of OOD” Retrieved 2014-07-17.. (Note the reference to “the first five principles”, although the acronym is not used in this article.) Dates back to at least 2003.
  2. a b Robert C. Martin. “Getting a SOLID start” Retrieved 2013-08-19.
  3. a b Sandi Metz (May 2009). “SOLID Object-Oriented Design”. Retrieved 2019-08-13. Talk given at the 2009 Gotham Ruby Conference.
  4. a b c Martin, Robert C. (2000). “Design Principles and Design Patterns” (PDF). Archived from the original (PDF) on 2015-09-06.
  5. ^ “Single Responsibility Principle” (PDF). Archived from the original (PDF) on 2 February 2015.
  6. ^ Martin, Robert C. (2003). Agile Software Development, Principles, Patterns, and Practices. Prentice Hall. p. 95. ISBN 978-0135974445.
  7. ^ “Open/Closed Principle” (PDF). Archived from the original (PDF) on 5 September 2015.
  8. ^ “Liskov Substitution Principle” (PDF). Archived from the original (PDF) on 5 September 2015.
  9. ^ “Interface Segregation Principle” (PDF). 1996. Archived from the original (PDF) on 5 September 2015.
  10. ^ “Dependency Inversion Principle” (PDF). Archived from the original (PDF) on 5 September 2015.
  11. ^ Martin, Robert (2018). Clean Architecture: A Craftsman’s Guide to Software Structure and Design. p. 58. ISBN 9780134494166.



Fair Use Sources:

Software Engineering

DI – Dependency inversion principle of SOLID object-oriented design

“In object-oriented design, the dependency inversion principle is a specific form of loosely coupling software modules. When following this principle, the conventional dependency relationships established from high-level, policy-setting modules to low-level, dependency modules are reversed, thus rendering high-level modules independent of the low-level module implementation details. The principle states:[1]” (WP)

  1. High-level modules should not depend on low-level modules. Both should depend on abstractions (e.g., interfaces).
  2. Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions.
Principles of Object-Oriented Design
SSingle responsibility principle – SRP
LLiskov substitution principle – LSP
IInterface segregation principle – ISP
DDependency inversion – DI

“By dictating that both high-level and low-level objects must depend on the same abstraction, this design principle inverts the way some people may think about object-oriented programming.[2]” (WP)

“The idea behind points A and B of this principle is that when designing the interaction between a high-level module and a low-level one, the interaction should be thought of as an abstract interaction between them. This not only has implications on the design of the high-level module, but also on the low-level one: the low-level one should be designed with the interaction in mind and it may be necessary to change its usage interface.” (WP)

“In many cases, thinking about the interaction in itself as an abstract concept allows the coupling of the components to be reduced without introducing additional coding patterns, allowing only a lighter and less implementation-dependent interaction schema.” (WP)

“When the discovered abstract interaction schema(s) between two modules is/are generic and generalization makes sense, this design principle also leads to the following dependency inversion coding pattern.” (WP)

Traditional layers pattern

In conventional application architecture, lower-level components (e.g., Utility Layer) are designed to be consumed by higher-level components (e.g., Policy Layer) which enable increasingly complex systems to be built. In this composition, higher-level components depend directly upon lower-level components to achieve some task. This dependency upon lower-level components limits the reuse opportunities of the higher-level components.[1]

Traditional Layers Pattern.png

The goal of the dependency inversion pattern is to avoid this highly coupled distribution with the mediation of an abstract layer, and to increase the re-usability of higher/policy layers.

Dependency inversion pattern

With the addition of an abstract layer, both high- and lower-level layers reduce the traditional dependencies from top to bottom. Nevertheless, the “inversion” concept does not mean that lower-level layers depend on higher-level layers. Both layers should depend on abstractions that draw the behavior needed by higher-level layers.


In a direct application of dependency inversion, the abstracts are owned by the upper/policy layers. This architecture groups the higher/policy components and the abstractions that define lower services together in the same package. The lower-level layers are created by inheritance/implementation of these abstract classes or interfaces.[1]

The inversion of the dependencies and ownership encourages the re-usability of the higher/policy layers. Upper layers could use other implementations of the lower services. When the lower-level layer components are closed or when the application requires the reuse of existing services, it is common that an Adapter mediates between the services and the abstractions.

Dependency inversion pattern generalization

In many projects the dependency inversion principle and pattern are considered as a single concept that should be generalized, i.e., applied to all interfaces between software modules. There are at least two reasons for that:

  1. It is simpler to see a good thinking principle as a coding pattern. Once an abstract class or an interface has been coded, the programmer may say: “I have done the job of abstraction”.
  2. Because many unit testing tools rely on inheritance to accomplish mocking, the usage of generic interfaces between classes (not only between modules when it makes sense to use generality) became the rule.

If the mocking tool used relies only on inheritance, it may become necessary to widely apply the dependency inversion pattern. This has major drawbacks:

  1. Merely implementing an interface over a class isn’t sufficient to reduce coupling; only thinking about the potential abstraction of interactions can lead to a less coupled design.
  2. Implementing generic interfaces everywhere in a project makes it harder to understand and maintain. At each step the reader will ask themself what are the other implementations of this interface and the response is generally: only mocks.
  3. The interface generalization requires more plumbing code, in particular factories that generally rely on a dependency-injection framework.
  4. Interface generalization also restricts the usage of the programming language.

Generalization restrictions

The presence of interfaces to accomplish the Dependency Inversion Pattern (DIP) has other design implications in an object-oriented program:

  • All member variables in a class must be interfaces or abstracts.
  • All concrete class packages must connect only through interface or abstract class packages.
  • No class should derive from a concrete class.
  • No method should override an implemented method.[1]
  • All variable instantiation requires the implementation of a creational pattern such as the factory method or the factory pattern, or the use of a dependency-injection framework.

Interface mocking restrictions

Using inheritance-based mocking tools also introduces restrictions:

  • Static externally visible members should systematically rely on dependency injection making them far harder to implement.
  • All testable methods should become an interface implementation or an override of an abstract definition.

Future directions

Principles are ways of thinking. Patterns are common ways to solve problems. Coding patterns may be missing programming language features.

  • Programming languages will continue to evolve to allow them to enforce stronger and more precise usage contracts in at least two directions: enforcing usage conditions (pre-, post- and invariant conditions) and state-based interfaces. This will probably encourage and potentially simplify a stronger application of the dependency inversion pattern in many situations.
  • More and more mocking tools now use dependency-injection to solve the problem of replacing static and non virtual members. Programming languages will probably evolve to generate mocking-compatible bytecode. One direction will be to restrict the usage of non-virtual members. The other one will be to generate, at least in test situations, bytecode allowing non-inheritance based mocking.


Two common implementations of DIP use similar logical architecture but with different implications.

A direct implementation packages the policy classes with service abstracts classes in one library. In this implementation high-level components and low-level components are distributed into separate packages/libraries, where the interfaces defining the behavior/services required by the high-level component are owned by, and exist within the high-level component’s library. The implementation of the high-level component’s interface by the low-level component requires that the low-level component package depend upon the high-level component for compilation, thus inverting the conventional dependency relationship.

Dependency inversion.png

Figures 1 and 2 illustrate code with the same functionality, however in Figure 2, an interface has been used to invert the dependency. The direction of dependency can be chosen to maximize policy code reuse, and eliminate cyclic dependencies.

In this version of DIP, the lower layer component’s dependency on the interfaces/abstracts in the higher-level layers makes re-utilization of the lower layer components difficult. This implementation instead ″inverts″ the traditional dependency from top-to-bottom to the opposite, from bottom-to-top.

A more flexible solution extracts the abstract components into an independent set of packages/libraries:

DIPLayersPattern v2.png

The separation of each layer into its own package encourages re-utilization of any layer, providing robustness and mobility.[1]


Genealogical module

A genealogical system may represent relationships between people as a graph of direct relationships between them (father-son, father-daughter, mother-son, mother-daughter, husband-wife, wife-husband, etc.). This is very efficient and extensible, as it is easy to add an ex-husband or a legal guardian.

But some higher-level modules may require a simpler way to browse the system: any person may have children, parents, siblings (including half-brothers and -sisters or not), grandparents, cousins, and so on.

Depending on the usage of the genealogical module, presenting common relationships as distinct direct properties (hiding the graph) will make the coupling between a higher-level module and the genealogical module much lighter and allow one to change the internal representation of the direct relationships completely without any effect on the modules using them. It also permits embedding exact definitions of siblings or uncles in the genealogical module, thus enforcing the single responsibility principle.

Finally, if the first extensible generalized graph approach seems the most extensible, the usage of the genealogical module may show that a more specialized and simpler relationship implementation is sufficient for the application(s) and helps create a more efficient system.

In this example, abstracting the interaction between the modules leads to a simplified interface of the lower-level module and may lead to a simpler implementation of it.

Remote file server client

Imagine you have to implement a client to a remote file server (FTP, cloud storage …). You may think of it as a set of abstract interfaces:

  1. Connection/Disconnection (a connection persistence layer may be needed)
  2. Folder/tags creation/rename/delete/list interface
  3. File creation/replacement/rename/delete/read interface
  4. File searching
  5. Concurrent replacement or delete resolution
  6. File history management …

If both local files and remote files offers the same abstract interfaces, any high-level module using local files and fully implementing the dependency inversion pattern will be able to access local and remote files indiscriminately.

Local disk will generally use folder, remote storage may use folder and/or tags. You have to decide how to unify them if possible.

On remote file we may have to use only create or replace: remote files update do not necessarily make sense because random update is too slow comparing local file random update and may be very complicated to implement). On remote file we may need partial read and write (at least inside the remote file module to allow download or upload to resume after a communication interruption), but random read isn’t adapted (except if a local cache is used).

File searching may be pluggable : file searching can rely on the OS or in particular for tag or full text search, be implemented with distinct systems (OS embedded, or available separately).

Concurrent replacement or delete resolution detection may impact the other abstract interfaces.

When designing the remote file server client for each conceptual interface you have to ask yourself the level of service your high level modules require (not necessary all of them) and not only how to implement the remote file server functionalities but maybe how to make the file services in your application compatible between already implemented file services (local files, existing cloud clients) and your new remote file server client.

Once you have designed the abstract interfaces required, your remote file server client should implement these interfaces. And because you probably restricted some local functionalities existing on local file (for example file update), you may have to write adapters for local or other existing used remote file access modules each offering the same abstract interfaces. You also have to write your own file access enumerator allowing to retrieve all file compatible systems available and configured on your computer.

Once you do that, your application will be able to save its documents locally or remotely transparently. Or simpler, the high level module using the new file access interfaces can be used indistinctly in local or remote file access scenarios making it reusable.

Remark: many OSes have started to implement these kind of functionalities and your work may be limited to adapt your new client to this already abstracted models.

In this example, thinking of the module as a set of abstract interfaces, and adapting other modules to this set of interfaces, allows you to provide a common interface for many file storage systems.

Model View Controller

Example of DIP

UI and ApplicationLayer packages contains mainly concrete classes. Controllers contains abstracts/interface types. UI has an instance of ICustomerHandler. All packages are physically separated. In the ApplicationLayer there is a concrete implementation that Page class will use. Instances of this interface are created dynamically by a Factory (possibly in the same Controllers package). The concrete types, Page and CustomerHandler, don’t depend on each other; both depend on ICustomerHandler.

The direct effect is that the UI doesn’t need to reference the ApplicationLayer or any concrete package that implements the ICustomerHandler. The concrete class will be loaded using reflection. At any moment the concrete implementation could be replaced by another concrete implementation without changing the UI class. Another interesting possibility is that the Page class implements an interface IPageViewer that could be passed as an argument to ICustomerHandler methods. Then the concrete implementation could communicate with UI without a concrete dependency. Again, both are linked by interfaces.

Related patterns

Applying the dependency inversion principle can also be seen as an example of the adapter pattern, i.e. the high-level class defines its own adapter interface which is the abstraction that the other high-level classes depend on. The adaptee implementation also depends on the adapter interface abstraction (of course, since it implements its interface) while it can be implemented by using code from within its own low-level module. The high-level has no dependency on the low-level module since it only uses the low-level indirectly through the adapter interface by invoking polymorphic methods to the interface which are implemented by the adaptee and its low-level module.

Various patterns such as Plugin, Service Locator, or Dependency injection are employed to facilitate the run-time provisioning of the chosen low-level component implementation to the high-level component.


The dependency inversion principle was postulated by Robert C. Martin and described in several publications including the paper Object Oriented Design Quality Metrics: an analysis of dependencies,[3] an article appearing in the C++ Report in May 1996 entitled The Dependency Inversion Principle,[4] and the books Agile Software Development, Principles, Patterns, and Practices,[1] and Agile Principles, Patterns, and Practices in C#.

See also


  1. a b c d e f Martin, Robert C. (2003). Agile Software Development, Principles, Patterns, and Practices. Prentice Hall. pp. 127–131. ISBN 978-0135974445.
  2. ^ Freeman, Eric; Freeman, Elisabeth; Kathy, Sierra; Bert, Bates (2004). Hendrickson, Mike; Loukides, Mike (eds.). Head First Design Patterns (paperback). 1. O’REILLY. ISBN 978-0-596-00712-6. Retrieved 2012-06-21.
  3. ^ Martin, Robert C. (October 1994). “Object Oriented Design Quality Metrics: An analysis of dependencies” (PDF). Retrieved 2016-10-15.
  4. ^ Martin, Robert C. (May 1996). “The Dependency Inversion Principle” (PDF). C++ Report. Archived from the original (PDF) on 2011-07-14.

External links


” (WP)


Fair Use Sources:

Bibliography Java Software Engineering

Java Cookbook – Problems and Solutions for Java Developers

See also Java Programming Language, Java Glossary, Java Bibliography, Java Reference materials

Java Cookbook – Problems and Solutions for Java Developers, 4th Edition, by Ian F. Darwin, 2020, B08651PDL6 (JvCkbk)

Fair Use Source: B08651PDL6 (JvCkbk)

About This Book:

Java continues to grow and evolve, and this cookbook continues to evolve in tandem. With this guide, you’ll get up to speed right away with hundreds of hands-on recipes across a broad range of Java topics. You’ll learn useful techniques for everything from string handling and functional programming to network communication.

Each recipe includes self-contained code solutions that you can freely use, along with a discussion of how and why they work. If you’re familiar with Java basics, this cookbook will bolster your knowledge of the language and its many recent changes, including how to apply them in your day-to-day development. This updated edition covers changes through Java 12 and parts of 13 and 14.

Recipes include:

  • Methods for compiling, running, and debugging
  • Packaging Java classes and building applications
  • Manipulating, comparing, and rearranging text
  • Regular expressions for string and pattern matching
  • Handling numbers, dates, and times
  • Structuring data with collections, arrays, and other types
  • Object-oriented and functional programming techniques
  • Input/output, directory, and filesystem operations
  • Network programming on both client and server
  • Processing JSON for data interchange
  • Multithreading and concurrency
  • Using Java in big data applications
  • Interfacing Java with other languages

About the Author:

Book Details:

  • ASIN : B08651PDL6
  • Publisher : O’Reilly Media; 4th edition (March 17, 2020)
  • Publication date : March 17, 2020
  • Print length : 949 pages

Publisher Resources

Table of Contents:

Table of Contents

  1. Preface
    1. Who This Book Is For
    2. What’s in This Book?
    3. Java Books
    4. Conventions Used in This Book
    5. O’Reilly Online Learning
    6. Comments and Questions
    7. Acknowledgments
  2. 1. Getting Started: Compiling and Running Java
    1. 1.0. Introduction
    2. 1.1. Compiling and Running Java: Standard JDK
    3. 1.2. Compiling and Running Java: GraalVM for Better Performance
    4. 1.3. Compiling, Running, and Testing with an IDE
    5. 1.4. Exploring Java with JShell
    6. 1.5. Using CLASSPATH Effectively
    7. 1.6. Downloading and Using the Code Examples
    8. 1.7. Automating Dependencies, Compilation, Testing, and Deployment with Apache Maven
    9. 1.8. Automating Dependencies, Compilation, Testing, and Deployment with Gradle
    10. 1.9. Dealing with Deprecation Warnings
    11. 1.10. Maintaining Code Correctness with Unit Testing: JUnit
    12. 1.11. Maintaining Your Code with Continuous Integration
    13. 1.12. Getting Readable Stack Traces
    14. 1.13. Finding More Java Source Code
    15. 1.14. Finding Runnable Java Libraries
  3. 2. Interacting with the Environment
    1. 2.0. Introduction
    2. 2.1. Getting Environment Variables
    3. 2.2. Getting Information from System Properties
    4. 2.3. Dealing with Code That Depends on the Java Version or the Operating System
    5. 2.4. Using Extensions or Other Packaged APIs
    6. 2.5. Using the Java Modules System
  4. 3. Strings and Things
    1. 3.0. Introduction
    2. 3.1. Taking Strings Apart with Substrings or Tokenizing
    3. 3.2. Putting Strings Together with StringBuilder
    4. 3.3. Processing a String One Character at a Time
    5. 3.4. Aligning, Indenting, and Unindenting Strings
    6. 3.5. Converting Between Unicode Characters and Strings
    7. 3.6. Reversing a String by Word or by Character
    8. 3.7. Expanding and Compressing Tabs
    9. 3.8. Controlling Case
    10. 3.9. Entering Nonprintable Characters
    11. 3.10. Trimming Blanks from the End of a String
    12. 3.11. Creating a Message with I18N Resources
    13. 3.12. Using a Particular Locale
    14. 3.13. Creating a Resource Bundle
    15. 3.14. Program: A Simple Text Formatter
    16. 3.15. Program: Soundex Name Comparisons
  5. 4. Pattern Matching with Regular Expressions
    1. 4.0. Introduction
    2. 4.1. Regular Expression Syntax
    3. 4.2. Using Regexes in Java: Test for a Pattern
    4. 4.3. Finding the Matching Text
    5. 4.4. Replacing the Matched Text
    6. 4.5. Printing All Occurrences of a Pattern
    7. 4.6. Printing Lines Containing a Pattern
    8. 4.7. Controlling Case in Regular Expressions
    9. 4.8. Matching Accented, or Composite, Characters
    10. 4.9. Matching Newlines in Text
    11. 4.10. Program: Apache Logfile Parsing
    12. 4.11. Program: Full Grep
  6. 5. Numbers
    1. 5.0. Introduction
    2. 5.1. Checking Whether a String Is a Valid Number
    3. 5.2. Converting Numbers to Objects and Vice Versa
    4. 5.3. Taking a Fraction of an Integer Without Using Floating Point
    5. 5.4. Working with Floating-Point Numbers
    6. 5.5. Formatting Numbers
    7. 5.6. Converting Among Binary, Octal, Decimal, and Hexadecimal
    8. 5.7. Operating on a Series of Integers
    9. 5.8. Formatting with Correct Plurals
    10. 5.9. Generating Random Numbers
    11. 5.10. Multiplying Matrices
    12. 5.11. Using Complex Numbers
    13. 5.12. Handling Very Large Numbers
    14. 5.13. Program: TempConverter
    15. 5.14. Program: Number Palindromes
  7. 6. Dates and Times
    1. 6.0. Introduction
    2. 6.1. Finding Today’s Date
    3. 6.2. Formatting Dates and Times
    4. 6.3. Converting Among Dates/Times, YMDHMS, and Epoch Seconds
    5. 6.4. Parsing Strings into Dates
    6. 6.5. Difference Between Two Dates
    7. 6.6. Adding to or Subtracting from a Date
    8. 6.7. Handling Recurring Events
    9. 6.8. Computing Dates Involving Time Zones
    10. 6.9. Interfacing with Legacy Date and Calendar Classes
  8. 7. Structuring Data with Java
    1. 7.0. Introduction
    2. 7.1. Using Arrays for Data Structuring
    3. 7.2. Resizing an Array
    4. 7.3. The Collections Framework
    5. 7.4. Like an Array, but More Dynamic
    6. 7.5. Using Generic Types in Your Own Class
    7. 7.6. How Shall I Iterate Thee? Let Me Enumerate the Ways
    8. 7.7. Eschewing Duplicates with a Set
    9. 7.8. Structuring Data in a Linked List
    10. 7.9. Mapping with Hashtable and HashMap
    11. 7.10. Storing Strings in Properties and Preferences
    12. 7.11. Sorting a Collection
    13. 7.12. Avoiding the Urge to Sort
    14. 7.13. Finding an Object in a Collection
    15. 7.14. Converting a Collection to an Array
    16. 7.15. Making Your Data Iterable
    17. 7.16. Using a Stack of Objects
    18. 7.17. Multidimensional Structures
    19. 7.18. Simplifying Data Objects with Lombok or Record
    20. 7.19. Program: Timing Comparisons
  9. 8. Object-Oriented Techniques
    1. 8.0. Introduction
    2. 8.1. Object Methods: Formatting Objects with toString(), Comparing with Equals
    3. 8.2. Using Inner Classes
    4. 8.3. Providing Callbacks via Interfaces
    5. 8.4. Polymorphism/Abstract Methods
    6. 8.5. Using Typesafe Enumerations
    7. 8.6. Avoiding NPEs with Optional
    8. 8.7. Enforcing the Singleton Pattern
    9. 8.8. Roll Your Own Exceptions
    10. 8.9. Using Dependency Injection
    11. 8.10. Program: Plotter
  10. 9. Functional Programming Techniques: Functional Interfaces, Streams, and Parallel Collections
    1. 9.0. Introduction
    2. 9.1. Using Lambdas/Closures Instead of Inner Classes
    3. 9.2. Using Lambda Predefined Interfaces Instead of Your Own
    4. 9.3. Simplifying Processing with Streams
    5. 9.4. Simplifying Streams with Collectors
    6. 9.5. Improving Throughput with Parallel Streams and Collections
    7. 9.6. Using Existing Code as Functional with Method References
    8. 9.7. Java Mixins: Mixing in Methods
  11. 10. Input and Output: Reading, Writing, and Directory Tricks
    1. 10.0. Introduction
    2. 10.1. About InputStreams/OutputStreams and Readers/Writers
    3. 10.2. Reading a Text File
    4. 10.3. Reading from the Standard Input or from the Console/Controlling Terminal
    5. 10.4. Printing with Formatter and printf
    6. 10.5. Scanning Input with StreamTokenizer
    7. 10.6. Scanning Input with the Scanner Class
    8. 10.7. Scanning Input with Grammatical Structure
    9. 10.8. Copying a File
    10. 10.9. Reassigning the Standard Streams
    11. 10.10. Duplicating a Stream as It Is Written; Reassigning Standard Streams
    12. 10.11. Reading/Writing a Different Character Set
    13. 10.12. Those Pesky End-of-Line Characters
    14. 10.13. Beware Platform-Dependent File Code
    15. 10.14. Reading/Writing Binary Data
    16. 10.15. Reading and Writing JAR or ZIP Archives
    17. 10.16. Finding Files in a Filesystem-Neutral Way with getResource() and getResourceAsStream()
    18. 10.17. Getting File Information: Files and Path
    19. 10.18. Creating a New File or Directory
    20. 10.19. Changing a File’s Name or Other Attributes
    21. 10.20. Deleting a File
    22. 10.21. Creating a Transient/Temporary File
    23. 10.22. Listing a Directory
    24. 10.23. Getting the Directory Roots
    25. 10.24. Using the FileWatcher Service to Get Notified About File Changes
    26. 10.25. Program: Save User Data to Disk
    27. 10.26. Program: Find—Walking a File Tree
  12. 11. Data Science and R
    1. 11.1. Machine Learning with Java
    2. 11.2. Using Data In Apache Spark
    3. 11.3. Using R Interactively
    4. 11.4. Comparing/Choosing an R Implementation
    5. 11.5. Using R from Within a Java App: Renjin
    6. 11.6. Using Java from Within an R Session
    7. 11.7. Using FastR, the GraalVM Implementation of R
    8. 11.8. Using R in a Web App
  13. 12. Network Clients
    1. 12.0. Introduction
    2. 12.1. HTTP/REST Web Client
    3. 12.2. Contacting a Socket Server
    4. 12.3. Finding and Reporting Network Addresses
    5. 12.4. Handling Network Errors
    6. 12.5. Reading and Writing Textual Data
    7. 12.6. Reading and Writing Binary or Serialized Data
    8. 12.7. UDP Datagrams
    9. 12.8. URI, URL, or URN?
    10. 12.9. Program: TFTP UDP Client
    11. 12.10. Program: Sockets-Based Chat Client
    12. 12.11. Program: Simple HTTP Link Checker
  14. 13. Server-Side Java
    1. 13.0. Introduction
    2. 13.1. Opening a Server Socket for Business
    3. 13.2. Finding Network Interfaces
    4. 13.3. Returning a Response (String or Binary)
    5. 13.4. Returning Object Information Across a Network Connection
    6. 13.5. Handling Multiple Clients
    7. 13.6. Serving the HTTP Protocol
    8. 13.7. Securing a Web Server with SSL and JSSE
    9. 13.8. Creating a REST Service with JAX-RS
    10. 13.9. Network Logging
    11. 13.10. Setting Up SLF4J
    12. 13.11. Network Logging with Log4j
    13. 13.12. Network Logging with java.util.logging
  15. 14. Processing JSON Data
    1. 14.0. Introduction
    2. 14.1. Generating JSON Directly
    3. 14.2. Parsing and Writing JSON with Jackson
    4. 14.3. Parsing and Writing JSON with org.json
    5. 14.4. Parsing and Writing JSON with JSON-B
    6. 14.5. Finding JSON Elements with JSON Pointer
  16. 15. Packages and Packaging
    1. 15.0. Introduction
    2. 15.1. Creating a Package
    3. 15.2. Documenting Classes with Javadoc
    4. 15.3. Beyond Javadoc: Annotations/Metadata
    5. 15.4. Preparing a Class as a JavaBean
    6. 15.5. Archiving with JAR
    7. 15.6. Running a Program from a JAR
    8. 15.7. Packaging Web Tier Components into a WAR File
    9. 15.8. Creating a Smaller Distribution with jlink
    10. 15.9. Using JPMS to Create a Module
  17. 16. Threaded Java
    1. 16.0. Introduction
    2. 16.1. Running Code in a Different Thread
    3. 16.2. Displaying a Moving Image with Animation
    4. 16.3. Stopping a Thread
    5. 16.4. Rendezvous and Timeouts
    6. 16.5. Synchronizing Threads with the synchronized Keyword
    7. 16.6. Simplifying Synchronization with Locks
    8. 16.7. Simplifying Producer/Consumer with the Queue Interface
    9. 16.8. Optimizing Parallel Processing with Fork/Join
    10. 16.9. Scheduling Tasks: Future Times, Background Saving in an Editor
  18. 17. Reflection, or “A Class Named Class”
    1. 17.0. Introduction
    2. 17.1. Getting a Class Descriptor
    3. 17.2. Finding and Using Methods and Fields
    4. 17.3. Accessing Private Methods and Fields via Reflection
    5. 17.4. Loading and Instantiating a Class Dynamically
    6. 17.5. Constructing a Class from Scratch with a ClassLoader
    7. 17.6. Constructing a Class from Scratch with JavaCompiler
    8. 17.7. Performance Timing
    9. 17.8. Printing Class Information
    10. 17.9. Listing Classes in a Package
    11. 17.10. Using and Defining Annotations
    12. 17.11. Finding Plug-In-Like Classes via Annotations
    13. 17.12. Program: CrossRef
  19. 18. Using Java with Other Languages
    1. 18.0. Introduction
    2. 18.1. Running an External Program from Java
    3. 18.2. Running a Program and Capturing Its Output
    4. 18.3. Calling Other Languages via javax.script
    5. 18.4. Mixing Languages with GraalVM
    6. 18.5. Marrying Java and Perl
    7. 18.6. Calling Other Languages via Native Code
    8. 18.7. Calling Java from Native Code
  20. Afterword
  21. Java Then and Now
    1. Introduction: Always in Motion the Java Is
    2. What Was New in Java 8
    3. What Was New in Java 9
    4. What Was New in Java 10 (March 2018)
    5. What Was New in Java 11 (September 2018)
    6. What Was New in Java 12 (March 2019)
    7. What Is New in Java 13 (September 2019)
    8. Looking Ahead
  22. Index


Fair Use Sources:



See: Java Cookbook – Problems and Solutions for Java Developers, 4th Edition, by Ian F. Darwin, 2020

Fair Use Source: B08651PDL6 (JvCkbk)

Bibliography Java Software Engineering

Java – A Beginner’s Guide, by Herbert Schildt

See also: Java – The Complete Reference, Java Programming Language, Java Glossary, Java Bibliography, Java Reference materials

Java – A Beginner’s Guide, 8th Edition, by Herbert Schildt, 2018, B07J2ZZ29H (JvBgnGd)

Fair Use Source: B07J2ZZ29H (JvBgnGd)

About This Book:

A practical introduction to Java programming—fully revised for long-term support release Java SE 11

Thoroughly updated for Java Platform Standard Edition 11, this hands-on resource shows, step by step, how to get started programming in Java from the very first chapter. Written by Java guru Herbert Schildt, the book starts with the basics, such as how to create, compile, and run a Java program. From there, you will learn essential Java keywords, syntax, and commands.

Java: A Beginner’s Guide, Eighth Edition covers the basics and touches on advanced features, including multithreaded programming, generics, Lambda expressions, and Swing. Enumeration, modules, and interface methods are also clearly explained. This Oracle Press guide delivers the appropriate mix of theory and practical coding necessary to get you up and running developing Java applications in no time.

  • Clearly explains all of the new Java SE 11 features
  • Features self-tests, exercises, and downloadable code samples
  • Written by bestselling author and leading Java authority Herbert Schildt

About the Author:

Herbert Schildt is one of the world’s leading programming authors and has written extensively on Java, C, C++, and C#. His books have sold millions of copies worldwide. Herb’s acclaimed books include Java: The Complete Reference, Java: A Beginner’s Guide, C: The Complete Reference, C++: The Complete Reference and C#: The Complete Reference

Book Details:

  • ASIN : B07J2ZZ29H
  • Publisher : McGraw-Hill Education; 8th edition (November 9, 2018)
  • Publication date : November 9, 2018
  • Print length : 720 pages

Table of Contents:

Published by McGraw-Hill, 2018

  1. Cover (01:09 mins)
  2. Title Page (01:09 mins)
  3. Copyright Page (03:27 mins)
  4. Contents at a Glance (01:09 mins)
  5. Contents (09:12 mins)
  6. Introduction (12:39 mins)
  7. 1 Java Fundamentals (60:57 mins)
  8. 2 Introducing Data Types and Operators (46:00 mins)
  9. 3 Program Control Statements (56:21 mins)
  10. 4 Introducing Classes, Objects, and Methods (43:42 mins)
  11. 5 More Data Types and Operators (75:54 mins)
  12. 6 A Closer Look at Methods and Classes (67:51 mins)
  13. 7 Inheritance (64:24 mins)
  14. 8 Packages and Interfaces (56:21 mins)
  15. 9 Exception Handling (42:33 mins)
  16. 10 Using I/O (66:42 mins)
  17. 11 Multithreaded Programming (66:42 mins)
  18. 12 Enumerations, Autoboxing, Static Import, and Annotations (44:51 mins)
  19. 13 Generics (57:30 mins)
  20. 14 Lambda Expressions and Method References (50:36 mins)
  21. 15 Modules (50:36 mins)
  22. 16 Introducing Swing (58:39 mins)
  23. A Answers to Self Tests (70:09 mins)
  24. B Using Java’s Documentation Comments (10:21 mins)
  25. C Compile and Run Simple Single-File Programs in One Step (03:27 mins)
  26. D Introducing JShell (17:15 mins)
  27. E More Java Keywords (06:54 mins)
  28. Index (29:54 mins)

Detailed Table of Contents

1 Java Fundamentals

  1. The History and Philosophy of Java
    1. The Origins of Java
    2. Java’s Lineage: C and C++
    3. How Java Impacted the Internet
    4. Java’s Magic: The Bytecode
    5. Moving Beyond Applets
    6. A Faster Release Schedule
    7. The Java Buzzwords
  2. Object-Oriented Programming
    1. Encapsulation
    2. Polymorphism
    3. Inheritance
  3. The Java Development Kit
  4. A First Simple Program
    1. Entering the Program
    2. Compiling the Program
    3. The First Sample Program Line by Line
  5. Handling Syntax Errors
  6. A Second Simple Program
  7. Another Data Type
  8. Try This 1-1: Converting Gallons to Liters
  9. Two Control Statements
    1. The if Statement
    2. The for Loop
  10. Create Blocks of Code
  11. Semicolons and Positioning
  12. Indentation Practices
  13. Try This 1-2: Improving the Gallons-to-Liters Converter
  14. The Java Keywords
  15. Identifiers in Java
  16. The Java Class Libraries
  17. Chapter 1 Self Test

2 Introducing Data Types and Operators

  1. Why Data Types Are Important
  2. Java’s Primitive Types
    1. Integers
    2. Floating-Point Types
    3. Characters
  3. The Boolean Type
  4. Try This 2-1: How Far Away Is the Lightning?
  5. Literals
    1. Hexadecimal, Octal, and Binary Literals
    2. Character Escape Sequences
    3. String Literals
  6. A Closer Look at Variables
    1. Initializing a Variable
    2. Dynamic Initialization
  7. The Scope and Lifetime of Variables
  8. Operators
  9. Arithmetic Operators
    1. Increment and Decrement
  10. Relational and Logical Operators
  11. Short-Circuit Logical Operators
  12. The Assignment Operator
  13. Shorthand Assignments
  14. Type Conversion in Assignments
  15. Casting Incompatible Types
  16. Operator Precedence
  17. Try This 2-2: Display a Truth Table for the Logical Operators
  18. Expressions
    1. Type Conversion in Expressions
    2. Spacing and Parentheses
  19. Chapter 2 Self Test

3 Program Control Statements

  1. Input Characters from the Keyboard
  2. The if Statement
  3. Nested ifs
  4. The if-else-if Ladder
  5. The switch Statement
  6. Nested switch Statements
  7. Try This 3-1: Start Building a Java Help System
  8. The for Loop
  9. Some Variations on the for Loop
  10. Missing Pieces
    1. The Infinite Loop
  11. Loops with No Body
  12. Declaring Loop Control Variables Inside the for Loop
  13. The Enhanced for Loop
  14. The while Loop
  15. The do-while Loop
  16. Try This 3-2: Improve the Java Help System
  17. Use break to Exit a Loop
  18. Use break as a Form of goto
  19. Use continue
  20. Try This 3-3: Finish the Java Help System
  21. Nested Loops
  22. Chapter 3 Self Test

4 Introducing Classes, Objects, and Methods

  1. Class Fundamentals
    1. The General Form of a Class
    2. Defining a Class
  2. How Objects Are Created
  3. Reference Variables and Assignment
  4. Methods
    1. Adding a Method to the Vehicle Class
  5. Returning from a Method
  6. Returning a Value
  7. Using Parameters
    1. Adding a Parameterized Method to Vehicle
  8. Try This 4-1: Creating a Help Class
  9. Constructors
  10. Parameterized Constructors
  11. Adding a Constructor to the Vehicle Class
  12. The new Operator Revisited
  13. Garbage Collection
  14. The this Keyword
  15. Chapter 4 Self Test

5 More Data Types and Operators

  1. Arrays
    1. One-Dimensional Arrays
  2. Try This 5-1: Sorting an Array
  3. Multidimensional Arrays
    1. Two-Dimensional Arrays
    2. Irregular Arrays
    3. Arrays of Three or More Dimensions
    4. Initializing Multidimensional Arrays
  4. Alternative Array Declaration Syntax
  5. Assigning Array References
  6. Using the length Member
  7. Try This 5-2: A Queue Class
  8. The For-Each Style for Loop
    1. Iterating Over Multidimensional Arrays
    2. Applying the Enhanced for
  9. Strings
    1. Constructing Strings
    2. Operating on Strings
    3. Arrays of Strings
    4. Strings Are Immutable
    5. Using a String to Control a switch Statement
  10. Using Command-Line Arguments
  11. Using Type Inference with Local Variables
    1. Local Variable Type Inference with Reference Types
    2. Using Local Variable Type Inference in a for Loop
    3. Some var Restrictions
  12. The Bitwise Operators
    1. The Bitwise AND, OR, XOR, and NOT Operators
    2. The Shift Operators
    3. Bitwise Shorthand Assignments
  13. Try This 5-3: A ShowBits Class
  14. The ? Operator
  15. Chapter 5 Self Test

6 A Closer Look at Methods and Classes

  1. Controlling Access to Class Members
    1. Java’s Access Modifiers
  2. Try This 6-1: Improving the Queue Class
  3. Pass Objects to Methods
    1. How Arguments Are Passed
  4. Returning Objects
  5. Method Overloading
  6. Overloading Constructors
  7. Try This 6-2: Overloading the Queue Constructor
  8. Recursion
  9. Understanding static
    1. Static Blocks
  10. Try This 6-3: The Quicksort
  11. Introducing Nested and Inner Classes
  12. Varargs: Variable-Length Arguments
    1. Varargs Basics
    2. Overloading Varargs Methods
    3. Varargs and Ambiguity
  13. Chapter 6 Self Test

7 Inheritance

  1. Inheritance Basics
  2. Member Access and Inheritance
  3. Constructors and Inheritance
  4. Using super to Call Superclass Constructors
  5. Using super to Access Superclass Members
  6. Try This 7-1: Extending the Vehicle Class
  7. Creating a Multilevel Hierarchy
  8. When Are Constructors Executed?
  9. Superclass References and Subclass Objects
  10. Method Overriding
  11. Overridden Methods Support Polymorphism
  12. Why Overridden Methods?
    1. Applying Method Overriding to TwoDShape
  13. Using Abstract Classes
  14. Using final
    1. final Prevents Overriding
    2. final Prevents Inheritance
    3. Using final with Data Members
  15. The Object Class
  16. Chapter 7 Self Test

8 Packages and Interfaces

  1. Packages
    1. Defining a Package
    2. Finding Packages and CLASSPATH
    3. A Short Package Example
  2. Packages and Member Access
    1. A Package Access Example
  3. Understanding Protected Members
  4. Importing Packages
  5. Java’s Class Library Is Contained in Packages
  6. Interfaces
  7. Implementing Interfaces
  8. Using Interface References
  9. Try This 8-1: Creating a Queue Interface
  10. Variables in Interfaces
  11. Interfaces Can Be Extended
  12. Default Interface Methods
    1. Default Method Fundamentals
    2. A More Practical Example of a Default Method
    3. Multiple Inheritance Issues
  13. Use static Methods in an Interface
  14. Private Interface Methods
  15. Final Thoughts on Packages and Interfaces
  16. Chapter 8 Self Test

9 Exception Handling

  1. The Exception Hierarchy
  2. Exception Handling Fundamentals
    1. Using try and catch
    2. A Simple Exception Example
  3. The Consequences of an Uncaught Exception
    1. Exceptions Enable You to Handle Errors Gracefully
  4. Using Multiple catch Statements
  5. Catching Subclass Exceptions
  6. Try Blocks Can Be Nested
  7. Throwing an Exception
    1. Rethrowing an Exception
  8. A Closer Look at Throwable
  9. Using finally
  10. Using throws
  11. Three Additional Exception Features
  12. Java’s Built-in Exceptions
  13. Creating Exception Subclasses
  14. Try This 9-1: Adding Exceptions to the Queue Class
  15. Chapter 9 Self Test

10 Using I/O

  1. Java’s I/O Is Built upon Streams
  2. Byte Streams and Character Streams
  3. The Byte Stream Classes
  4. The Character Stream Classes
  5. The Predefined Streams
  6. Using the Byte Streams
    1. Reading Console Input
    2. Writing Console Output
  7. Reading and Writing Files Using Byte Streams
    1. Inputting from a File
    2. Writing to a File
  8. Automatically Closing a File
  9. Reading and Writing Binary Data
  10. Try This 10-1: A File Comparison Utility
  11. Random-Access Files
  12. Using Java’s Character-Based Streams
    1. Console Input Using Character Streams
    2. Console Output Using Character Streams
  13. File I/O Using Character Streams
    1. Using a FileWriter
    2. Using a FileReader
  14. Using Java’s Type Wrappers to Convert Numeric Strings
  15. Try This 10-2: Creating a Disk-Based Help System
  16. Chapter 10 Self Test

11 Multithreaded Programming

  1. Multithreading Fundamentals
  2. The Thread Class and Runnable Interface
  3. Creating a Thread
    1. One Improvement and Two Simple Variations
  4. Try This 11-1: Extending Thread
  5. Creating Multiple Threads
  6. Determining When a Thread Ends
  7. Thread Priorities
  8. Synchronization
  9. Using Synchronized Methods
  10. The synchronized Statement
  11. Thread Communication Using notify( ), wait( ), and notifyAll( )
    1. An Example That Uses wait( ) and notify( )
  12. Suspending, Resuming, and Stopping Threads
  13. Try This 11-2: Using the Main Thread
  14. Chapter 11 Self Test

12 Enumerations, Autoboxing, Static Import, and Annotations

  1. Enumerations
    1. Enumeration Fundamentals
  2. Java Enumerations Are Class Types
  3. The values( ) and valueOf( ) Methods
  4. Constructors, Methods, Instance Variables, and Enumerations
    1. Two Important Restrictions
  5. Enumerations Inherit Enum
  6. Try This 12-1: A Computer-Controlled Traffic Light
  7. Autoboxing
  8. Type Wrappers
  9. Autoboxing Fundamentals
  10. Autoboxing and Methods
  11. Autoboxing/Unboxing Occurs in Expressions
    1. A Word of Warning
  12. Static Import
  13. Annotations (Metadata)
  14. Chapter 12 Self Test

13 Generics

  1. Generics Fundamentals
  2. A Simple Generics Example
    1. Generics Work Only with Reference Types
    2. Generic Types Differ Based on Their Type Arguments
    3. A Generic Class with Two Type Parameters
    4. The General Form of a Generic Class
  3. Bounded Types
  4. Using Wildcard Arguments
  5. Bounded Wildcards
  6. Generic Methods
  7. Generic Constructors
  8. Generic Interfaces
  9. Try This 13-1: Create a Generic Queue
  10. Raw Types and Legacy Code
  11. Type Inference with the Diamond Operator
  12. Local Variable Type Inference and Generics
  13. Erasure
  14. Ambiguity Errors
  15. Some Generic Restrictions
    1. Type Parameters Can’t Be Instantiated
    2. Restrictions on Static Members
    3. Generic Array Restrictions
    4. Generic Exception Restriction
  16. Continuing Your Study of Generics
  17. Chapter 13 Self Test

14 Lambda Expressions and Method References

  1. Introducing Lambda Expressions
    1. Lambda Expression Fundamentals
    2. Functional Interfaces
    3. Lambda Expressions in Action
  2. Block Lambda Expressions
  3. Generic Functional Interfaces
  4. Try This 14-1: Pass a Lambda Expression as an Argument
  5. Lambda Expressions and Variable Capture
  6. Throw an Exception from Within a Lambda Expression
  7. Method References
    1. Method References to static Methods
    2. Method References to Instance Methods
  8. Constructor References
  9. Predefined Functional Interfaces
  10. Chapter 14 Self Test

15 Modules

  1. Module Basics
    1. A Simple Module Example
    2. Compile and Run the First Module Example
    3. A Closer Look at requires and exports
  2. java.base and the Platform Modules
  3. Legacy Code and the Unnamed Module
  4. Exporting to a Specific Module
  5. Using requires transitive
  6. Try This 15-1: Experiment with requires transitive
  7. Use Services
    1. Service and Service Provider Basics
    2. The Service-Based Keywords
    3. A Module-Based Service Example
  8. Additional Module Features
    1. Open Modules
    2. The opens Statement
    3. requires static
  9. Continuing Your Study of Modules
  10. Chapter 15 Self Test

16 Introducing Swing

  1. The Origins and Design Philosophy of Swing
  2. Components and Containers
    1. Components
    2. Containers
    3. The Top-Level Container Panes
  3. Layout Managers
  4. A First Simple Swing Program
    1. The First Swing Example Line by Line
  5. Swing Event Handling
    1. Events
    2. Event Sources
    3. Event Listeners
    4. Event Classes and Listener Interfaces
  6. Use JButton
  7. Work with JTextField
  8. Create a JCheckBox
  9. Work with JList
  10. Try This 16-1: A Swing-Based File Comparison Utility
  11. Use Anonymous Inner Classes or Lambda Expressions to Handle Events
  12. Chapter 16 Self Test

A Answers to Self Tests

  1. Chapter 1: Java Fundamentals
  2. Chapter 2: Introducing Data Types and Operators
  3. Chapter 3: Program Control Statements
  4. Chapter 4: Introducing Classes, Objects, and Methods
  5. Chapter 5: More Data Types and Operators
  6. Chapter 6: A Closer Look at Methods and Classes
  7. Chapter 7: Inheritance
  8. Chapter 8: Packages and Interfaces
  9. Chapter 9: Exception Handling
  10. Chapter 10: Using I/O
  11. Chapter 11: Multithreaded Programming
  12. Chapter 12: Enumerations, Autoboxing, Static Import, and Annotations
  13. Chapter 13: Generics
  14. Chapter 14: Lambda Expressions and Method References
  15. Chapter 15: Modules
  16. Chapter 16: Introducing Swing

B Using Java’s Documentation Comments

  1. The javadoc Tags
    1. @author
    2. {@code}
    3. @deprecated
    4. {@docRoot}
    5. @exception
    6. @hidden
    7. {@index}
    8. {@inheritDoc}
    9. {@link}
    10. {@linkplain}
    11. {@literal}
    12. @param
    13. @provides
    14. @return
    15. @see
    16. @since
    17. {@summary}
    18. @throws
    19. @uses
    20. {@value}
    21. @version
  2. The General Form of a Documentation Comment
  3. What javadoc Outputs
  4. An Example That Uses Documentation Comments

C Compile and Run Simple Single-File Programs in One StepD Introducing JShell

  1. JShell Basics
  2. List, Edit, and Rerun Code
  3. Add a Method
  4. Create a Class
  5. Use an Interface
  6. Evaluate Expressions and Use Built-in Variables
  7. Importing Packages
  8. Exceptions
  9. Some More JShell Commands
  10. Exploring JShell Further

E More Java Keywords

  1. The transient and volatile Modifiers
  2. instanceof
  3. strictfp
  4. assert
  5. Native Methods
  6. Another Form of this



Fair Use Sources:



See: Java – A Beginner’s Guide, 8th Edition, by Herbert Schildt, 2018

Fair Use Source: B07J2ZZ29H (JvBgnGd)

Bibliography Java Software Engineering

The Well-Grounded Java Developer

See also Java Programming Language, Java Glossary, Java Bibliography, Java Reference materials

See: The Well-Grounded Java Developer, Second Edition, by Benjamin Evans, Jason Clark, and Martijn Verburg, 2021, 1617298875 (WelGrJvDv)

Fair Use Source: 1617298875 (WelGrJvDv)

Previous version from 2012, New version available Summer 2021

About This Book:

Understanding Java from the JVM up gives you a solid foundation to grow your expertise and take on advanced techniques for performance, concurrency, containerization, and more.

In The Well-Grounded Java Developer, Second Edition you will learn:

  • The new Java module system and why you should use it
  • Bytecode for the JVM, including operations and classloading
  • Performance tuning the JVM
  • Working with Java’s built-in concurrency and expanded options
  • Programming in Kotlin and Clojure on the JVM
  • Maximizing the benefits from your build/CI tooling with Maven and Gradle
  • Running the JVM in containers
  • Planning for future JVM releases

The Well-Grounded Java Developer, Second Edition introduces both the modern innovations and timeless fundamentals you need to know to become a Java master. Authors Ben Evans, Martijn Verburg, and Jason Clark distil their decades of experience as Java Champions, veteran developers, and key contributors to the Java ecosystem into this clear and practical guide.

about the technology

Java’s history of innovation, its huge collection of libraries and frameworks, and the flexibility of the JVM have cemented its place as one of the world’s most popular programming languages. Although it’s easy to get started with Java, understanding how the language intersects with the JVM is the key to unlocking the power of this awesome language and its deep ecosystem of frameworks, tools, and alternative JVM-based languages.

about the book

The Well-Grounded Java Developer, Second Edition is a complete revision of the classic original with the latest innovations of the Java platform. It upgrades your existing Java skills with both JVM fundamentals like bytecode, and powerful new features such as modules and concurrency models.

You’ll broaden your understanding of what’s possible by exploring Kotlin and other JVM languages, and learn how functional programming can offer a powerful new perspective. Each concept is illustrated with hands-on examples, including a fully modularized application/library, build setups for Maven and Gradle, and creating your own multithreaded application.

about the reader

For intermediate Java developers. No experience with the latest Java version or JVM languages required.

About the Authors:

Martijn Verburg is the principal SWE group manager for the Java Engineering Group at Microsoft. He is the co-leader of the London Java User Group (LJC) where he co-founded AdoptOpenJDK, the world’s leading (non-Oracle) OpenJDK distribution. He has been made a Java Champion in recognition for his contribution to the Java ecosystem.

Jason Clark is a principal engineer and architect at New Relic, and was previously an architect at WebMD. A regular conference speaker, Jason contributes to the open-source project Shoes, aiming to make GUI programming easy and fun for beginners.

Book Details:

  • Publisher : Manning Publications; 1st edition (July 21, 2012), 2nd edition (August 2021)
  • Paperback : 496 pages
  • ISBN-10 : 1st edition 1617290068, 2nd edition 1617298875
  • ISBN-13 : 1st edition 978-1617290060, 2nd edition 978-1617298875

Table of Contents:


Fair Use Sources:



See: The Well-Grounded Java Developer, Second Edition, by Benjamin Evans, Jason Clark, and Martijn Verburg, 2021

Fair Use Source: 1617298875 (WelGrJvDv)

Previous version from 2012, New version available Summer 2021