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:

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:

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:

Bibliography Java Software Engineering

Java Quick Syntax Reference, by Mikael Olsson

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

Java Quick Syntax Reference, 2nd Edition, by Mikael Olsson, 2018, B079BKJ6CB (JvQSynRf)

Fair Use Source: B079BKJ6CB (JvQSynRf)

About This Book:

Quickly gain the insight necessary to address a multitude of Java coding challenges using this succinct reference guide. Short, focused code examples will help you master Java elements such as modules, boxing/unboxing and more.

You won’t find any technical jargon, bloated samples, drawn out history lessons or witty stories in this book. What you will find is a language reference that is concise, to the point and highly accessible. The book is packed with useful information and is a must-have for any Java programmer.

What You Will Learn

  • Code with Java modules
  • Box/unbox 
  • Utilize exception handling

Who This Book Is For

Those with prior experience with Java who want a quick and handy reference. 

About the Author:

Mikael Olsson is a professional web entrepreneur, programmer, and author. He works for an R&D company in Finland where he specializes in software development. In his spare time he writes books and creates websites that summarize various fields of interest. The books he writes are focused on teaching their subject in the most efficient way possible, by explaining only what is relevant and practical without any unnecessary repetition or theory. The portal to his online businesses and other websites is

Book Details:

  • ASIN : B079BKJ6CB
  • Publisher : Apress; 2nd edition (January 25, 2018)
  • Publication date : January 25, 2018
  • Print length : 113 pages

Table of Contents:

  1. Cover
  2. Front Matter
  3. 1. Hello World
  4. 2. Compile and Run
  5. 3. Variables
  6. 4. Operators
  7. 5. String
  8. 6. Arrays
  9. 7. Conditionals
  10. 8. Loops
  11. 9. Methods
  12. 10. Class
  13. 11. Static
  14. 12. Inheritance
  15. 13. Overriding
  16. 14. Packages and Import
  17. 15. Access Levels
  18. 16. Constants
  19. 17. Interface
  20. 18. Abstract
  21. 19. Enum
  22. 20. Exception Handling
  23. 21. Boxing and Unboxing
  24. 22. Generics
  25. 23. Lambda Expressions
  26. Back Matter


Fair Use Sources:

Cover image
Bibliography Java Software Engineering

Head First Java, by Kathy Sierra and Bert Bates

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

See: Head First Java, 3rd Edition, by Kathy Sierra and Bert Bates, 2021, 1491910771 (HFJav)

Fair Use Source: 1491910771 (HFJav)

About This Book:

Learning a complex new language is no easy task especially when it s an object-oriented computer programming language like Java. You might think the problem is your brain. It seems to have a mind of its own, a mind that doesn’t always want to take in the dry, technical stuff you’re forced to study.

The fact is your brain craves novelty. It’s constantly searching, scanning, waiting for something unusual to happen. After all, that’s the way it was built to help you stay alive. It takes all the routine, ordinary, dull stuff and filters it to the background so it won’t interfere with your brain’s real work–recording things that matter. How does your brain know what matters? It’s like the creators of the Head First approach say, suppose you’re out for a hike and a tiger jumps in front of you, what happens in your brain? Neurons fire. Emotions crank up. Chemicals surge.

That’s how your brain knows.

And that’s how your brain will learn Java. Head First Java combines puzzles, strong visuals, mysteries, and soul-searching interviews with famous Java objects to engage you in many different ways. It’s fast, it’s fun, and it’s effective. And, despite its playful appearance, Head First Java is serious stuff: a complete introduction to object-oriented programming and Java. You’ll learn everything from the fundamentals to advanced topics, including threads, network sockets, and distributed programming with RMI. And the new. third edition focuses on Java 17, the latest version of the Java language and development platform.

What will you learn from this book?

Ready to learn Java? This book combines puzzles, strong visuals, mysteries, and soul-searching interviews with famous Java objects to engage you in many different ways. It’s fast, it’s fun, and it’s effective. And, despite its playful appearance, Head First Java is serious stuff: a complete introduction to object-oriented programming and Java. You’ll learn everything from the fundamentals to advanced topics.

The new third edition brings the book up to date for Java 8-17, including major recent updates to the Java language and development platform. Java has seen some deep, code-level changes and more modern approaches, requiring even more careful study and implementation. So learning the Head First way is more important than ever.

What’s so special about this book?

If you’ve read a Head First book, you know what to expect–a visually rich format designed for the way your brain works. If you haven’t, you’re in for a treat. With this book, you’ll learn Java through a multi-sensory experience that engages your mind, rather than a text-heavy approach that puts you to sleep.

About the Authors:

Kathy Sierra, SCJP, was a codeveloper of the SCJP SCEA exams. Along with her partner Bert Bates, Kathy Sierra created the award-winning Head First programming book series that has sold over 1 million copies, and includes the longest-running tech bestsellers of the past decade. Her background is in developing education games and software for the motion picture industry, and she also created the first interaction design courses for UCLA Entertainment Studies. For more than 15 years she’s been helping large companies, small start-ups, non-profits, and educators rethink their approach to user experience, and build sustainable, genuine loyalty.

Kathy has been interested in learning theory since her days as a game developer (Virgin, MGM, Amblin’). More recently, she’s been a master trainer for Sun Microsystems, teaching Sun’s Java instructors how to teach the latest technologies to customers, and a lead developer of several Sun certification exams. She’s also the original founder of the Software Development/Jolt Productivity Award-winning, the largest (and friendliest) all-volunteer Java community.

Bert Bates, SCJP, OCA, OCP, is a Sun Certified Programmer for Java and has been developing software for the last 20 years. He has participated in the development of the SCJP, SCEA, and SCWCD exams. Bert has been teaching software development, including Java programming, for many years. Bert Bates is a 20-year software developer, a Java instructor, and a co-developer of Sun’s EJB exam (Sun Certified Business Component Developer), the SCJP exam and the SCJD exam. Bert has also been teaching software development, including Java programming, for many years. His background features a long stint in artificial intelligence, with clients like the Weather Channel, A&E Network, Rockwell, and Timken.

Book Details:

  • ASIN : 1491910771
  • Publisher : O’Reilly Media; 3rd edition (December 2021)
    • 2nd edition (February 9, 2005)
  • Publication date : December 2021
  • Print length : ~ 1200 pages

Publisher Resources

Table of Contents:

  1. 1. Dive in A Quick Dip: Breaking the Surface
    1. The Way Java Works
    2. What you’ll do in Java
    3. A Very Brief History of Java
      1. Speed and Memory Usage
      2. Sharpen your pencil Answers
    4. Code structure in Java
      1. What goes in a source file?
      2. What goes in a class?
      3. What goes in a method?
    5. Anatomy of a class
    6. Writing a class with a main
    7. What can you say in the main method?
      1. Looping and looping and…
      2. Simple boolean tests
    8. There are no dumb Questions
    9. Example of a while loop
    10. Conditional branching
    11. Coding a Serious Business Application
      1. Monday Morning at Bob’s Java-Enabled House
    12. Phrase-O-Matic
    13. Code Magnets
      1. BE the compiler
    14. JavaCross 7.0
    15. Pool Puzzle
    16. Exercise Solutions
    17. puzzle answers
  2. 2. Classes and Objects: A Trip to Objectville
    1. Chair Wars
      1. (or How Objects Can Change Your Life)
      2. In Larry’s cube
      3. At Brad’s laptop at the cafe
      4. Larry thought he’d nailed it. He could almost feel the rolled steel of the Aeron beneath his…
      5. Back in Larry’s cube
      6. At Brad’s laptop at the beach
      7. Larry snuck in just moments ahead of Brad.
      8. Back in Larry’s cube
      9. At Brad’s laptop on his lawn chair at the Telluride Bluegrass Festival
      10. So, Brad the OO guy got the chair and desk, right?
    2. What about the Amoeba rotate()?
    3. The suspense is killing me. Who got the chair and desk?
      1. Brain Power
    4. When you design a class, think about the objects that will be created from that class t ype. Think about:
    5. What’s the difference between a class and an object?
      1. A class is not an object.
    6. Making your first object
    7. Making and testing Movie objects
    8. Quick! Get out of main!
      1. The Guessing Game
    9. Running the Guessing Game
    10. There are no Dumb Questions
      1. BE the compiler
    11. Code Magnets
      1. Pool Puzzle
    12. Exercise Solutions
    13. Puzzle Solutions
      1. Pool Puzzle
      2. Who am I?
  3. 3. Primitives And References: Know Your Variables
    1. Declaring a variable
      1. variables must have a type
      2. variables must have a name
    2. “I’d like a double mocha, no, make it an int.”
      1. Primitive Types
    3. You really don’t want to spill that…
    4. Back away from that keyword!
    5. Controlling your Dog object
    6. An object reference is just another variable value.
      1. The 3 steps of object declaration, creation and assignment
    7. There are no Dumb Questions
      1. Java Exposed
    8. Life on the garbage-collectible heap
      1. Life and death on the heap
      2. An array is like a tray of cups
      3. Arrays are objects too
      4. Make an array of Dogs
      5. Control your Dog
      6. What happens if the Dog is in a Dog array?
      7. A Dog example
      8. BE the compiler
      9. Code Magnets
    9. Pool Puzzle
    10. A Heap o’ Trouble
      1. The case of the pilfered references
    11. Exercise Solutions
    12. Puzzle Solutions
      1. The case of the pilfered references
  4. 4. methods use instance variables: How Objects Behave
    1. Remember: a class describes what an object knows and what an object does
      1. Can every object of that type have different method behavior?
      2. The size affects the bark
      3. You can send things to a method
    2. You can get things back from a method.
    3. You can send more than one thing to a method
      1. Calling a two-parameter method, and sending it two arguments.
    4. There are no Dumb Questions
      1. Reminder: Java cares about type!
    5. Cool things you can do with parameters and return types
    6. Encapsulation
      1. Do it or risk humiliation and ridicule.
      2. Hide the data
    7. Java Exposed
    8. Encapsulating the GoodDog class
      1. How do objects in an array behave?
    9. Declaring and initializing instance variables
    10. The difference between instance and local variables
    11. There are no Dumb Questions
    12. Comparing variables (primitives or references)
      1. BE the compiler
    13. Mixed Messages
    14. Pool Puzzle
      1. Fast Times in Stim-City
    15. Exercise Solutions
    16. Puzzle Solutions
  5. 5. Writing a Program: Extra-Strength Methods
    1. Let’s build a Battleship-style game: “Sink a Startup”
    2. First, a high-level design
    3. The “Simple Startup Game” a gentler introduction
    4. Developing a Class
    5. Brain Power
    6. SimpleStartup class
    7. Writing the method implementations
      1. let’s write the real method code now, and get this puppy working.
    8. Writing test code for the SimpleStartup class
    9. There are no Dumb Questions
    10. The checkYourself() method
    11. Just the new stuff
    12. There are no Dumb Questions
    13. Final code for SimpleStartup and SimpleStartupTester
    14. Prepcode for the SimpleStartupGame class
    15. The game’s main() method
    16. random() and getUserInput()
    17. One last class: GameHelper
      1. Let’s play
      2. What’s this? A bug ?
    18. More about for loops
      1. Regular (non-enhanced) for loops
    19. Trips through a loop
      1. Difference between for and while
    20. The enhanced for loop
    21. Casting primitives
      1. BE the JVM
    22. Code Magnets
    23. JavaCross
      1. Mixed Messages
    24. Exercise Solutions
      1. Puzzle Solutions


Fair Use Sources:

Bibliography Java Software Engineering

Think Java – How to Think Like a Computer Scientist

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

Think Java – How to Think Like a Computer Scientist, 2nd Edition, by Allen B. Downey and Chris Mayfield, 2019, B08234FFCX (TnkJav)

Fair Use Source: B08234FFCX (TnkJav)

About This Book:

Currently used at many colleges, universities, and high schools, this hands-on introduction to computer science is ideal for people with little or no programming experience. The goal of this concise book is not just to teach you Java, but to help you think like a computer scientist. You’ll learn how to program—a useful skill by itself—but you’ll also discover how to use programming as a means to an end.

Authors Allen Downey and Chris Mayfield start with the most basic concepts and gradually move into topics that are more complex, such as recursion and object-oriented programming. Each brief chapter covers the material for one week of a college course and includes exercises to help you practice what you’ve learned.

  • Learn one concept at a time: tackle complex topics in a series of small steps with examples
  • Understand how to formulate problems, think creatively about solutions, and write programs clearly and accurately
  • Determine which development techniques work best for you, and practice the important skill of debugging
  • Learn relationships among input and output, decisions and loops, classes and methods, strings and arrays
  • Work on exercises involving word games, graphics, puzzles, and playing cards

The updated second edition of Think Java also features new chapters on polymorphism and data processing, as well as content covering changes through Java 12.

About the Authors:

Allen B. Downey is a Professor of Computer Science at Olin College of Engineering. He has taught at Wellesley College, Colby College, and U.C. Berkeley. He has a Ph.D. in Computer Science from U.C. Berkeley, and Master’s and Bachelor’s degrees from MIT. Downey is the creator of the bestselling Think series for O’Reilly, including Think Python, Think Complexity, Think DSP, and Think Bayes.

Chris Mayfield is an Assistant Professor of Computer Science at James Madison University, with a research focus on CS education and professional development. He has a Ph.D. in Computer Science from Purdue University and Bachelor’s degrees in CS and German from the University of Utah. and

Publisher Resources

Book Details:

  • ASIN : B08234FFCX
  • Publisher : O’Reilly Media; 2nd edition (November 27, 2019)
  • Publication date : November 27, 2019
  • Print length : 328 pages

Table of Contents:

Table of Contents

  1. Preface
    1. The Philosophy Behind the Book
    2. Object-Oriented Programming
    3. Changes to the Second Edition
    4. About the Appendixes
    5. Using the Code Examples
    6. Conventions Used in This Book
    7. O’Reilly Online Learning
    8. How to Contact Us
    9. Acknowledgments
  2. 1. Computer Programming
    1. What Is a Computer?
    2. What Is Programming?
    3. The Hello World Program
    4. Compiling Java Programs
    5. Displaying Two Messages
    6. Formatting Source Code
    7. Using Escape Sequences
    8. What Is Computer Science?
    9. Debugging Programs
    10. Vocabulary
    11. Exercises
  3. 2. Variables and Operators
    1. Declaring Variables
    2. Assigning Variables
    3. Memory Diagrams
    4. Printing Variables
    5. Arithmetic Operators
    6. Floating-Point Numbers
    7. Rounding Errors
    8. Operators for Strings
    9. Compiler Error Messages
    10. Other Types of Errors
    11. Vocabulary
    12. Exercises
  4. 3. Input and Output
    1. The System Class
    2. The Scanner Class
    3. Language Elements
    4. Literals and Constants
    5. Formatting Output
    6. Reading Error Messages
    7. Type Cast Operators
    8. Remainder Operator
    9. Putting It All Together
    10. The Scanner Bug
    11. Vocabulary
    12. Exercises
  5. 4. Methods and Testing
    1. Defining New Methods
    2. Flow of Execution
    3. Parameters and Arguments
    4. Multiple Parameters
    5. Stack Diagrams
    6. Math Methods
    7. Composition
    8. Return Values
    9. Incremental Development
    10. Vocabulary
    11. Exercises
  6. 5. Conditionals and Logic
    1. Relational Operators
    2. The if-else Statement
    3. Chaining and Nesting
    4. The switch Statement
    5. Logical Operators
    6. De Morgan’s Laws
    7. Boolean Variables
    8. Boolean Methods
    9. Validating Input
    10. Example Program
    11. Vocabulary
    12. Exercises
  7. 6. Loops and Strings
    1. The while Statement
    2. Increment and Decrement
    3. The for Statement
    4. Nested Loops
    5. Characters
    6. Which Loop to Use
    7. String Iteration
    8. The indexOf Method
    9. Substrings
    10. String Comparison
    11. String Formatting
    12. Vocabulary
    13. Exercises
  8. 7. Arrays and References
    1. Creating Arrays
    2. Accessing Elements
    3. Displaying Arrays
    4. Copying Arrays
    5. Traversing Arrays
    6. Generating Random Numbers
    7. Building a Histogram
    8. The Enhanced for Loop
    9. Counting Characters
    10. Vocabulary
    11. Exercises
  9. 8. Recursive Methods
    1. Recursive Void Methods
    2. Recursive Stack Diagrams
    3. Value-Returning Methods
    4. The Leap of Faith
    5. Counting Up Recursively
    6. Binary Number System
    7. Recursive Binary Method
    8. CodingBat Problems
    9. Vocabulary
    10. Exercises
  10. 9. Immutable Objects
    1. Primitives Versus Objects
    2. The null Keyword
    3. Strings Are Immutable
    4. Wrapper Classes
    5. Command-Line Arguments
    6. Argument Validation
    7. BigInteger Arithmetic
    8. Incremental Design
    9. More Generalization
    10. Vocabulary
    11. Exercises
  11. 10. Mutable Objects
    1. Point Objects
    2. Objects as Parameters
    3. Objects as Return Values
    4. Rectangles Are Mutable
    5. Aliasing Revisited
    6. Java Library Source
    7. Class Diagrams
    8. Scope Revisited
    9. Garbage Collection
    10. Mutable Versus Immutable
    11. StringBuilder Objects
    12. Vocabulary
    13. Exercises
  12. 11. Designing Classes
    1. The Time Class
    2. Constructors
    3. Value Constructors
    4. Getters and Setters
    5. Displaying Objects
    6. The toString Method
    7. The equals Method
    8. Adding Times
    9. Vocabulary
    10. Exercises
  13. 12. Arrays of Objects
    1. Card Objects
    2. Card toString
    3. Class Variables
    4. The compareTo Method
    5. Cards Are Immutable
    6. Arrays of Cards
    7. Sequential Search
    8. Binary Search
    9. Tracing the Code
    10. Vocabulary
    11. Exercises
  14. 13. Objects of Arrays
    1. Decks of Cards
    2. Shuffling Decks
    3. Selection Sort
    4. Merge Sort
    5. Subdecks
    6. Merging Decks
    7. Adding Recursion
    8. Static Context
    9. Piles of Cards
    10. Playing War
    11. Vocabulary
    12. Exercises
  15. 14. Extending Classes
    1. CardCollection
    2. Inheritance
    3. Dealing Cards
    4. The Player Class
    5. The Eights Class
    6. Class Relationships
    7. Vocabulary
    8. Exercises
  16. 15. Arrays of Arrays
    1. Conway’s Game of Life
    2. The Cell Class
    3. Two-Dimensional Arrays
    4. The GridCanvas Class
    5. Other Grid Methods
    6. Starting the Game
    7. The Simulation Loop
    8. Exception Handling
    9. Counting Neighbors
    10. Updating the Grid
    11. Vocabulary
    12. Exercises
  17. 16. Reusing Classes
    1. Langton’s Ant
    2. Refactoring
    3. Abstract Classes
    4. UML Diagram
    5. Vocabulary
    6. Exercises
  18. 17. Advanced Topics
    1. Polygon Objects
    2. Adding Color
    3. Regular Polygons
    4. More Constructors
    5. An Initial Drawing
    6. Blinking Polygons
    7. Interfaces
    8. Event Listeners
    9. Timers
    10. Vocabulary
    11. Exercises
  19. A. Tools
    1. Installing DrJava
    2. DrJava Interactions
    3. Command-Line Interface
    4. Command-Line Testing
    5. Running Checkstyle
    6. Tracing with a Debugger
    7. Testing with JUnit
    8. Vocabulary
  20. B. Javadoc
    1. Reading Documentation
    2. Writing Documentation
    3. Javadoc Tags
    4. Example Source File
    5. Vocabulary
  21. C. Graphics
    1. Creating Graphics
    2. Graphics Methods
    3. Example Drawing
    4. Vocabulary
    5. Exercises
  22. D. Debugging
    1. Compile-Time Errors
      1. The compiler is spewing error messages.
      2. I’m getting a weird compiler message, and it won’t go away.
      3. I can’t get my program to compile no matter what I do.
      4. I did what the compiler told me to do, but it still doesn’t work.
    2. Run-Time Errors
      1. My program hangs.
      2. When I run the program, I get an exception.
      3. I added so many print statements I get inundated with output.
    3. Logic Errors
      1. My program doesn’t work.
      2. I’ve got a big, hairy expression and it doesn’t do what I expect.
      3. My method doesn’t return what I expect.
      4. My print statement isn’t doing anything.
      5. I’m really, really stuck and I need help.
      6. No, I really need help.
      7. I found the bug!
  23. Index


Fair Use Sources: