SlideShare a Scribd company logo

Learning Java 4th Edition Patrick Niemeyer Daniel Leuck

Z
zachryqypi73

Learning Java 4th Edition Patrick Niemeyer Daniel Leuck Learning Java 4th Edition Patrick Niemeyer Daniel Leuck Learning Java 4th Edition Patrick Niemeyer Daniel Leuck

Education
1 of 78
Download to read offline
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
Learning Java 4th Edition Patrick Niemeyer Daniel Leuck download https://ebookbell.com/product/learning-java-4th-edition-patrick- niemeyer-daniel-leuck-4318126 Explore and download more ebooks at ebookbell.com
Here are some recommended products that we believe you will be interested in. You can click the link to download. Learning Java An Introduction To Realworld Programming With Java 6th Edition Marc Loy https://ebookbell.com/product/learning-java-an-introduction-to- realworld-programming-with-java-6th-edition-marc-loy-52200556 Learning Java With Games 1st Ed 2018 Chongwei Xu https://ebookbell.com/product/learning-java-with-games-1st- ed-2018-chongwei-xu-23480728 Learning Java By Building Android Games Learn Java And Android From Scratch By Building Five Exciting Games 3rd John Horton https://ebookbell.com/product/learning-java-by-building-android-games- learn-java-and-android-from-scratch-by-building-five-exciting- games-3rd-john-horton-23721610 Learning Java 3rd Edition Covers J2se 50 3rd Edition Patrick Niemeyer https://ebookbell.com/product/learning-java-3rd-edition- covers-j2se-50-3rd-edition-patrick-niemeyer-2406906
Learning Java Programming In Claras World 1st Anton Bogdanovych https://ebookbell.com/product/learning-java-programming-in-claras- world-1st-anton-bogdanovych-33453718 Learning Java 5th Edition Marc Loy Patrick Niemeyer And Daniel Leuck https://ebookbell.com/product/learning-java-5th-edition-marc-loy- patrick-niemeyer-and-daniel-leuck-37239172 Learning Java Through Applications A Graphical Approach Duane J Jarc https://ebookbell.com/product/learning-java-through-applications-a- graphical-approach-duane-j-jarc-4720722 Learning Java By Building Android Games John Horton https://ebookbell.com/product/learning-java-by-building-android-games- john-horton-5058278 Learning Java Through Games Stanchev Lubomir https://ebookbell.com/product/learning-java-through-games-stanchev- lubomir-5085918
Learning Java 4th Edition Patrick Niemeyer Daniel Leuck
Learning Java 4th Edition Patrick Niemeyer Daniel Leuck
Learning Java 4th Edition Patrick Niemeyer Daniel Leuck
Patrick Niemeyer and Daniel Leuck FOURTH EDITION Learning Java
Learning Java, Fourth Edition by Patrick Niemeyer and Daniel Leuck Copyright © 2013 Patrick Niemeyer, Daniel Leuck. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are alsoavailableformosttitles(http://my.safaribooksonline.com).Formoreinformation,contactourcorporate/ institutional sales department: 800-998-9938 or corporate@oreilly.com. Editors: Mike Loukides and Meghan Blanchette Production Editor: Rachel Steely Copyeditor: Gillian McGarvey Proofreader: Rachel Monaghan Indexer: BIM Publishing Services, Inc. Cover Designer: Randy Comer Interior Designer: David Futato Illustrators: Robert Romano and Rebecca Demarest June 2013: Fourth Edition Revision History for the Fourth Edition: 2013-06-06: First release See http://oreilly.com/catalog/errata.csp?isbn=9781449319243 for release details. Nutshell Handbook, the Nutshell Handbook logo, and the O’Reilly logo are registered trademarks of O’Reilly Media, Inc. Learning Java, Fourth Edition, the image of a Bengal tigress and her cubs, and related trade dress are trademarks of O’Reilly Media, Inc. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and O’Reilly Media, Inc., was aware of a trade‐ mark claim, the designations have been printed in caps or initial caps. While every precaution has been taken in the preparation of this book, the publisher and authors assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein. ISBN: 978-1-449-31924-3 [LSI]
Table of Contents Preface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi 1. A Modern Language. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Enter Java 2 Java’s Origins 2 Growing Up 3 A Virtual Machine 4 Java Compared with Other Languages 7 Safety of Design 10 Simplify, Simplify, Simplify... 10 Type Safety and Method Binding 11 Incremental Development 12 Dynamic Memory Management 13 Error Handling 14 Threads 14 Scalability 15 Safety of Implementation 15 The Verifier 17 Class Loaders 18 Security Managers 19 Application and User-Level Security 19 A Java Road Map 20 The Past: Java 1.0–Java 1.6 20 The Present: Java 7 21 The Future 23 Availability 23 2. A First Application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Java Tools and Environment 25 iii
Configuring Eclipse and Creating a Project 26 Importing the Learning Java Examples 28 HelloJava 29 Classes 32 The main() Method 33 Classes and Objects 34 Variables and Class Types 34 HelloComponent 35 Inheritance 36 The JComponent Class 37 Relationships and Finger Pointing 38 Package and Imports 39 The paintComponent() Method 40 HelloJava2: The Sequel 41 Instance Variables 43 Constructors 44 Events 45 The repaint() Method 47 Interfaces 48 HelloJava3: The Button Strikes! 49 Method Overloading 51 Components 52 Containers 52 Layout 53 Subclassing and Subtypes 54 More Events and Interfaces 54 Color Commentary 55 Static Members 55 Arrays 56 Our Color Methods 56 HelloJava4: Netscape’s Revenge 58 Threads 60 The Thread Class 61 The Runnable Interface 61 Starting the Thread 62 Running Code in the Thread 62 Exceptions 63 Synchronization 64 3. Tools of the Trade. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 JDK Environment 67 The Java VM 68 iv | Table of Contents
Running Java Applications 68 System Properties 70 The Classpath 70 javap 72 The Java Compiler 72 JAR Files 74 File Compression 74 The jar Utility 75 The pack200 Utility 78 Policy Files 78 The Default Security Manager 79 The policytool Utility 79 Using a Policy File with the Default Security Manager 81 4. The Java Language. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Text Encoding 83 Comments 84 Javadoc Comments 85 Types 86 Primitive Types 87 Reference Types 91 A Word About Strings 93 Statements and Expressions 93 Statements 94 Expressions 100 Exceptions 104 Exceptions and Error Classes 105 Exception Handling 107 Bubbling Up 109 Stack Traces 110 Checked and Unchecked Exceptions 111 Throwing Exceptions 112 try Creep 115 The finally Clause 116 Try with Resources 117 Performance Issues 119 Assertions 119 Enabling and Disabling Assertions 120 Using Assertions 121 Arrays 122 Array Types 123 Array Creation and Initialization 123 Table of Contents | v
Using Arrays 125 Anonymous Arrays 127 Multidimensional Arrays 127 Inside Arrays 129 5. Objects in Java. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 Classes 132 Accessing Fields and Methods 133 Static Members 135 Methods 138 Local Variables 139 Shadowing 139 Static Methods 140 Initializing Local Variables 141 Argument Passing and References 142 Wrappers for Primitive Types 144 Autoboxing and Unboxing of Primitives 146 Variable-Length Argument Lists 147 Method Overloading 148 Object Creation 149 Constructors 150 Working with Overloaded Constructors 151 Static and Nonstatic Initializer Blocks 153 Object Destruction 154 Garbage Collection 154 Finalization 155 Weak and Soft References 155 Enumerations 156 Enum Values 158 Customizing Enumerations 158 6. Relationships Among Classes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Subclassing and Inheritance 161 Shadowed Variables 163 Overriding Methods 165 Special References: this and super 172 Casting 172 Using Superclass Constructors 174 Full Disclosure: Constructors and Initialization 175 Abstract Methods and Classes 176 Interfaces 177 Interfaces as Callbacks 179 vi | Table of Contents
Interface Variables 180 Subinterfaces 181 Packages and Compilation Units 182 Compilation Units 182 Package Names 183 Class Visibility 183 Importing Classes 184 Visibility of Variables and Methods 186 Basic Access Modifiers 186 Subclasses and Visibility 188 Interfaces and Visibility 189 Arrays and the Class Hierarchy 189 ArrayStoreException 190 Inner Classes 190 Inner Classes as Adapters 192 Inner Classes Within Methods 194 7. Working with Objects and Classes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 The Object Class 201 Equality and Equivalence 202 Hashcodes 203 Cloning Objects 203 The Class Class 206 Reflection 208 Modifiers and Security 211 Accessing Fields 212 Accessing Methods 213 Accessing Constructors 215 What About Arrays? 216 Accessing Generic Type Information 216 Accessing Annotation Data 217 Dynamic Interface Adapters 217 What Is Reflection Good For? 218 Annotations 219 Using Annotations 220 Standard Annotations 221 The apt Tool 222 8. Generics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 Containers: Building a Better Mousetrap 224 Can Containers Be Fixed? 224 Enter Generics 225 Table of Contents | vii
Talking About Types 228 “There Is No Spoon” 229 Erasure 230 Raw Types 231 Parameterized Type Relationships 232 Why Isn’t a List<Date> a List<Object>? 234 Casts 235 Writing Generic Classes 236 The Type Variable 236 Subclassing Generics 237 Exceptions and Generics 238 Parameter Type Limitations 239 Bounds 240 Erasure and Bounds (Working with Legacy Code) 241 Wildcards 242 A Supertype of All Instantiations 243 Bounded Wildcards 243 Thinking Outside the Container 243 Lower Bounds 244 Reading, Writing, and Arithmetic 245 <?>, <Object>, and the Raw Type 247 Wildcard Type Relationships 247 Generic Methods 248 Generic Methods Introduced 249 Type Inference from Arguments 250 Type Inference from Assignment Context 251 Explicit Type Invocation 252 Wildcard Capture 252 Wildcard Types Versus Generic Methods 253 Arrays of Parameterized Types 253 Using Array Types 254 What Good Are Arrays of Generic Types? 255 Wildcards in Array Types 255 Case Study: The Enum Class 256 Case Study: The sort() Method 257 Conclusion 258 9. Threads. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 Introducing Threads 260 The Thread Class and the Runnable Interface 261 Controlling Threads 265 Death of a Thread 267 viii | Table of Contents
Threading an Applet 268 Issues Lurking 270 Synchronization 271 Serializing Access to Methods 272 Accessing class and instance Variables from Multiple Threads 274 The wait() and notify() Methods 275 Passing Messages 277 ThreadLocal Objects 281 Scheduling and Priority 282 Thread State 283 Time-Slicing 284 Priorities 285 Yielding 285 Thread Groups 286 Working with ThreadGroups 287 Uncaught Exceptions 287 Thread Performance 288 The Cost of Synchronization 288 Thread Resource Consumption 289 Concurrency Utilities 289 Executors 291 Locks 303 Synchronization Constructs 306 Atomic Operations 311 Conclusion 313 10. Working with Text. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315 Text-Related APIs 316 Strings 316 Constructing Strings 317 Strings from Things 318 Comparing Strings 319 Searching 321 Editing 322 String Method Summary 322 StringBuilder and StringBuffer 323 Internationalization 325 The java.util.Locale Class 325 Resource Bundles 326 Parsing and Formatting Text 328 Parsing Primitive Numbers 328 Tokenizing Text 330 Table of Contents | ix
Printf-Style Formatting 332 Formatter 333 The Format String 333 String Conversions 334 Primitive and Numeric Conversions 336 Flags 337 Miscellaneous 338 Formatting with the java.text Package 338 MessageFormat 340 Regular Expressions 342 Regex Notation 342 The java.util.regex API 352 11. Core Utilities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359 Math Utilities 359 The java.lang.Math Class 360 Big/Precise Numbers 361 Floating-Point Components 362 Random Numbers 363 Dates and Times 364 Working with Calendars 365 Time Zones 366 Parsing and Formatting with DateFormat 368 Printf-Style Date and Time Formatting 370 Timers 371 Collections 373 The Collection Interface 374 Iterator 376 Collection Types 378 The Map Interface 380 Collection Implementations 382 Hash Codes and Key Values 387 Synchronized and Unsynchronized Collections 388 Read-Only and Read-Mostly Collections 390 WeakHashMap 390 EnumSet and EnumMap 390 Sorting Collections 391 A Thrilling Example 392 Properties 393 Loading and Storing 394 System Properties 395 The Preferences API 396 x | Table of Contents
Preferences for Classes 397 Preferences Storage 398 Change Notification 398 The Logging API 399 Overview 399 Logging Levels 401 A Simple Example 402 Logging Setup Properties 403 The Logger 405 Performance 406 Observers and Observables 406 12. Input/Output Facilities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409 Streams 409 Basic I/O 412 Character Streams 415 Stream Wrappers 416 Pipes 420 Streams from Strings and Back 422 Implementing a Filter Stream 423 File I/O 425 The java.io.File Class 425 File Streams 430 RandomAccessFile 433 Resource Paths 434 The NIO File API 436 FileSystem and Path 436 NIO File Operations 438 Directory Operations 441 Watching Paths 443 Serialization 444 Initialization with readObject() 446 SerialVersionUID 447 Data Compression 448 Archives and Compressed Data 448 Decompressing Data 450 Zip Archive As a Filesystem 452 The NIO Package 453 Asynchronous I/O 453 Performance 454 Mapped and Locked Files 454 Channels 454 Table of Contents | xi
Buffers 455 Character Encoders and Decoders 459 FileChannel 461 Scalable I/O with NIO 467 13. Network Programming. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469 Sockets 471 Clients and Servers 472 The DateAtHost Client 477 The TinyHttpd Server 478 Socket Options 482 Proxies and Firewalls 484 Datagram Sockets 486 The HeartBeat Applet 487 InetAddress 491 Simple Serialized Object Protocols 491 A Simple Object-Based Server 492 Remote Method Invocation 496 Real-World Usage 497 Remote and Nonremote Objects 497 An RMI Example 500 RMI and CORBA 508 Scalable I/O with NIO 509 Selectable Channels 509 Using Select 510 LargerHttpd 512 Nonblocking Client-Side Operations 517 14. Programming for the Web. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519 Uniform Resource Locators (URLs) 519 The URL Class 520 Stream Data 521 Getting the Content as an Object 522 Managing Connections 523 Handlers in Practice 524 Useful Handler Frameworks 524 Talking to Web Applications 525 Using the GET Method 526 Using the POST Method 527 The HttpURLConnection 530 SSL and Secure Web Communications 530 URLs, URNs, and URIs 530 xii | Table of Contents
Web Services 531 XML-RPC 532 WSDL 532 The Tools 532 The Weather Service Client 533 15. Web Applications and Web Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535 Web Application Technologies 536 Page-Oriented Versus “Single Page” Applications 536 JSPs 537 XML and XSL 538 Web Application Frameworks 538 Google Web Toolkit 539 HTML5, AJAX, and More... 539 Java Web Applications 539 The Servlet Lifecycle 540 Servlets 541 The HelloClient Servlet 542 The Servlet Response 544 Servlet Parameters 545 The ShowParameters Servlet 546 User Session Management 548 The ShowSession Servlet 548 The ShoppingCart Servlet 550 Cookies 553 The ServletContext API 554 Asynchronous Servlets 555 WAR Files and Deployment 559 Configuration with web.xml and Annotations 560 URL Pattern Mappings 562 Deploying HelloClient 563 Error and Index Pages 564 Security and Authentication 566 Protecting Resources with Roles 566 Secure Data Transport 568 Authenticating Users 569 Procedural Authorization 570 Servlet Filters 571 A Simple Filter 572 A Test Servlet 573 Declaring and Mapping Filters 574 Filtering the Servlet Request 575 Table of Contents | xiii
Filtering the Servlet Response 577 Building WAR Files with Ant 580 A Development-Oriented Directory Layout 581 Deploying and Redeploying WARs with Ant 582 Implementing Web Services 582 Defining the Service 583 Our Echo Service 584 Using the Service 585 Data Types 587 Conclusion 588 16. Swing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589 Components 592 Peers and Look-and-Feel 594 The MVC Framework 595 Painting 596 Enabling and Disabling Components 597 Focus, Please 598 Other Component Methods 598 Layout Managers 600 Insets 601 Z-Ordering (Stacking Components) 601 The revalidate() and doLayout() Methods 601 Managing Components 602 Listening for Components 602 Windows, Frames and Splash Screens 602 Other Methods for Controlling Frames 604 Content Panes 605 Desktop Integration 605 Events 607 Event Receivers and Listener Interfaces 608 Event Sources 610 Event Delivery 611 Event Types 612 The java.awt.event.InputEvent Class 613 Mouse and Key Modifiers on InputEvents 613 Focus Events 614 Event Summary 616 Adapter Classes 619 Dummy Adapters 622 The AWT Robot! 623 xiv | Table of Contents
Multithreading in Swing 623 17. Using Swing Components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627 Buttons and Labels 627 HTML Text in Buttons and Labels 630 Checkboxes and Radio Buttons 631 Lists and Combo Boxes 634 The Spinner 637 Borders 639 Menus 642 Pop-Up Menus 646 Component-Managed Pop Ups 648 The JScrollPane Class 650 The JSplitPane Class 652 The JTabbedPane Class 653 Scrollbars and Sliders 657 Dialogs 659 File Selection Dialog 662 The Color Chooser 664 18. More Swing Components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667 Text Components 667 The TextEntryBox Application 668 Formatted Text 670 Filtering Input 671 Validating Data 673 Say the Magic Word 674 Sharing a Data Model 675 HTML and RTF for Free 677 Managing Text Yourself 680 Focus Navigation 682 Trees 684 Nodes and Models 684 Save a Tree 685 Tree Events 685 A Complete Example 686 Tables 688 A First Stab: Freeloading 688 Round Two: Creating a Table Model 690 Round Three: A Simple Spreadsheet 693 Sorting and Filtering 697 Printing JTables 699 Table of Contents | xv
Desktops 699 Pluggable Look-and-Feel 701 Creating Custom Components 704 Generating Events 704 A Dial Component 704 Model and View Separation 708 19. Layout Managers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 709 FlowLayout 711 GridLayout 712 BorderLayout 713 BoxLayout 716 CardLayout 717 GridBagLayout 719 The GridBagConstraints Class 719 Grid Coordinates 721 The fill Constraint 722 Spanning Rows and Columns 724 Weighting 725 Anchoring 728 Padding and Insets 728 Relative Positioning 730 Composite Layouts 731 Other Layout Managers 734 Absolute Positioning 735 20. Drawing with the 2D API. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737 The Big Picture 737 The Rendering Pipeline 739 A Quick Tour of Java 2D 742 Filling Shapes 742 Drawing Shape Outlines 742 Convenience Methods 743 Drawing Text 744 Drawing Images 744 The Whole Iguana 745 Filling Shapes 748 Solid Colors 748 Color Gradients 749 Textures 749 Desktop Colors 749 Stroking Shape Outlines 750 xvi | Table of Contents
Using Fonts 751 Font Metrics 752 Displaying Images 756 The Image Class 756 Image Observers 758 Scaling and Size 759 Drawing Techniques 760 Double Buffering 763 Limiting Drawing with Clipping 764 Offscreen Drawing 766 Printing 769 21. Working with Images and Other Media. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 771 Loading Images 772 ImageObserver 773 MediaTracker 775 ImageIcon 777 ImageIO 777 Producing Image Data 778 Drawing Animations 779 BufferedImage Anatomy 782 Color Models 783 Creating an Image 784 Updating a BufferedImage 786 Filtering Image Data 790 How ImageProcessor Works 792 Converting an Image to a BufferedImage 793 Using the RescaleOp Class 793 Using the AffineTransformOp Class 793 Saving Image Data 794 Simple Audio 795 Java Media Framework 796 22. JavaBeans. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 799 What’s a Bean? 799 What Constitutes a Bean? 801 The NetBeans IDE 801 Installing and Running NetBeans 802 Properties and Customizers 805 Event Hookups and Adapters 807 Taming the Juggler 808 Molecular Motion 810 Table of Contents | xvii
Binding Properties 811 Constraining Properties 812 Building Beans 813 The Dial Bean 813 Design Patterns for Properties 816 Limitations of Visual Design 817 Serialization Versus Code Generation 818 Customizing with BeanInfo 819 Getting Properties Information 819 Handcoding with Beans 822 Bean Instantiation and Type Management 823 Working with Serialized Beans 823 Runtime Event Hookups with Reflection 825 BeanContext and BeanContextServices 827 The Java Activation Framework 828 Enterprise JavaBeans and POJO-Based Enterprise Frameworks 828 23. Applets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 831 The Politics of Browser-Based Applications 831 Applet Support and the Java Plug-in 833 The JApplet Class 833 Applet Lifecycle 834 The Applet Security Sandbox 837 Getting Applet Resources 838 The <applet> Tag 842 Attributes 843 Parameters 843 ¿Habla Applet? 844 The Complete <applet> Tag 844 Loading Class Files 846 Packages 846 appletviewer 847 Java Web Start 847 Conclusion 848 24. XML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 849 The Butler Did It 849 A Bit of Background 850 Text Versus Binary 851 A Universal Parser 851 The State of XML 851 The XML APIs 852 xviii | Table of Contents
XML and Web Browsers 852 XML Basics 852 Attributes 853 XML Documents 854 Encoding 854 Namespaces 855 Validation 856 HTML to XHTML 856 SAX 856 The SAX API 857 Building a Model Using SAX 858 XMLEncoder/Decoder 864 DOM 865 The DOM API 865 Test-Driving DOM 866 Generating XML with DOM 868 JDOM 869 XPath 869 Nodes 870 Predicates 871 Functions 871 The XPath API 872 XMLGrep 873 XInclude 874 Enabling XInclude 875 Validating Documents 876 Using Document Validation 876 DTDs 877 XML Schema 879 The Validation API 883 JAXB Code Binding and Generation 885 Annotating Our Model 885 Generating a Java Model from an XML Schema 890 Generating an XML Schema from a Java Model 891 Transforming Documents with XSL/XSLT 891 XSL Basics 892 Transforming the Zoo Inventory 894 XSLTransform 896 XSL in the Browser 897 Web Services 897 Table of Contents | xix
The End of the Book 898 A. The Eclipse IDE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 899 B. BeanShell: Java Scripting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 911 Glossary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 917 Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 931 xx | Table of Contents
Preface This book is about the Java programming language and environment. Whether you are a software developer or just someone who uses the Internet in your daily life, you’ve undoubtedly heard about Java. Its introduction was one of the most exciting develop‐ ments in the history of the Web and Java applications have powered much of the growth of business on the Internet in the past 15 years. Java is, arguably, the most popular programming language in the world, used by millions of developers on almost every kind of computer imaginable. In the past decade, Java has surpassed languages such as C++ and Visual Basic in terms of developer demand and has become the de facto lan‐ guage for certain kinds of development—especially for web-based services. Most uni‐ versities are now using Java in their introductory courses alongside the other important modern languages. Perhaps you are using this text in one of your classes right now! This book gives you a thorough grounding in Java fundamentals and APIs. Learning Java, Fourth Edition, attempts to live up to its name by mapping out the Java language and its class libraries, programming techniques, and idioms. We’ll dig deep into inter‐ esting areas and at least scratch the surface of the rest. Other titles from O’Reilly pick up where we leave off and provide more comprehensive information on specific areas and applications of Java. Whenever possible, we provide compelling, realistic, and fun examples and avoid mere‐ ly cataloging features. The examples are simple, but hint at what can be done. We won’t bedevelopingthenextgreat“killerapp”inthesepages,butwehopetogiveyouastarting point for many hours of experimentation and inspired tinkering that will lead you to develop one yourself. Who Should Read This Book This book is for computer professionals, students, technical people, and Finnish hack‐ ers. It’s for everyone who has a need for hands-on experience with the Java language with an eye toward building real applications. This book could also be considered a xxi
crash course in object-oriented programming, networking, GUIs, and XML. As you learn about Java, you’ll also learn a powerful and practical approach to software devel‐ opment, beginning with a deep understanding of the fundamentals of Java and its APIs. Superficially, Java looks like C or C++, so you’ll have a tiny head start in using this book if you have some experience with one of these languages. If you do not, don’t worry. Don’t make too much of the syntactic similarities between Java and C or C++. In many respects, Java acts like more dynamic languages such as Smalltalk and Lisp. Knowledge of another object-oriented programming language should certainly help, although you may have to change some ideas and unlearn a few habits. Java is considerably simpler than languages such as C++ and Smalltalk. If you learn well from concise examples and personal experimentation, we think you’ll like this book. The last part of this book branches out to discuss Java in the context of web applications, web services, and XML processing, so you should be familiar with the basic ideas behind web browsers, servers, and documents. New Developments This edition of Learning Java is actually the sixth edition—updated and retitled—of our original, popular Exploring Java. With each edition, we’ve taken great care not only to add new material covering additional features, but to thoroughly revise and update the existing content to synthesize the coverage and add years of real-world perspective and experience to these pages. One noticeable change in recent editions is that we’ve deemphasized the use of applets, reflecting their diminished role in recent years in creating interactive web pages. In contrast, we’ve greatly expanded our coverage of Java web applications, web services, and XML, which are now mature technologies. We cover all of the important features of the latest release of Java, officially called Java Standard Edition (SE) 7, JDK 1.7. Sun (Java’s keeper before Oracle) has changed the naming scheme many times over the years. Sun coined the term Java 2 to cover the major new features introduced in Java version 1.2 and dropped the term JDK in favor of SDK. With the sixth release, Sun skipped from Java version 1.4 to Java 5.0, but re‐ prieved the term JDK and kept its numbering convention there. After that, we had Java 6 and now we reach Java 7. This release of Java reflects a mature language with relatively few syntactic changes but significant updates to APIs and libraries. We’ve tried to capture these new features and update every example in this book to reflect not only the current Java practice, but style as well. xxii | Preface
New in This Edition (Java 6 and 7) This edition of the book has been significantly reworked to be as complete and up-to- date as possible. It incorporates changes from both the Java 6 and Java 7 releases that occurred since the last edition of this book. New topics in this edition include: • New language features, including type inference in generics and improved excep‐ tion handling and automatic resource management syntax • New concurrency utilities including the Fork-Join framework • The new NIO Files API, which allows new types of filesystem access to be imple‐ mented in Java • New versions of the Java Servlets (3.0) and web services APIs, including use of the new annotations-based deployment and built-in web service container • New version of JAXB (2.2) Java XML Binding, including use of the new annotations for binding Java to XML • Improved Swing desktop integration and enhancements to key Swing components such as JTable • Updated examples and analysis throughout the book Using This Book This book is organized roughly as follows: • Chapters 1 and 2 provide a basic introduction to Java concepts and a tutorial to give you a jump start on Java programming. • Chapter 3 discusses fundamental tools for developing with Java (the compiler, the interpreter, and the JAR file package). • Chapters 4 through 7 describe the Java language itself, beginning with the basic syntax and then covering classes and objects, exceptions, arrays, enumerations, annotations, and much more. • Chapter 8 covers generics and parameterized types in Java. • Chapter 9 covers the language’s built-in thread facilities and the Java Concurrency package, which should be of particular interest to advanced programmers. • Chapter 10 covers text processing, formatting, scanning, string utilities, and the powerful regular expressions API. • Chapter 11 covers much of the core API including utilities and collections. • Chapter 12 covers Java I/O, streams, files, and the NIO package. Preface | xxiii
• Chapters 13 and 14 cover Java networking, including sockets and NIO, URLs, and RMI. • Chapter 15 covers web applications using servlets, servlet filters, and WAR files, as well as web services. • Chapters 16 through 21 cover GUI development with the Abstract Window Toolkit (AWT) and Swing, which provide graphical user interface (GUI) and image support. • Chapter 22 covers the JavaBeans component architecture and introduces the Net‐ Beans IDE. • Chapter 23 covers applets. • Chapter 24 covers the Java APIs for working with XML and XSLT, including XML Schema, validation, XPath, and XInclude, as well as XML binding with JAXB. • Appendix A covers using the Eclipse IDE with the examples in this book. • AppendixBdescribesBeanShell,alightweightscriptinglanguageforJavadeveloped by the authors of this book. If you’re like us, you don’t read books from front to back. If you’re really like us, you usually don’t read the Preface at all. However, on the off chance that you will see this in time, here are a few suggestions: • IfyouareanexperiencedprogrammerwhohastolearnJavainthenextfiveminutes, you are probably looking for the examples. You might want to start by glancing at the tutorial in Chapter 2. If that doesn’t float your boat, you should at least look at the information in Chapter 3, which explains how to use the compiler and inter‐ preter, or Appendix A, which shows how to run the examples in the Eclipse IDE. This should get you started. • Chapters 12 through 15 are essential if you are interested in writing advanced net‐ worked or web-based applications and services. This is one of the more interesting and important parts of Java. • Chapters 16 through 22 discuss Java’s graphics features and component architec‐ ture. You should read this if you are interested in writing graphical Java applications or applets. • Chapter 24 covers the Java APIs for working with XML, including SAX, DOM, DTDs,XMLSchema,andusingXSLtorenderoutputfortheWeb.XMLtechnology is becoming key to cross-platform development. xxiv | Preface
Online Resources There are many online sources for information about Java. Oracle’s official website for Java topics is http://java.sun.com; look here for the software, updates, and Java releases. This is where you’ll find the JDK, which includes the compiler, the interpreter, and other tools. You should also visit O’Reilly’s Java site at http://oreilly.com/java. There you’ll find in‐ formation about other O’Reilly Java books, and a pointer to the home page for Learning Java, http://oreil.ly/Java_4E, where you’ll find the source code examples for this book. Conventions Used in This Book The font conventions used in this book are quite simple. Italic is used for: • Unix pathnames, filenames, and program names • Internet addresses, such as domain names and URLs • New terms where they are defined • Program names, compilers, interpreters, utilities, and commands • Threads Constant width is used for: • Anything that might appear in a Java program, including method names, variable names, and class names • Tags that might appear in an HTML or XML document • Keywords, objects, and environment variables Constant width bold is used for: • Text that is typed by the user on the command line Constant width italic is used for: • Replaceable items in code This icon designates a note, which is an important aside to the near‐ by text. Preface | xxv
This icon designates a warning relating to the nearby text. In the main body of text, we always use a pair of empty parentheses after a method name to distinguish methods from variables and other creatures. In the Java source listings, we follow the coding conventions most frequently used in the Java community. Class names begin with capital letters; variable and method names begin with lowercase. All the letters in the names of constants are capitalized. We don’t use underscores to separate words in a long name; following common practice, we capitalize individual words (after the first) and run the words together. For example: thisIsAVariable, thisIsAMethod(), ThisIsAClass, and THISISACONSTANT. Also, note thatwedifferentiatebetweenstaticandnonstaticmethodswhenwerefertothem.Unlike some books, we never write Foo.bar() to mean the bar() method of Foo unless bar() is a static method (paralleling the Java syntax in that case). Using Code Examples This book is here to help you get your job done. In general, if this book includes code examples, you may use the code in your programs and documentation. You do not need to contact us for permission unless you’re reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from this book does not require permission. Selling or distributing a CD-ROM of examples from O’Reilly books does require permission. Answering a question by citing this book and quoting example code does not require permission. Incorporating a significant amount of ex‐ ample code from this book into your product’s documentation does require permission. We appreciate, but do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: “Learning Java, Fourth Edition, by Patrick Niemeyer and Daniel Leuck. Copyright 2013 Patrick Niemeyer and Daniel Leuck, 978-1-449-31924-3.” If you feel your use of code examples falls outside fair use or the permission given above, feel free to contact us at permissions@oreilly.com. Safari® Books Online Safari Books Online (www.safaribooksonline.com) is an on- demand digital library that delivers expert content in both book and video form from the world’s leading authors in technology and busi‐ ness. xxvi | Preface
Technology professionals, software developers, web designers, and business and crea‐ tive professionals use Safari Books Online as their primary resource for research, prob‐ lem solving, learning, and certification training. Safari Books Online offers a range of product mixes and pricing programs for organi‐ zations, government agencies, and individuals. Subscribers have access to thousands of books, training videos, and prepublication manuscripts in one fully searchable database from publishers like O’Reilly Media, Prentice Hall Professional, Addison-Wesley Pro‐ fessional, Microsoft Press, Sams, Que, Peachpit Press, Focal Press, Cisco Press, John Wiley & Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe Press, FT Press, Apress, Manning, New Riders, McGraw-Hill, Jones & Bartlett, Course Technol‐ ogy, and dozens more. For more information about Safari Books Online, please visit us online. How to Contact Us Please address comments and questions concerning this book to the publisher: O’Reilly Media, Inc. 1005 Gravenstein Highway North Sebastopol, CA 95472 800-998-9938 (in the United States or Canada) 707-829-0515 (international or local) 707-829-0104 (fax) We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at http://oreil.ly/Java_4E. To comment or ask technical questions about this book, send email to bookques tions@oreilly.com. For more information about our books, courses, conferences, and news, see our website at http://www.oreilly.com. Find us on Facebook: http://facebook.com/oreilly Follow us on Twitter: http://twitter.com/oreillymedia Watch us on YouTube: http://www.youtube.com/oreillymedia Acknowledgments Many people have contributed to putting this book together, both in its Exploring Java incarnation and in its current form as Learning Java. Foremost, we would like to thank Tim O’Reilly for giving us the opportunity to write this book. Thanks to Mike Loukides, the series editor, whose patience and experience helped us get started on this Preface | xxvii
journey. Thanks to Paula Ferguson and John Posner, who contributed their organiza‐ tional and editing abilities at various times. And a special thanks to Deb Cameron, the tireless editor of this book, without whom the previous two editions might never have been finished and certainly wouldn’t have resembled English. We could not have asked for a more skillful or responsive team of people with whom to work. Speakingofborrowings,theoriginalversionoftheglossarycamefromDavidFlanagan’s book Java in a Nutshell (O’Reilly). We also borrowed several class hierarchy diagrams from David’s book. These diagrams were based on similar diagrams by Charles L. Perkins. Thanks also to Marc Wallace and Steven Burkett for reading the original work in pro‐ gress and for the support of our friends at Washington University: Bryan O’Connor and Brian Gottlieb. Thanks also to Josh Peck, coauthor of the original book, Exploring Java. Thanks to all those who reviewed or answered questions: David Flanagan for generics; Henry Wong for the concurrency utilities; Jim Elliott, Marc Loy, and Brian ColeforSwing;JackShiraziforNIO;TimBoudreauforNetBeans;MartinAeschlimann, Jim Farley, and John Norman for Eclipse; Ed Howland for XML; and Ian Darwin for regular expressions. (Check out Ian’s Java Cookbook [O’Reilly] for more examples.) Thanks also to Ray O’Leary, Mario Aquino, and Mark Volkmann for their reviews. And finally, thanks to my beautiful wife, Ellen Song, for putting up with me through all this work. xxviii | Preface
CHAPTER 1 A Modern Language The greatest challenges and most exciting opportunities for software developers today lie in harnessing the power of networks. Applications created today, whatever their intended scope or audience, will almost certainly run on machines linked by a global network of computing resources. The increasing importance of networks is placing new demands on existing tools and fueling the demand for a rapidly growing list of com‐ pletely new kinds of applications. We want software that works—consistently, anywhere, on any platform—and that plays well with other applications. We want dynamic applications that take advantage of a connected world, capable of accessing disparate and distributed information sources. We want truly distributed software that can be extended and upgraded seamlessly. We want intelligent applications that can roam the Net for us, ferreting out information and serving as electronic emissaries. We have known for some time what kind of software we want, but it is really only in the past few years that we have begun to get it. The problem, historically, has been that the tools for building these applications have fallen short. The requirements of speed and portability have been, for the most part, mutually exclusive, and security has been largely ignored or misunderstood. In the past, truly portable languages were bulky, interpreted, and slow. These languages were pop‐ ular as much for their high-level functionality as for their portability. Fast languages usually provided speed by binding themselves to particular platforms, so they met the portability issue only halfway. There were even a few safe languages, but they were primarily offshoots of the portable languages and suffered from the same problems. Java is a modern language that addresses all three of these fronts: portability, speed, and security. This is why it has been a dominant language in the world of programming for more than a decade and a half. 1
Enter Java The Java programming language, developed at Sun Microsystems under the guidance ofNetluminariesJamesGoslingandBillJoy,wasdesignedtobeamachine-independent programming language that is both safe enough to traverse networks and powerful enough to replace native executable code. Java addresses the issues raised here and played a starring role in the growth of the Internet, leading to where we are today. Initially, most of the enthusiasm for Java centered on its capabilities for building em‐ bedded applications for the Web called applets. But in the early days, applets and other client-side GUI applications written in Java were limited. Today, Java has Swing, one of the most sophisticated toolkits for building graphical user interfaces (GUIs) in any lan‐ guage. This development has allowed Java to become a popular platform for developing traditional client-side application software. Of even more importance, however, Java has become the premier platform for web- based applications and web services. These applications use technologies including the Java Servlet API, Java web services, and many popular open source and commercial Java application servers and frameworks. Java’s portability and speed make it the platform of choice for modern business applications. Java servers running on open source Linux platforms are at the heart of the business and financial world today. This book will show you how to use Java to accomplish real-world programming tasks. In the coming chapters we’ll cover everything from text processing to networking, building rich client-side GUI applications with Swing and lightweight web-based ap‐ plications and services. Java’s Origins The seeds of Java were planted in 1990 by Sun Microsystems patriarch and chief re‐ searcherBillJoy.Atthetime,Sunwascompetinginarelativelysmallworkstationmarket while Microsoft was beginning its domination of the more mainstream, Intel-based PC world. When Sun missed the boat on the PC revolution, Joy retreated to Aspen, Colo‐ rado, to work on advanced research. He was committed to the idea of accomplishing complex tasks with simple software and founded the aptly named Sun Aspen Smallworks. Of the original members of the small team of programmers assembled in Aspen, James Gosling will be remembered as the father of Java. Gosling first made a name for himself in the early 80s as the author of Gosling Emacs, the first version of the popular Emacs editor that was written in C and ran under Unix. Gosling Emacs became popular but was soon eclipsed by a free version, GNU Emacs, written by Emacs’s original designer. By that time, Gosling had moved on to design Sun’s NeWS, which briefly contended with the X Window System for control of the Unix GUI desktop in 1987. Although some people would argue that NeWS was superior to X, NeWS lost because Sun kept it 2 | Chapter 1: A Modern Language
proprietary and didn’t publish source code while the primary developers of X formed the X Consortium and took the opposite approach. Designing NeWS taught Gosling the power of integrating an expressive language with a network-aware windowing GUI. It also taught Sun that the Internet programming community will ultimately refuse to accept proprietary standards, no matter how good they may be. The seeds of Java’s licensing scheme and open (if not quite “open source”) code were sown by NeWS’s failure. Gosling brought what he had learned to Bill Joy’s nascent Aspen project. In 1992, work on the project led to the founding of the Sun subsidiary FirstPerson, Inc. Its mission was to lead Sun into the world of consumer electronics. The FirstPerson team worked on developing software for information appliances, such as cellular phones and personal digital assistants (PDAs). The goal was to enable the transfer of information and real-time applications over cheap infrared and traditional packet-based networks. Memory and bandwidth limitations dictated small, efficient code. The nature of the applications also demanded they be safe and robust. Gosling and his teammates began programming in C++, but they soon found themselves con‐ founded by a language that was too complex, unwieldy, and insecure for the task. They decided to start from scratch, and Gosling began working on something he dubbed “C++ minus minus.” With the foundering of the Apple Newton (Apple’s earliest handheld computer), it be‐ came apparent that the PDA’s ship had not yet come in, so Sun shifted FirstPerson’s efforts to interactive TV (ITV). The programming language of choice for ITV set-top boxes was to be the near ancestor of Java, a language called Oak. Even with its elegance and ability to provide safe interactivity, Oak could not salvage the lost cause of ITV at that time. Customers didn’t want it, and Sun soon abandoned the concept. Atthattime,JoyandGoslinggottogethertodecideonanewstrategyfortheirinnovative language. It was 1993, and the explosion of interest in the Web presented a new oppor‐ tunity. Oak was small, safe, architecture-independent, and object-oriented. As it happens, these are also some of the requirements for a universal, Internet-savvy pro‐ gramminglanguage.Sunquicklychangedfocus,and,withalittleretooling,Oakbecame Java. Growing Up It would not be overstating it to say that Java caught on like wildfire. Even before its first official release when Java was still a nonproduct, nearly every major industry player had jumped on the Java bandwagon. Java licensees included Microsoft, Intel, IBM, and vir‐ tually all major hardware and software vendors. However, even with all this support Java took a lot of knocks and experienced some growing pains during its first few years. Enter Java | 3
A series of breach of contract and antitrust lawsuits between Sun and Microsoft over the distribution of Java and its use in Internet Explorer hampered its deployment on the world’s most common desktop operating system—Windows. Microsoft’s involve‐ ment with Java also become one focus of a larger federal lawsuit over serious anticom‐ petitive practices at the company, with court testimony revealing concerted efforts by the software giant to undermine Java by introducing incompatibilities in its version of the language. Meanwhile, Microsoft introduced its own Java-derived language called C# (C-sharp) as part of its .NET initiative and dropped Java from inclusion in Windows. C# has gone on to become a very good language in its own right, enjoying more inno‐ vation in recent years than has Java. But Java continues to spread on a wide variety of platforms. As we begin looking at the Java architecture, you’ll see that much of what is exciting about Java comes from the self-contained, virtual machine environment in which Java applications run. Java was carefully designed so that this supporting architecture can be implemented either in software, for existing computer platforms, or in customized hardware. Hardware im‐ plementations of Java are used in some smart cards and other embedded systems. You can even buy “wearable” devices, such as rings and dog tags, that have Java interpreters embedded in them. Software implementations of Java are available for all modern com‐ puter platforms down to portable computing devices. Today, an offshoot of the Java platform is the basis for Google’s Android operating system that powers billions of phones and other mobile devices. In 2010, Oracle corporation bought Sun Microsystems and became the steward of the Java language. In a somewhat rocky start to its tenure, Oracle sued Google over its use of the Java language in Android and lost. In July of 2011, Oracle released Java SE 7, a significant Java release. A Virtual Machine Java is both a compiled and an interpreted language. Java source code is turned into simple binary instructions, much like ordinary microprocessor machine code. How‐ ever, whereas C or C++ source is reduced to native instructions for a particular model of processor, Java source is compiled into a universal format—instructions for a virtual machine. Compiled Java bytecode is executed by a Java runtime interpreter. The runtime system performs all the normal activities of a hardware processor, but it does so in a safe, virtual environment. It executes a stack-based instruction set and manages memory like an operating system. It creates and manipulates primitive data types and loads and invokes newly referenced blocks of code. Most importantly, it does all this in accordance with a strictly defined open specification that can be implemented by anyone who wants to produce a Java-compliant virtual machine. Together, the virtual machine and language definition provide a complete specification. There are no features of the base Java 4 | Chapter 1: A Modern Language
language left undefined or implementation-dependent. For example, Java specifies the sizes and mathematical properties of all its primitive data types rather than leaving it up to the platform implementation. The Java interpreter is relatively lightweight and small; it can be implemented in what‐ ever form is desirable for a particular platform. The interpreter may be run as a separate application or it can be embedded in another piece of software, such as a web browser. Put together, this means that Java code is implicitly portable. The same Java application bytecode can run on any platform that provides a Java runtime environment, as shown in Figure 1-1. You don’t have to produce alternative versions of your application for different platforms, and you don’t have to distribute source code to end users. Figure 1-1. The Java runtime environment The fundamental unit of Java code is the class. As in other object-oriented languages, classes are application components that hold executable code and data. Compiled Java classesaredistributedinauniversalbinaryformatthatcontainsJavabytecodeandother class information. Classes can be maintained discretely and stored in files or archives locally or on a network server. Classes are located and loaded dynamically at runtime as they are needed by an application. In addition to the platform-specific runtime system, Java has a number of fundamental classes that contain architecture-dependent methods. These native methods serve as the gateway between the Java virtual machine and the real world. They are implemented in A Virtual Machine | 5
a natively compiled language on the host platform and provide low-level access to re‐ sources such as the network, the windowing system, and the host filesystem. The vast majority of Java, however, is written in Java itself—bootstrapped from these basic primitives—and is therefore portable. This includes fundamental Java tools such as the Java compiler, networking, and GUI libraries, which are also written in Java and are therefore available on all Java platforms in exactly the same way without porting. Historically, interpreters have been considered slow, but Java is not a traditional inter‐ preted language. In addition to compiling source code down to portable bytecode, Java has also been carefully designed so that software implementations of the runtime system can further optimize their performance by compiling bytecode to native machine code on the fly. This is called just-in-time (JIT) or dynamic compilation. With JIT compila‐ tion, Java code can execute as fast as native code and maintain its transportability and security. This is an often misunderstood point among those who want to compare language performance. There is only one intrinsic performance penalty that compiled Java code suffers at runtime for the sake of security and virtual machine design—array bounds checking. Everything else can be optimized to native code just as it can with a statically compiled language. Going beyond that, the Java language includes more structural in‐ formation than many other languages, providing for more types of optimizations. Also remember that these optimizations can be made at runtime, taking into account the actual application behavior and characteristics. What can be done at compile time that can’t be done better at runtime? Well, there is a tradeoff: time. The problem with a traditional JIT compilation is that optimizing code takes time. So a JIT compiler can produce decent results, but may suffer a significant latency when the application starts up. This is generally not a problem for long-running server-side ap‐ plications, but is a serious problem for client-side software and applications that run on smaller devices with limited capabilities. To address this, Java’s compiler technology, called HotSpot, uses a trick called adaptive compilation. If you look at what programs actually spend their time doing, it turns out that they spend almost all their time exe‐ cuting a relatively small part of the code again and again. The chunk of code that is executed repeatedly may be only a small fraction of the total program, but its behavior determines the program’s overall performance. Adaptive compilation also allows the Java runtime to take advantage of new kinds of optimizations that simply can’t be done in a statically compiled language, hence the claim that Java code can run faster than C/ C++ in some cases. To take advantage of this fact, HotSpot starts out as a normal Java bytecode interpreter, but with a difference: it measures (profiles) the code as it is executing to see what parts are being executed repeatedly. Once it knows which parts of the code are crucial to performance, HotSpot compiles those sections into optimal native machine code. Since it compiles only a small portion of the program into machine code, it can afford to take 6 | Chapter 1: A Modern Language
the time necessary to optimize those portions. The rest of the program may not need to be compiled at all—just interpreted—saving memory and time. In fact, the Java VM can run in one of two modes: client and server, which determine whether it emphasizes quick startup time and memory conservation or flat out performance. A natural question to ask at this point is, Why throw away all this good profiling infor‐ mation each time an application shuts down? Well, Sun partially broached this topic with the release of Java 5.0 through the use of shared, read-only classes that are stored persistently in an optimized form. This significantly reduced both the startup time and overhead of running many Java applications on a given machine. The technology for doing this is complex, but the idea is simple: optimize the parts of the program that need to go fast and don’t worry about the rest. Java Compared with Other Languages Java draws on many years of programming experience with other languages in its choice of features. It is worth taking a moment to compare Java at a high level with some other languages, both for the benefit of those of you with other programming experience and for the newcomers who need to put things in context. We do not expect you to have a knowledge of any particular programming language in this book and when we refer to other languages by way of comparison, we hope that the comments are self-explanatory. At least three pillars are necessary to support a universal programming language today: portability, speed, and security. Figure 1-2 shows how Java compares to a a few of the languages that were popular when it was created. Figure 1-2. Programming languages compared You may have heard that Java is a lot like C or C++, but that’s really not true except at a superficial level. When you first look at Java code, you’ll see that the basic syntax looks like C or C++. But that’s where the similarities end. Java is by no means a direct Java Compared with Other Languages | 7
descendant of C or a next-generation C++. If you compare language features, you’ll see that Java actually has more in common with highly dynamic languages such as Smalltalk and Lisp. In fact, Java’s implementation is about as far from native C as you can imagine. Ifyouarefamiliarwiththecurrentlanguagelandscape,youwillnoticethatC#,apopular language, is missing from this comparison. C# is largely Microsoft’s answer to Java, admittedly with a number of niceties layered on top. Given their common design goals and approach (e.g., use of a virtual machine, bytecode, sandbox, etc.), the platforms don’t differ substantially in terms of their speed or security characteristics. C# is theo‐ retically as portable as Java, but to date it is supported on far fewer platforms. Like Java, C#borrowsheavilyfromCsyntaxbutisreallyacloserrelativeofthedynamiclanguages. Most Java developers find it relatively easy to pick up C# and vice versa. The majority of time spent moving from one to the other is learning the standard library. Thesurface-levelsimilaritiestotheselanguagesareworthnoting,however.Javaborrows heavily from C and C++ syntax, so you’ll see terse language constructs, including an abundance of curly braces and semicolons. Java subscribes to the C philosophy that a good language should be compact; in other words, it should be sufficiently small and regular so a programmer can hold all the language’s capabilities in his or her head at once. Just as C is extensible with libraries, packages of Java classes can be added to the core language components to extend its vocabulary. C has been successful because it provides a reasonably feature-packed programming environment, with high performance and an acceptable degree of portability. Java also tries to balance functionality, speed, and portability, but it does so in a very different way. C trades functionality for portability; Java initially traded speed for portability. Java also addresses security issues that C does not (although in modern systems many of those concerns are now addressed in the operating system and hardware). In the early days before JIT and adaptive compilation, Java was slower than statically compiled languages and there was a constant refrain from detractors that it would never catch up. But as we described in the previous section, Java’s performance is now com‐ parable to C or C++ for equivalent tasks and those criticisms have generally fallen quiet. ID Software’s open source Quake2 video game engine has been ported to Java. If Java is fast enough for first-person combat video games, it’s certainly fast enough for business applications. Scripting languages such as Perl, Python, and Ruby are very popular. There’s no reason ascriptinglanguagecan’tbesuitableforsafe,networkedapplications.Butmostscripting languages are not well suited for serious, large-scale programming. The attraction to scripting languages is that they are dynamic; they are powerful tools for rapid develop‐ ment. Some scripting languages such as Perl also provide powerful tools for text-processing tasks that more general-purpose languages find unwieldy. Scripting languages are also highly portable, albeit at the source code level. 8 | Chapter 1: A Modern Language
1. See, for example, G. Phipps, “Comparing Observed Bug and Productivity Rates for Java and C++,”Software —Practice & Experience, volume 29, 1999. Not to be confused with Java, JavaScript is an object-based scripting language originally developed by Netscape for the web browser. It serves as a web browser resident language for dynamic, interactive web-based applications. JavaScript takes its name from its in‐ tegration with and similarities to Java, but the comparison really ends there. While there have been applications of JavaScript outside of the browser, it has not truly caught on as a general scripting language. For more information on JavaScript, check out Java‐ Script: The Definitive Guide by David Flanagan (O’Reilly). The problem with scripting languages is that they are rather casual about program structure and data typing. Most scripting languages (with a hesitant exception for Python and later versions of Perl) are not object-oriented. They also have simplified type systems and generally don’t provide for sophisticated scoping of variables and functions. These characteristics make them less suitable for building large, modular applications. Speed is another problem with scripting languages; the high-level, usually source-interpreted nature of these languages often makes them quite slow. Advocates of individual scripting languages would take issue with some of these gen‐ eralizations, and no doubt they’d be right in some cases. Scripting languages have im‐ proved in recent years—especially JavaScript, which has had an enormous amount of research poured into its performance. But the fundamental tradeoff is undeniable: scripting languages were born as loose, less structured alternatives to systems program‐ ming languages and are generally not ideal for large or complex projects for a variety of reasons, at least not today. Java offers some of the essential advantages of a scripting language: it is highly dynamic, along with the added benefits of a lower-level language. Java has a powerful Regular Expression API that competes with Perl for working with text and language features that streamline coding with collections, variable argument lists, static imports of meth‐ ods, and other syntactic sugar that make it more concise. Incremental development with object-oriented components, combined with Java’s sim‐ plicity, make it possible to develop applications rapidly and change them easily. Studies havefoundthatdevelopmentinJavaisfasterthaninCorC++,strictlybasedonlanguage features.1 Java also comes with a large base of standard core classes for common tasks such as building GUIs and handling network communications. But along with these features, Java has the scalability and software-engineering advantages of more static languages. It provides a safe structure on which to build higher-level frameworks (and even other languages). As we’ve already said, Java is similar in design to languages such as Smalltalk and Lisp. However, these languages were used mostly as research vehicles rather than for Java Compared with Other Languages | 9
development of large-scale systems. One reason is that these languages never developed a standard portable binding to operating system services, such as the C standard library or the Java core classes. Smalltalk is compiled to an interpreted bytecode format, and it can be dynamically compiled to native code on the fly, just like Java. But Java improves on the design by using a bytecode verifier to ensure the correctness of compiled Java code. This verifier gives Java a performance advantage over Smalltalk because Java code requires fewer runtime checks. Java’s bytecode verifier also helps with security issues, something that Smalltalk doesn’t address. Throughout the rest of this chapter, we’ll present a bird’s-eye view of the Java language. We’ll explain what’s new and what’s not-so-new about Java and why. Safety of Design You have no doubt heard a lot about the fact that Java is designed to be a safe language. Butwhatdowemeanbysafe?Safefromwhatorwhom?Thesecurityfeaturesthatattract the most attention for Java are those features that make possible new types of dynami‐ cally portable software. Java provides several layers of protection from dangerously flawed code as well as more mischievous things such as viruses and Trojan horses. In the next section, we’ll take a look at how the Java virtual machine architecture assesses the safety of code before it’s run and how the Java class loader (the bytecode loading mechanismoftheJavainterpreter)buildsawallarounduntrustedclasses.Thesefeatures provide the foundation for high-level security policies that can allow or disallow various kinds of activities on an application-by-application basis. In this section, though, we’ll look at some general features of the Java programming language. Perhaps more important than the specific security features, although often overlooked in the security din, is the safety that Java provides by addressing common design and programming problems. Java is intended to be as safe as possible from the simple mistakes we make ourselves as well as those we inherit from legacy software. The goal with Java has been to keep the language simple, provide tools that have demon‐ strated their usefulness, and let users build more complicated facilities on top of the language when needed. Simplify, Simplify, Simplify... With Java, simplicity rules. Since Java started with a clean slate, it was able to avoid features that proved to be messy or controversial in other languages. For example, Java doesn’t allow programmer-defined operator overloading (which in some languages al‐ lows programmers to redefine the meaning of basic symbols like + and –). Java doesn’t have a source code preprocessor, so it doesn’t have things like macros, #define state‐ ments, or conditional source compilation. These constructs exist in other languages primarily to support platform dependencies, so in that sense, they should not be needed in Java. Conditional compilation is also commonly used for debugging, but Java’s 10 | Chapter 1: A Modern Language
sophisticated runtime optimizations and features such as assertions solve the problem more elegantly (we’ll cover these in Chapter 4). Java provides a well-defined package structure for organizing class files. The package system allows the compiler to handle some of the functionality of the traditional make utility (a tool for building executables from source code). The compiler can also work with compiled Java classes directly because all type information is preserved; there is no need for extraneous source “header” files, as in C/C++. All this means that Java code requires less context to read. Indeed, you may sometimes find it faster to look at the Java source code than to refer to class documentation. Java also takes a different approach to some structural features that have been trouble‐ some in other languages. For example, Java supports only a single inheritance class hierarchy (each class may have only one “parent” class), but allows multiple inheritance of interfaces. An interface, like an abstract class in C++, specifies the behavior of an object without defining its implementation. It is a very powerful mechanism that allows the developer to define a “contract” for object behavior that can be used and referred to independently of any particular object implementation. Interfaces in Java eliminate the need for multiple inheritance of classes and the associated problems. As you’ll see in Chapter 4, Java is a fairly simple and elegant programming language and that is still a large part of its appeal. Type Safety and Method Binding One attribute of a language is the kind of type checking it uses. Generally, languages are categorized as static or dynamic, which refers to the amount of information about vari‐ ables known at compile time versus what is known while the application is running. In a strictly statically typed language such as C or C++, data types are etched in stone when the source code is compiled. The compiler benefits from this by having enough information to catch many kinds of errors before the code is executed. For example, the compiler would not allow you to store a floating-point value in an integer variable. The code then doesn’t require runtime type checking, so it can be compiled to be small and fast. But statically typed languages are inflexible. They don’t support collections as nat‐ urally as languages with dynamic type checking, and they make it impossible for an application to safely import new data types while it’s running. In contrast, a dynamic language such as Smalltalk or Lisp has a runtime system that manages the types of objects and performs necessary type checking while an application isexecuting.Thesekindsoflanguagesallowformorecomplexbehaviorandareinmany respects more powerful. However, they are also generally slower, less safe, and harder to debug. Safety of Design | 11
2. The credit for the car analogy goes to Marshall P. Cline, author of the C++ FAQ. The differences in languages have been likened to the differences among kinds of au‐ tomobiles.2 Statically typed languages such as C++ are analogous to a sports car: rea‐ sonably safe and fast, but useful only if you’re driving on a nicely paved road. Highly dynamic languages such as Smalltalk are more like an off-road vehicle: they afford you more freedom but can be somewhat unwieldy. It can be fun (and sometimes faster) to go roaring through the backwoods, but you might also get stuck in a ditch or mauled by bears. Another attribute of a language is the way it binds method calls to their definitions. In a static language such as C or C++, the definitions of methods are normally bound at compile time, unless the programmer specifies otherwise. Languages like Smalltalk, on the other hand, are called late binding because they locate the definitions of methods dynamically at runtime. Early binding is important for performance reasons; an appli‐ cation can run without the overhead incurred by searching for methods at runtime. But late binding is more flexible. It’s also necessary in an object-oriented language where new types can be loaded dynamically and only the runtime system can determine which method to run. Java provides some of the benefits of both C++ and Smalltalk; it’s a statically typed, late- binding language. Every object in Java has a well-defined type that is known at compile time. This means the Java compiler can do the same kind of static type checking and usageanalysisasC++.Asaresult,youcan’tassignanobjecttothewrongtypeofvariable or call nonexistent methods on an object. The Java compiler goes even further and prevents you from using uninitialized variables and creating unreachable statements (see Chapter 4). However, Java is fully runtime-typed as well. The Java runtime system keeps track of all objects and makes it possible to determine their types and relationships during execu‐ tion. This means you can inspect an object at runtime to determine what it is. Unlike C or C++, casts from one type of object to another are checked by the runtime system, and it’s possible to use new kinds of dynamically loaded objects with a degree of type safety. And because Java is a late binding language, it’s always possible for a subclass to override methods in its superclass, even a subclass loaded at runtime. Incremental Development Java carries all data type and method signature information with it from its source code to its compiled bytecode form. This means that Java classes can be developed incre‐ mentally. Your own Java source code can also be compiled safely with classes from other sources your compiler has never seen. In other words, you can write new code that references binary class files without losing the type safety you gain from having the source code. 12 | Chapter 1: A Modern Language
Java does not suffer from the “fragile base class” problem. In languages such as C++, the implementation of a base class can be effectively frozen because it has many derived classes; changing the base class may require recompilation of all of the derived classes. This is an especially difficult problem for developers of class libraries. Java avoids this problem by dynamically locating fields within classes. As long as a class maintains a valid form of its original structure, it can evolve without breaking other classes that are derived from it or that make use of it. Dynamic Memory Management Some of the most important differences between Java and lower-level languages such as C and C++ involve how Java manages memory. Java eliminates ad hoc “pointers” that can reference arbitrary areas of memory and adds object garbage collection and high- level arrays to the language. These features eliminate many otherwise insurmountable problems with safety, portability, and optimization. Garbage collection alone has saved countless programmers from the single largest source of programming errors in C or C++: explicit memory allocation and dealloca‐ tion. In addition to maintaining objects in memory, the Java runtime system keeps track of all references to those objects. When an object is no longer in use, Java automatically removesitfrommemory.Youcan,forthemostpart,simplyignoreobjectsyounolonger use, with confidence that the interpreter will clean them up at an appropriate time. Java uses a sophisticated garbage collector that runs in the background, which means that most garbage collecting takes place during idle times, between I/O pauses, mouse clicks, or keyboard hits. Advanced runtime systems, such as HotSpot, have more ad‐ vanced garbage collection that can differentiate the usage patterns of objects (such as short-lived versus long-lived) and optimize their collection. The Java runtime can now tune itself automatically for the optimal distribution of memory for different kinds of applications based on their behavior. With this kind of runtime profiling, automatic memory management can be much faster than the most diligently programmer- managed resources, something that some old-school programmers still find hard to believe. We’ve said that Java doesn’t have pointers. Strictly speaking, this statement is true, but it’s also misleading. What Java provides are references—a safe kind of pointer. A refer‐ ence is a strongly typed handle for an object. All objects in Java, with the exception of primitive numeric types, are accessed through references. You can use references to build all the normal kinds of data structures a C programmer would be accustomed to building with pointers, such as linked lists, trees, and so forth. The only difference is that with references, you have to do so in a typesafe way. Another important difference between a reference and a pointer is that you can’t play games (perform pointer arithmetic) with references to change their values; they can point only to specific objects or elements of an array. A reference is an atomic thing; Safety of Design | 13
you can’t manipulate the value of a reference except by assigning it to an object. Refer‐ ences are passed by value, and you can’t reference an object through more than a single level of indirection. The protection of references is one of the most fundamental aspects of Java security. It means that Java code has to play by the rules; it can’t peek into places it shouldn’t and circumvent the rules. Java references can point only to class types. There are no pointers to methods. People sometimes complain about this missing feature, but you will find that most tasks that call for pointers to methods can be accomplished more cleanly using interfaces and adapter classes instead. We should also mention that Java has a sophisticated Reflection API that actually allows you to reference and invoke individual methods. However, this is not the normal way of doing things. We discuss reflection in Chapter 7. Finally, we should mention that arrays in Java are true, first-class objects. They can be dynamically allocated and assigned like other objects. Arrays know their own size and type, and although you can’t directly define or subclass array classes, they do have a well- defined inheritance relationship based on the relationship of their base types. Having true arrays in the language alleviates much of the need for pointer arithmetic, such as that used in C or C++. Error Handling Java’s roots are in networked devices and embedded systems. For these applications, it’s important to have robust and intelligent error management. Java has a powerful excep‐ tion handling mechanism, somewhat like that in newer implementations of C++. Ex‐ ceptions provide a more natural and elegant way to handle errors. Exceptions allow you to separate error handling code from normal code, which makes for cleaner, more readable applications. When an exception occurs, it causes the flow of program execution to be transferred to a predesignated “catch” block of code. The exception carries with it an object that con‐ tains information about the situation that caused the exception. The Java compiler re‐ quires that a method either declare the exceptions it can generate or catch and deal with them itself. This promotes error information to the same level of importance as argu‐ ment and return types for methods. As a Java programmer, you know precisely what exceptional conditions you must deal with, and you have help from the compiler in writing correct software that doesn’t leave them unhandled. Threads Modern applications require a high degree of parallelism. Even a very single-minded application can have a complex user interface—which requires concurrent activities. As machinesgetfaster,usersbecomemoresensitivetowaitingforunrelatedtasksthatseize controloftheirtime.Threadsprovideefficientmultiprocessinganddistributionoftasks 14 | Chapter 1: A Modern Language
for both client and server applications. Java makes threads easy to use because support for them is built into the language. Concurrency is nice, but there’s more to programming with threads than just perform‐ ing multiple tasks simultaneously. In most cases, threads need to be synchronized (co‐ ordinated), which can be tricky without explicit language support. Java supports synchronization based on the monitor and condition model—a sort of lock and key system for accessing resources. The keyword synchronized designates methods and blocksofcodeforsafe,serializedaccesswithinanobject.Therearealsosimple,primitive methodsforexplicitwaitingandsignalingbetweenthreadsinterestedinthesameobject. Java also has a high-level concurrency package that provides powerful utilities address‐ ing common patterns in multithreaded programming, such as thread pools, coordina‐ tion of tasks, and sophisticated locking. With the addition of the concurrency package and related utilities, Java provides some of the most advanced thread-related utilities of any language. Although some developers may never have to write multithreaded code, learning to program with threads is an important part of mastering programming in Java and something all developers should grasp. See Chapter 9 for a discussion of this topic. Scalability At the lowest level, Java programs consist of classes. Classes are intended to be small, modular components. Over classes, Java provides packages, a layer of structure that groups classes into functional units. Packages provide a naming convention for organ‐ izing classes and a second tier of organizational control over the visibility of variables and methods in Java applications. Within a package, a class is either publicly visible or protected from outside access. Packages form another type of scope that is closer to the application level. This lends itself to building reusable components that work together in a system. Packages also help in designing a scalable application that can grow without becoming a bird’s nest of tightly coupled code. Safety of Implementation It’s one thing to create a language that prevents you from shooting yourself in the foot; it’s quite another to create one that prevents others from shooting you in the foot. Encapsulation is the concept of hiding data and behavior within a class; it’s an important part of object-oriented design. It helps you write clean, modular software. In most lan‐ guages, however, the visibility of data items is simply part of the relationship between the programmer and the compiler. It’s a matter of semantics, not an assertion about the actual security of the data in the context of the running program’s environment. Safety of Implementation | 15
When Bjarne Stroustrup chose the keyword private to designate hidden members of classes in C++, he was probably thinking about shielding a developer from the messy details of another developer’s code, not the issues of shielding that developer’s classes and objects from attack by someone else’s viruses and Trojan horses. Arbitrary casting and pointer arithmetic in C or C++ make it trivial to violate access permissions on classes without breaking the rules of the language. Consider the following code: // C++ code class Finances { private: char creditCardNumber[16]; ... }; main() { Finances finances; // Forge a pointer to peek inside the class char *cardno = (char *)&finances; printf("Card Number = %.16sn", cardno); } In this little C++ drama, we have written some code that violates the encapsulation of the Finances class and pulls out some secret information. This sort of shenanigan— abusing an untyped pointer—is not possible in Java. If this example seems unrealistic, consider how important it is to protect the foundation (system) classes of the runtime environment from similar kinds of attacks. If untrusted code can corrupt the compo‐ nentsthatprovideaccesstorealresourcessuchasthefilesystem,network,orwindowing system, it certainly has a chance at stealing your credit card numbers. IfaJavaapplicationistobeabletodynamicallydownloadcodefromanuntrustedsource on the Internet and run it alongside applications that might contain confidential infor‐ mation, protection has to extend very deep. The Java security model wraps three layers of protection around imported classes, as shown in Figure 1-3. Figure 1-3. The Java security model 16 | Chapter 1: A Modern Language
At the outside, application-level security decisions are made by a security manager in conjunction with a flexible security policy. A security manager controls access to system resourcessuchasthefilesystem,networkports,andwindowingenvironment.Asecurity manager relies on the ability of a class loader to protect basic system classes. A class loader handles loading classes from local storage or the network. At the innermost level, all system security ultimately rests on the Java verifier, which guarantees the integrity of incoming classes. The Java bytecode verifier is a fixed part of the Java runtime system. Class loaders and security managers (or security policies to be more precise), however, are components that may be implemented differently by different applications, such as servers or web browsers. All three of these pieces need to be functioning properly to ensure security in the Java environment. The Verifier Java’s first line of defense is the bytecode verifier. The verifier reads bytecode before it is run and makes sure it is well behaved and obeys the basic rules of the Java language. A trusted Java compiler won’t produce code that does otherwise. However, it’s possible for a mischievous person to deliberately assemble bad Java bytecode. It’s the verifier’s job to detect this. Once code has been verified, it’s considered safe from certain inadvertent or malicious errors. For example, verified code can’t forge references or violate access permissions on objects (as in our credit card example). It can’t perform illegal casts or use objects in unintended ways. It can’t even cause certain types of internal errors, such as overflowing or underflowing the internal stack. These fundamental guarantees underlie all of Java’s security. Youmightbewondering,isn’tthiskindofsafetyimplicitinlotsofinterpretedlanguages? Well, while it’s true that you shouldn’t be able to corrupt a BASIC interpreter with a bogus line of BASIC code, remember that the protection in most interpreted languages happens at a higher level. Those languages are likely to have heavyweight interpreters that do a great deal of runtime work, so they are necessarily slower and more cumbersome. By comparison, Java bytecode is a relatively light, low-level instruction set. The ability to statically verify the Java bytecode before execution lets the Java interpreter run at full speed later with full safety, without expensive runtime checks. This was one of the fun‐ damental innovations in Java. The verifier is a type of mathematical “theorem prover.” It steps through the Java byte‐ code and applies simple, inductive rules to determine certain aspects of how the byte‐ code will behave. This kind of analysis is possible because compiled Java bytecode contains a lot more type information than the object code of other languages of this Safety of Implementation | 17
kind. The bytecode also has to obey a few extra rules that simplify its behavior. First, most bytecode instructions operate only on individual data types. For example, with stack operations, there are separate instructions for object references and for each of the numeric types in Java. Similarly, there is a different instruction for moving each type of value into and out of a local variable. Second, the type of object resulting from any operation is always known in advance. No bytecode operations consume values and produce more than one possible type of value as output. As a result, it’s always possible to look at the next instruction and its operands and know the type of value that will result. Because an operation always produces a known type, it’s possible to determine the types of all items on the stack and in local variables at any point in the future by looking at the starting state. The collection of all this type information at any given time is called the type state of the stack; this is what Java tries to analyze before it runs an application. Java doesn’t know anything about the actual values of stack and variable items at this time; it only knows what kind of items they are. However, this is enough information to enforce the security rules and to ensure that objects are not manipulated illegally. To make it feasible to analyze the type state of the stack, Java places an additional re‐ striction on how Java bytecode instructions are executed: all paths to the same point in the code must arrive with exactly the same type state. Class Loaders Java adds a second layer of security with a class loader. A class loader is responsible for bringing the bytecode for Java classes into the interpreter. Every application that loads classes from the network must use a class loader to handle this task. After a class has been loaded and passed through the verifier, it remains associated with its class loader. As a result, classes are effectively partitioned into separate namespaces based on their origin. When a loaded class references another class name, the location of the new class is provided by the original class loader. This means that classes retrieved from a specific source can be restricted to interact only with other classes retrieved from that same location. For example, a Java-enabled web browser can use a class loader to build a separate space for all the classes loaded from a given URL. Sophisticated security based on cryptographically signed classes can also be implemented using class loaders. The search for classes always begins with the built-in Java system classes. These classes are loaded from the locations specified by the Java interpreter’s classpath (see Chap‐ ter 3). Classes in the classpath are loaded by the system only once and can’t be replaced. This means that it’s impossible for an application to replace fundamental system classes with its own versions that change their functionality. 18 | Chapter 1: A Modern Language
Security Managers A security manager is responsible for making application-level security decisions. A security manager is an object that can be installed by an application to restrict access to system resources. The security manager is consulted every time the application tries to access items such as the filesystem, network ports, external processes, and the window‐ ing environment; the security manager can allow or deny the request. Security managers are primarily of interest to applications that run untrusted code as partoftheirnormaloperation.Forexample,aJava-enabledwebbrowsercanrunapplets that may be retrieved from untrusted sources on the Net. Such a browser needs to install a security manager as one of its first actions. This security manager then restricts the kinds of access allowed after that point. This lets the application impose an effective level of trust before running an arbitrary piece of code. And once a security manager is installed, it can’t be replaced. The security manager works in conjunction with an access controller that lets you im‐ plement security policies at a high level by editing a declarative security policy file. Access policies can be as simple or complex as a particular application warrants. Some‐ times it’s sufficient simply to deny access to all resources or to general categories of services, such as the filesystem or network. But it’s also possible to make sophisticated decisions based on high-level information. For example, a Java-enabled web browser could use an access policy that lets users specify how much an applet is to be trusted or that allows or denies access to specific resources on a case-by-case basis. Of course, this assumes that the browser can determine which applets it ought to trust. We’ll discuss how this problem is addressed through code-signing shortly. The integrity of a security manager is based on the protection afforded by the lower levels of the Java security model. Without the guarantees provided by the verifier and the class loader, high-level assertions about the safety of system resources are mean‐ ingless. The safety provided by the Java bytecode verifier means that the interpreter can’t becorruptedorsubvertedandthatJavacodehastousecomponentsastheyareintended. This, in turn, means that a class loader can guarantee that an application is using the core Java system classes and that these classes are the only way to access basic system resources. With these restrictions in place, it’s possible to centralize control over those resources at a high level with a security manager and user-defined policy. Application and User-Level Security There’s a fine line between having enough power to do something useful and having all the power to do anything you want. Java provides the foundation for a secure environ‐ ment in which untrusted code can be quarantined, managed, and safely executed. How‐ ever, unless you are content with keeping that code in a little black box and running it just for its own benefit, you will have to grant it access to at least some system resources Application and User-Level Security | 19
so that it can be useful. Every kind of access carries with it certain risks and benefits. For example, in the web browser environment, the advantages of granting an untrusted (unknown) applet access to your windowing system are that it can display information and let you interact in a useful way. The associated risks are that the applet may instead display something worthless, annoying, or offensive. At one extreme, the simple act of running an application gives it a resource—compu‐ tation time—that it may put to good use or burn frivolously. It’s difficult to prevent an untrusted application from wasting your time or even attempting a “denial of service” attack. At the other extreme, a powerful, trusted application may justifiably deserve access to all sorts of system resources (e.g., the filesystem, process creation, network interfaces); a malicious application could wreak havoc with these resources. The mes‐ sage here is that important and sometimes complex security issues have to be addressed. In some situations, it may be acceptable to simply ask the user to “okay” requests. The Java language provides the tools to implement any security policies you want. However, what these policies will be ultimately depends on having confidence in the identity and integrity of the code in question. This is where digital signatures come into play. Digital signatures, together with certificates, are techniques for verifying that data truly comes from the source it claims to have come from and hasn’t been modified en route. If the Bank of Boofa signs its checkbook application, you can verify that the app actually came from the bank rather than an imposter and hasn’t been modified. Therefore, you can tell your browser to trust applets that have the Bank of Boofa’s signature. A Java Road Map With everything that’s going on, it’s hard to keep track of what’s available now, what’s promised, and what has been around for some time. The following sections constitute a road map that imposes some order on Java’s past, present, and future. The Past: Java 1.0–Java 1.6 Java 1.0 provided the basic framework for Java development: the language itself plus packages that let you write applets and simple applications. Although 1.0 is officially obsolete, there are still a lot of applets in existence that conform to its API. Java 1.1 superseded 1.0, incorporating major improvements in the Abstract Window Toolkit (AWT) package (Java’s original GUI facility), a new event pattern, new language facilities such as reflection and inner classes, and many other critical features. Java 1.1 is the version that was supported natively by most versions of Netscape and Microsoft Internet Explorer for many years. For various political reasons, the browser world was frozen in this condition for a long time. This version of Java is still considered a sort of baseline for applets, although even this will fall away as Microsoft drops support for Java in its platforms. 20 | Chapter 1: A Modern Language
Another Random Document on Scribd Without Any Related Topics
Poletes, n. pl. pullets, chickens, VIII a 275. [OFr. polete.] Polyse (V), Pollis(s)che, Pollysch, v. to polish, IX 35, 41, 119, 121, &c.; to cleanse, V 325. [OFr. polir, poliss-.] Pond, n.1 pool, lake, XIII a 19, 31, 43, &c.; Pound, XIII a 21, 23, 24, 25. [OE. *púnd, cf. pýndan.] Pond, n.2 pl. pounds, III 21, 24, &c.; Poundis, XI b 162. [OE. púnd.] Pope, n. Pope, I 249, VIII b 82, IX 286, XI b 46. [OE. pāpa.] Popi, n. poppy, XII a 81. [OE. popig.] Por-. See Pur-. Porche, n. porch, I 77. [OFr. porche.] Pore. See Pouer(e). Poret(te), n. (young) leek or onion, VIII a 281; collect. sg. VIII a 293. [OFr. poret, leek; porette, small onion.] Porful, adj. poverty-stricken, XV f 2. [From Pouer(e), Pore.] Porpos. See Purpos. Porter, n. porter (at the gates), II 380, V 4, &c. [OFr. port(i)er.] Portos, n. (pl. as sg.) breviary, XI b 228 (see note). [OFr. portehors.] Possyble, adj. possible, VI 92. [OFr. possible.] Post(e)les, n. pl. apostles, XV g 24, 25; itinerant preachers, VIII a 143. [OE. postol.] See Apostel. Potage, n. (vegetable) soup, VIII a 144. [OFr. potage.] Potful, n. potful, VIII a 180. [OE. pott + full (properly adj. with prec. noun).] Pound. See Pond. Pouerlich, adv. in humble guise, II 236, 567. [From prec.] Pouer(e), adj. poor, humble, II 430, 486, XII b 20, 36, &c.; Poeuere, XI b 272; Poure, III 48, IV b 20, VIII b 82; Pore, VI 213, VIII a 18, XI b 255, &c.; adj. pl. as sb., poor
(people), the poor, III 8, 41, VIII a 18, &c.; Pouren, dat. pl. III 7. [OFr. pov(e)re, poure.] Pour-. See Pur-. Power(e), Pouer, Poure, n. ability, power, VIII a 35, XII a 187, XVI 219; authority, VIII a 143; forces, XIV c 46. [OFr. po(u)eir, pouer.] Pray(e), n. prey, II 313, XVI 175; fig. (of good things won as prize) VI 79. [OFr. preie.] Prece, Pres(s), v. to press; thrust, force, X 49, 69, &c.; intr. and refl. to press forward, hasten, V 29, X 131; pressit on, assailed, X 190; hardest pressit, most hard pressed, X 150. See Prees. [OFr. presser; on forms prece, pre(e)s, see N.E.D.] Preche, v. to preach, VIII a 143, XI b 7, 24, XVI 51, &c.; Prechinge, -ynge, n. preaching, III 49, XI b 3, &c. [OFr. prech(i)er.] Precious, Precy(i)ous(e), adj. precious, costly, IX 42, 99, XI b 257; precious ston, II 151, 366, IX 123. [OFr. precious.] Preef, n. test, IX 128. [OFr. proeve.] See Preue. Prees, Press, n. press; crowd, XII b 213; uproar, commotion, XVI 125. [From Prece, q.v.] Preeued. See Preue. Preie, Preye(n), Prey, Pray(e), v. to pray, beg, II 534, IV b 8, VIII a 119, 250, XI b 37, XVII 242, &c.; Praid, Preide, Preyd(e), pa. t. I 89, II 224, VIII a 117, XII b 69; pray, pray to, VI 124; preye of, beg for, VIII a 38, 117; preye to, pray (to), IX 320, 322; Preiynge, n. in p. of lippes, prayer with lips (only), XI b 89. [OFr. preier.] Preiere, Preyer(e), Preȝer (XIV c), n. prayer, VIII a 244, b 88, XI b 36, XIV c 78, &c.; preiere in lippis, p. with the lips (only), XI b 90. [OFr. preiere.] Preise(n), Preyse, Prayse, v. to praise, esteem, V 4, VIII a 102, b 31, XI b 176, 182. [OFr. preis(i)er.] See Prese, Prys,
Prist. Preostes. See Prest(e), n. Pres(s). See Prece, Prees. Prese, n. praise, great worth, VI 59. [Stem of Preise(n) with AFr. monophthongization.] Presence, n. presence, IX 94, XII b 127, &c. [OFr. presence.] Present(e), adj. present, IX 128, 336; as sb. in in your presente, in your presence, VI 29. [OFr. present.] Present, n. present, gift, I 123, VIII a 42, 290. [OFr. present.] Presente, v. to give gifts to, IX 24. [OFr. presenter.] Prest, adj. prompt, quick, VIII a 190, XIV b 67; Prestly, adv. promptly, VIII a 87. [OFr. prest.] Prest(e), n. priest, I 8, 9, III 49 (dat.), 53, &c.; Preost, XI b 291. [OE. prēost.] Presthod, n. priesthood, XI b 47. [OE prēost-hād.] Pretermynable, adj. who predetermines, fore-ordains, VI 236. [Appar. invented for rhyme from pre + terminable used actively.] Preue, Preeue, v. to prove, show, VII 47, IX 298; to test, IX 297; to approve, IX 305. [OFr. preuv-, proev-, &c. accented stem of prover.] See Preef, Proue. Pryde, Pride, n. pride, magnificence, IV a 59, b 14, XI b 55, XVII 543, &c.; of pryde, proud, XVI 182. [OE. prȳdo.] See Proude. Priis. See Prys. Prike, v. to spur; intr. gallop, II 141, XIV a 15. [OE. prician, to prick.] Pryme, n. prime, first division of the day according to the sun (varying with the season), or a fixed period 6-9 a.m.; heighe pryme, fully prime, end of the period of prime, about 9 a.m., VIII a 106. [OE. prīm, from L. prīma (hōra).]
Prymer, n. devotional manual, VIII b 48 (note). [Origin of name doubtful; see N.E.D.] Primerole, n. primrose, XV e 9, 10, 13. [OFr. primerole.] Prynce, Prince, n. prince, V 4 (i.e. Sir Gawayne), XIV c 59, XVI 182, &c. [OFr. prince.] Princypall, Principall, adj. and n. chief, IX 1, 28, XVI 111; Principaly, adv. in the first place, XI b 96. [OFr. principal, or L. principālis.] Pryour, n. priory, VIII b 95. [OFr. priorie; with this form of the suffix cf. Oritore.] Prys, Prise, Priis (II), n. worth, excellence, V 296, VI 59; of priis, &c., worthy, excellent, noble, II 51, 64, 249, V 330, VII 47. [OFr. pris, earlier prieis.] See Preise(n), Prist. Prisoune, Prison, n. prison, XI b 126, XVI 220 (or read prisounes, prisoners; see note). [OFr. priso(u)n.] Prist, pp. esteemed, VII 33. [OFr. pris(i)er.] See Preise(n). Processioun, n. procession; pomp, II 587. [OFr. procession.] Proferi, Profre, v. to offer, II 434, V 278, VIII a 25, XII b 122, &c. [OFr. proffrir; proferer.] Profession, n. declaration; vows (on entering religious order), in singular prof., special vows, as opposed to the regular vows taken by all priests, XI b 101. [OFr. profession.] Profit, n. profit, VIII b 107. [OFr. profit.] Profit-, Profytable, adj. profitable, advantageous, VIII a 270, XIII b 68. [OFr. profitable.] Prologe, n. prologue, VII 96, [OFr. prologue.] Property, n. property, special virtue, VI 86. [OFr. proprieté.] Prophet(t)e, n. prophet, XI b 18, XV g 9, XVI 267, &c. [OFr. prophete, L. prophēta.] Prophecye, Prophicye, n. prophecy, IX 216, XVI 27. [OFr. prophecie.]
Prophicied, pa. t. prophesied (MS. prophicie), XVI 188. [From prec.] Propre, adj. proper, separate, IX 187; Propurly, adv. properly, rightly (or of my own knowledge, at first hand), IX 264. [OFr. propre.] Proude, Prowd(e), adj. magnificent, glorious, II 376; proud, haughty, arrogant, V 36, 201, VIII a 191, XV b 32, &c.; prowdist of pryde, greatest in pride (or splendour), XVII 543; Prowdly, adv. out of pride, XVII 17. [OE. prūt (rarely prūd), from OFr. prout, prou(d), valiant.] Proue, Prufe, v. to prove; demonstrate, show, X 74, XVI 255; test, try, XVII 460. [OFr. prover; cf. OE. prōfian.] See Preue. Prow(e) (to), n. benefit, good (of), IV b 82, XVI 220, 326; may to prow, may be of benefit ('prow' prob. apprehended as infin.), I introd. [OFr. prou.] Psalme, n. psalm, VIII a 246; Seuene Psalmes, the Seven Penitential Psalms, VIII b 49; note allit. with s. [OE. (p)salm, L. psalmus.] Puire, Puit. See Pure, Putte(n). Pull, v.; Puld, pa. t.; to drag, VII 178; pull up, hoist, VII 125, XVII 153. [OE. pullian.] Puple. See Peopull. Puplisshid, pp. (rime requires puplist), openly declared, XVI 59. [OFr. puplier + -is(h) from other verbs of Fr. origin.] Purchase, Porchase, Pourchace, v. to acquire, obtain, VI 79, VIII b 81, XII a 18. [OFr. p(o)urchac(i)er.] Pure, Puire, adj. pure; elegant, seemly (cf. Clene), V 330; utter, sheer, VIII a 111, IX 31, XIV c 13. [OFr. pur.] Pure(n), v. to purify, V 325, IX 45. [OFr. purer.] Purgatorie, n. Purgatory, VIII a 45. [L. Purgātōrium.] Purge, v. to purge out, IV b 77. [OFr. purg(i)er.] Purper, adj. purple, II 242. [OFr. purpre; cf. OE. purpuren.]
Purpos(e), Pourpos, Porpos, n. intention, purpose, resolve, IV b 73, VI 148, VII 118, XII a 21, XIV b 39; put in a p., resolved, VII 112. [OFr. po(u)rpos.] Purpose(n), v. to intend, XI b 110. [OFr. po(u)rposer.] Purs, n. purse, XII b 157, 173, 182. [OE. purs.] Pursewe, Pursuen, Poursuie, v. to follow, pursue, IX 229. XII b 7; persecute, torment, IX 93; pursewe to, go eagerly to, XVI 316. [OFr. pursiwer, pursuer.] Purvaye, Purueye (to), v. to provide, prepare (for), XVI 69, XVII 553. [OFr. po(u)rveier.] Putte(n), Puit (XIV c), v.; Put(te), pa. t. and pp.; to thrust, IV b 3, 10, X 187, XVI 259, XVII 39; to put, set, VII 112 (see Purpos), VIII a 191, XII b 141, XIV c 12, XVII 21; to impose, XI a 64; putte awey, do away with, XI b 127; putten errour in, impute error to, XI b 77; put hom þerto, set themselves to the task, VII 33; putten hem into, put out on, IX 183; put vnto payn, set in torment, XVII 547; putte wryten, set in writing, IX 318. [OE. pū̆ tian, pȳtan, potian; see N.E.D.]
Qu(h)-. See also Wh-. Qualitee, n. degree (of goodness), question of how good, IX 335. [OFr. qualité.] Quantytee, Quantité, n. limitation of greatness, question of how great, IX 336; capacity, quantity, X 26. [OFr. quantité.] Quarell, n. cross-bow bolt, IX 258. [OFr. quar(r)el.] Quaþ, Quath, pa. t. sg. quoth, said, II 127, VIII b 26, &c.; Quatȝ, VIII a 3; Quod, V 58, VI 61, &c. [OE. cwæþ.] Queer, n. choir, VIII b 63, XI b 172. [OFr. cuer.] Queynt, adj. skilful, elegant, II 299, 300 (see Pas); Koyntly, adv. cunningly, V 345. [OFr. cointe, queinte, &c.] Quelle, Qwell, v. to kill, destroy, IV a 92, V 41. [OE. cwellan.] Queme, adj. pleasant, V 41. [OE. cwēme.] Quen. See Whan(ne). Quen(e), Queen(e), n. queen, II 51, 71, VI 55, IX 190, XII a 195, &c. [OE. cwēn.] Querele, n. (legal) complaint, accusation, XII b 209. [OFr. querel(l)e.] Questioun, n. question, IX 178. [OFr. questioun.] Quhedirand, pres. p. whirling, or whirring, X 92. [Cf. Early ME. to-hwideren, -hwiðeren, whirl to pieces; OE. hwaþerian, make a rushing noise.] Quhelis, n. pl. wheels, X 17. [OE. hwē(o)l.] Quhen; Quhill. See Whan(ne), Whil. Quyk, adj. alive, V 41. [OE. cwic.] Quyte; Qwyte, Qwite (XVII); v. to pay, repay, V 176, 256, VI 235, XVII 216, 228; Quitte, pp. paid, VIII a 92. [OFr. quiter.] Quite, Quyte. See Whyyt. Quo(m); Quod. See Who; Quaþ. Qwake, v. to tremble, IV a 61. [OE. cwacian.]
Qwart, n. health; mase in qwart, heals, IV a 15. [ON. kvirt, (neut. adj.) untroubled.] Qwiles. See Whiles. Race, Rase, n. headlong course, XVII 429; onslaught, violent blow, V 8. [ON. rás infl. by senses of related OE. rǣs.] Raȝt, Raid. See Reche; Ride. Rayle, v. to order, array, XV b 13. [OFr. reiller.] Rayn, v. to rain, XVII 147; Renys, pl. are raining down, XVII 351. [OE. regnian.] Rayn(e), n.1 rain, VII 109, 132, XVII 445; Reyn(e), I 162, XIII a 18. [OE. regn.] Rayne, n.2 rein, V 109. [OFr. raigne, rainne, &c.] Raysede, pp. uplifted, IV b 71. [ON. reisa.] Rake, n. path, V 76, 92. [OE. racu, water-course, or ON. rák, streak (Norw. dial. raak, path).] Ram-skyt, n. a term of abuse, XVII 217. [OE. ramm + ON. skita.] Ran(ne). See Ryn. Randoune, n.; in a randoune, with a rush, X 102. [OFr. en un randon.] Ranke, adj. brave, fine, VII 122. [OE. ranc.] Rape, v. refl. to hasten, VIII a 112, b 108. [ON. hrapa.] Rapely, adv. hastily; quickly, V 151; rashly, VI 3. [ON. hrapalliga.] Rapes; Rase. See Ropis; Race. Rather, adv. earlier, VIII a 112. [OE. hraþor.] Rathly, adv. quickly, XIV b 6. [OE. hræþ-līce.] Raton, n. rat, XV i 1, 9, 18. [OFr. raton.] Raþeled, pp. entwined, V 226. [See N.E.D. s.vv. Raddle, v.1 , Ratheled.]
Raue, v. rave, talk foolishly, VI 3. [OFr. raver.] Ravyn, n. raven, XVII 479, 499. [OE. hræfn.] Rauysche, v. to carry off captive, carry away, IV a 16; Reuey<se>d, pp. II 82. [OFr. ravir, raviss-.] Rawe; Rawþe. See Rowe; Reuþe. Real, adj. royal, II 356. [OFr. real.] Reame, n. realm, kingdom, VIII b 78; Reume, XI a 25, 32, 52; Rem(e), VI 88, XIII b 47, 48; Roialme, IX 261. [OFr. re(i)alme, re(a)ume; later roialme.] Reasoune. See Reson. Rebalde, n. Rascal, XVI 99. [OFr. ribauld.] See Rybaudry. Rebuke, v. to rebuke, VI 7, VIII b 86. [ONFr. rebuk(i)er.] Receyue, v. to receive, take, VIII b 73; Res(s)ayue, V 8, XVI 390; Resceyued, pp. XI b 265. [OFr. receiv-re.] Reche, Recche, v.1 to reck, care, VIII a 114; me no reche, I care not (mixed pers. and impers. constr.), II 342. [OE. reccan.] Reche, v.2 to give, V 256; Raȝt, pa. t. V 229; Raȝteȝ, 2 sg. V 283. [OE. rǣcan, rǣ̆ hte, rā̆ hte.] Reches, n. sg. riches, IV b 61. [OFr. richesse.] Recorde, v. to ponder, go over in one's mind, IX 317; record, XII introd., b 111. [OFr. recorder.] Recoueren, v. to regain, IX 131. [OFr. recovrer.] See Keuer(e). Recuyell, n. compilation, VII introd. [OFr. recueil.] Red(e), adj. red, II 107, XIV b 41, XV e 19; red(e) gold, red gold, II 150, 362. [OE. rēad.] Red(e), n. advice, III 51 (dat.); counsel, plan, in can no other red, sees nothing else for it, XII b 102 (cf. Wane, n.). [OE. rǣd, rēd.] Red(e), Redyn, Reede, v. to advise, counsel, IV a 45, V 43 (note), VIII b 108, XIV c 97, XVII 341, &c.; to read, II 1, IV b 9, X introd., XII a 112, &c.; to read aloud, I 14; to reckon,
VIII b 73; to think, XVII 427; hard red (inf.), heard read, XVII 46; Ret (OE. rǣ̆ tt, rē̆ t), 3 sg. pres. reads, III 3, 16; Rede, pp. read, XVI 317. [OE. rǣdan, rēdan, str., later wk.] Redere, n. reader, IX 321. [OE. rǣdere.] Redi, Redy, adj. prompt, ready (to hand), II 380, VI 231, X 34, XII b 119, XVI 394; al redy, prompt(ly), XVI 120; Redyly, adv. promptly, V 256. [Extended from OE. (ge-)rǣde.] Redresse, v. to redress, set right, XII b 206. [OFr. re-dresser.] Reformed (of), pp. changed back to his proper form (from), XII a 19. [OFr. reformer.] Refuseþ, pres. pl. reject, VIII b 82. [OFr. refuser.] Reghtewysnes, Reghtwysely. See Ryghtwyse. Regioun, n. region, IX 161, XII a 13. [OFr. regioun.] Regne, n. kingdom, VI 141. [OFr. regne.] Regni, Regne, v. to reign, II 425, IX 339. [OFr. regner.] Reherce, Reherse, v. to repeat, XI a 4, XII a 103; Rehercyng(e), n. recounting, IX 274, 279. [OFr. rehercer.] Reyll, n. reel, XVII 298 (see Garn). [OE. hrēol.] Reynand. See Ren. Reyny, adj. rainy, XII a 53. [OE. regnig.] See Rayn(e), n.1 Rele, v. to reel, behave wildly, sway (in combat); rele as vs likeȝ, let us fight as fiercely as we please, V 178. [Prob. related to Reyll.] Relece, v. to release, V 274. [OFr. relaissier, relesser.] Relees, Reles, n. release, discharge, VIII a 84, XVI 288, 290. [OFr. reles.] Releif, Releue, v. to relieve, give relief to, X 151, 161, XI b 255. [OFr. relever.] Religioun, n. religious rule, or order, VIII a 145. [OFr. religion.] Relikes, n. pl. heirlooms, precious things, VII 122. [OFr. relique.] Rem(e). See Reame.
Remembraunce, n. recollection, VIII b 11. [OFr. remembra(u)nce.] Remene (to), v. to compare (to), interpret (as), XIV c 41. [? OFr. remener, bring back; senses seem due to assoc. with Mene, v.1 ] Remissioun, n. discharge, pardon, VIII a 84. [OFr. remissioun.] Remytte, v. to hand on, refer (for consideration), IX 296. [L. remittere.] Remnaunt, Remenaunte, n. remainder, V 274, 333, VIII a 94. [OFr. remenant.] Remorde, pp. afflicted, VI 4. [OFr. remord-re.] Remwe, v. to take away, VI 67. [OFr. remuer.] Ren, Renne, v. to run, XIV b 6; to flow, IX 179, XII a 84; ? Reynand, pres. p. XVII 111; see Ryn. [ON. renna.] Renys. See Rayn, v. Renk, n. knight, man, V 138 (see note), 178, 269. [OE. rinc.] Renne-aboute, Gad-about, Vagabond, VIII a 142. [From Ren.] Renoun, Renowne, n. renown, glorious name, in of renoun, renouns (pl. in Fr. constr., with ref. to several persons), I 248, II 202, XIV b 81. [OFr. renoun.] Rent, pp. torn, VII 147. [OE. rendan.] Rental, n. rent-book, VIII a 84 (see note). [OFr. rental.] Rentes, n. revenues from property, VIII b 77, XI b 96. [OFr. rente.] Reparde, pp. shut off, barred, VI 251. [OFr. re- + ME. parren.] Repe, v. to reap, VIII b 15. [OE. rī̆pan; on stem-vowel see N.E.D. s.v. Reap.] Repent(e), v. to repent, XVII 81, 91, 117. [OFr. repentir.] Repentance, n. repentance, XVII 56. [OFr. repentance.] Repereyue, n. head-reaper, harvest-overseer, VIII b 15. [OE. rip, harvest (or stem of prec.) + rēfa.] See Reue, n.
Repleye, v. XVI 380 (see note). [Cf. OFr. repley(i)er, &c. or replevir; see N.E.D. s.vv. Repledge, Replevy, &c.] Reprené, v. to reprehend, find fault with, VI 184. [OFr. reprendre, preign-.] Repreue, Reprouen (of), v. to reprove (for), V 201, XI b 187. [OFr. repro(u)ver, repreuv-.] Reprufe, n. disgrace, XVII 84. [OFr. repro(u)ve.] Rerd, Rurde (V), n. loud voice V 269, XVII 230; noise, V 151 (see Rusche), XVII 101. [OE. réord.] Rert, pp. ? (aroused), ready, VI 231. [OE. rǣran.] Res(s)ayue, Resceyued. See Receyue. Rescowe, Rescoghe, n. rescue, V 240; matȝ rescoghe, ? comes to the rescue (cf. make reschewes, Morte Arthure 433), VI 250 (see note). [Stem of ME. rescouen, v., OFr. rescourre.] Resette, n. (place of) refuge, shelter, V 96. [OFr. recet.] Residue, n. residue, VIII a 94. [OFr. residu.] Reson, Resoun(e), Reasoune, n. reason, (good) sense, VIII a 311, XI a 30, 48, b 6, XII b 225, XVII 501, &c.; (personified) VIII b 5, &c.; what is reasonable, XVI 263; reasoning, XVI 255; argument, saying, XVI 337; by reson, as a logical consequence, XVII 81; motive, in by þat resoune, with that intent, XVI 248. [OFr. raison, re(i)son.] Resonabele, adj. reasonable, VI 163. [OFr. resonable.] See Vnresounable. Restay, v. to stop; intr. to pause, VI 77. [OFr. resteir; see N.E.D., s.v. Stay, v.] Restor(e), v. to restore, V 215, XVI 13, XVII 29; trwe mon trwe restore, let an honest man honestly restore (another's property), V 286. [OFr. restorer.] Ret. See Red(e), v. Reue, n. reeve, manager of an estate, VI 182, XI b 288. [OE. (ge-)rēfa.]
Reue, v. to rob, steal, IV b 20; constr. with dat. pron. of person deprived, IV a 83, XV c 31. [OE. rēafian.] Reuey<se>d. See Rauysche. Reuel, v. revel, V 333. [OFr. reveler.] Reuerence, n. reverence; at þe r., out of respect, V 138; do a r., make an obeisance, XII b 128. [OFr. reverence.] Reuerse, v. to reverse, countermand, XI a 15. [OFr. reverser.] Reuest, pa. t. (refl.) vested, robed (himself), I 70. [OFr. revestir.] Reulis, n. pl. rules, XI b 203. [OFr. reule.] See Rewle. Reume. See Reame. Reuþe, Rawþe, n. (mental) pain, grief; hedde r. þerof, was grieved at that, III 20; r. to here, grievous to hear, V 136 (cf. Noy, Pine). [Extended with suffix -þ from OE. hrēow; cf. ON. hrygð.] See Rewe(ful). Reward(e), n. regard, consideration, in takeþ r. of (to), give a thought (to), XIV c 105-7; reward, VI 244, XII b 42. [ONFr. reward.] Rewardeþ, 3 sg. pres. gives reward, VIII b 32. [ONFr. rewarder.] Rew(e), v. to rue, regret, II 570, XVII 202; it shal him rewe, he shall rue it, XV a 23. [OE. hrēowan, pers. and impers.] Reweful, Ruful (V), adj. rueful; piteous, II 114; grievous, V 8. [OE. hrēow + full.] Rewle, v. to guide, XVII 429. [OFr. reuler.] See Reulis. Rybaudry, n. ribaldry, coarse jesting, II 9. [OFr. ribauderie.] See Rebalde. Ribbes, n. pl. ribs, IX 257. [OE. ribb.] Riche, Ryche, adj. of high rank, noble, II 326, 446, VIII b 26, XV g 18, &c.; wealthy, III 52, &c.; splendid, costly, rich, II 81, 161, 356, &c.; high (feast), V 333; quasi-sb. noble (steed),
V 109; adv. (or predic. adj.) richly, II 362. [OE. rīce; OFr. riche.] Ryche, n. kingdom, VI 241. [OE. rīce.] See Heuenryche. Ryched, pp. directed, intended, V 138. [OE. reccan, but form prob. due to confusion with ME. richen, ruchen (OE. *ryccan), draw.] Richt, Rycht. See Right. Rydde, v. to separate (combatants), V 178. [Blend of OE. hreddan, rescue, and ON. ryðja, rid.] Ride, Ryde, v. to ride, II 340 (subj.), 347, V 39, 76 (note), &c., Raid, pa. t. sg. X 149; Rod(e); I 62, V 21, XV a 4; him rod, sailed, XIV c 61; Riden, pl. II 308; Ryden, pp. gone on military service (as knights), VIII b 78. [OE. rīdan.] Rifild, pp. despoiled, XIV a 16, 17. [OFr. rifler.] Rife, adj. plentiful, VII 122. [Late OE. rȳfe, *rīfe.] Ryfis. See Ryue. Rigge, n. back, II 500; Rugge, XV g 4. [OE. hrycg.] Right, Ryght, Rihte (XII), adj. right, proper, true, XII a 124, XVI 255, XVII 471, &c.; right (hand), IX 70. [OE. riht.] Right, Ryght, Riȝt(e), Ryȝt, Riht (XII, XIV c); Richt, Rycht (X); adv. straight, right, II 100, 186, V 94, &c.; ful riȝt, straight (away), II 85, 191; ryght vprise (cf. Vpperight), rise up, XVI 31; correctly, XVII 139; exactly, just, right, I 94, II 166, V 236, IX 64, X introd., 102, XII a 146, XVII 513, &c.; richt evin, just, X 93; (with neg.) at all, VI 160, VIII a 145, b 86, XVII 524, &c.; very, IX 150, X 138, XIV c 10, &c. [OE. rihte.] Right, Ryght, Ryȝt, n. right, XIV b 37; justice, V 278, VI 136, 231; just cause, VIII b 78; by þe way of ryȝt to aske dome, if they demand an award acc. to strict justice, VI 220; Ryȝtes, Riȝttis, pl. duties, XI b 203; obligations, V 274. [OE. riht.] Right, pa. t. corrected, VII 69. [OE. rihtan.]
Rightfull, adj. just, IX 82; Riȝtfulleste, superl. XI b 193. [OE. (late) riht-ful.] Ryghtfulnesse, n. Justice, VIII b 32. [From prec.] Ryghtwyse, adj. righteous, IV b 7; Reghtwysely, adv. righteously, IV b 55; Reghtewysnes, n. righteousness, IV b 80. [OE. rihtwīs (rehtwīs), -līce, -nes.] Riȝtes; al to riȝtes, quite correctly, fittingly, II 136; to his riȝtes, as he should be, fittingly, II 292. [Extension of to riȝt, according to what is right (see Right, n.), with adv. -es.] Ryme, n. riming poem, I introd.; Rymys, pl. (trivial) popular poems, I 14; Ryme couwee, see Couwee. [OFr. rime.] Ryn, v. to run, flow, pass swiftly, X 17, XVII 101, 277, 305, 357; Ran(ne), pa. t. I 155, IV a 9 (note), X 107; Runne, pp. in be runne, may have mounted up, VI 163. [OE. rinnan.] See Eorne, Ren(ne). Rinde, n. bark, II 260. [OE. rínd.] Ryne, v. to touch, V 222 (see note). [OE. hrīnan.] Rynge, v. to ring, resound, XV b 12; Ronge, pa. t. V 136; Ry<n>kande, pres. p. V 269 (confus. of ng, nk, freq. in this poem). [OE. hríngan, wk.] Ryot, n. strife, violence, IX 83. [OFr. riot(e).] Rype, Ripe, adj. ripe, VIII a 289, IX 140. [OE. rīpe.] Ris, n. leafy spray, II 305. [OE. hrīs.] Rise, Ryse, v. to rise, IV a 62, V 17, XVI 394, &c.; Ros, pa. t. sg. VI 77, 146, 159; Ryse, pl. I 208; Rysen, pp. XVII 442; Rysing, n. resurrection, XVI 317. [OE. ā-rīsan.] Ryste, n. repose, rest, IV b 10; Rest(e), II 74, IV a 3, &c. [OE. rest; on y-form see N.E.D. s.v. Rest.] Ryste, Rest(e), v. to rest; intr. IV b 42, V 263; refl. IV b 38, IX 20. [OE. restan; see prec.] Ryue, v. to tear (asunder), cleave, V 222 (note); Ryfis, 3 sg. pres. intr. is torn, XVII 399; Roue, pa. t. V 278; Ryue, pp. I 121. [ON. rīfa.]
Riueling, n. a rough shoe (as nickname for a Scot), XIV a 19. [OE. rifeling.] Riuer(e), Ryuer(e), n. river, II 160, 308, IX 12, XII a 85, XIII a 16, &c. [OFr. rivere.] Ro, n. peace, XVII 237. [OE. rōw, ON. rō.] Robbe, v. to rob; Yrobbed, pp. III 18; Robbing, n. XIV b 6. [OFr. rob(b)er.] Robbere, n. robber, XIV a 6. [From prec.; OFr. robbour.] Robe, n. robe, II 81. [OFr. robe.] Roc, Rokke, n. rock, V 76, 130, XV g 12. [Cf. OE. gloss stānrocc, scopulus; OFr. ro(c)que.] Roche, n. rock, II 347, V 131, IX 33, 62, &c.; Rooch(e), XIII a 21, 22. [OFr. roche.] Roché, adj. rocky, V 226. [From prec.] Rod(e). See Ride. Rode, n.1 rood, cross, VIII a 94, XIV c 73. [OE. rōd.] Rode, n.2 rosy hue, fair face, II 107, XV b 13. [OE. rudu.] Rof, adj. rough; grievous (with sore), or ? n. gash, V 278 (note). [(i) As next with alteration of final spirant (cf. Þof), though this is not the usual form of 'rough' in this text. (ii) Related to Ryue, v.] Roȝ(e), adj. rough, rugged, V 94, 109, 130; Rouh, XIV c 37; Rowe, II 265, 459 (see Blac); Ruȝe, V 98. [OE. rūh, rūg-, rūw-.] Roialme. See Reame. Royis, 2 sg. pres. talkest folly, XVI 99. [Unknown.] Rok, n. distaff, XVII 338. [Cf. ON. rokk-r, MDu., MLG. rocke(n).] Rokke. See Roc. Romayn, n. a Roman, VII 69. [OFr. romain.] Romance, n. (French) romance, story, XIV b heading. [OFr. romanz.]
Rome, v. to wander, make one's way, V 130, VIII b 11. [ME. forms point to OE. *rāmian.] Rooch(es). See Roche. Rooris, 2 sg. pres. roarest, XVI 99. [OE. rārian.] Rooþur. See Roþur. Ropis, Rapes, n. pl. ropes, VII 147, XIV b 68. [OE. rāp.] Ros. See Rise. Rose, n. rose, XV b 13, e 19. [OE. rose from L. rosa.] Rote, n.1 root, V 226, VI 60 (origin), VIII a 97, XIV c 82; Rote, pl. (or collect. sg.), II 256, 260. [ON. rōt.] Rote, n.2 way, in bi rote, on the way, V 139. [OFr. rote.] Roted, pa. t. rotted, I 236. [OE. rotian.] Roþur, Rooþur, n. rudder, XIV c 25, 29, 36, 57. [OE. rōþor.] Roue; Rouh. See Ryue; Roȝ(e). Roun(e), n. speech, voice, XV b 2, 29 (see note), c 36; [OE. rūn.] Round, adj. round; adv. in al aboute round (as prep.) round, XII a 79; Roundnesse, n. roundness, IX 67. [OFr. roönd, round.] Rout(e), n.1 host, company, (great) number, II 283, X 176, XII b 118, XIV a 16; on a route, in a mass, tumultuously, XVII 305. [OFr. route.] Rout, n.2 roar, loud noise, X 92. [Stem of OE. hrūtan, or ON. rauta; see Rowtyn.] Rouwed, pa. t. rowed, XIV c 61. [OE. rōwan, str.] Rowe, Rawe, n. row, VI 185; be rowe (rawe), on rawe, in (due) order, in turn, XV h 15, XVI 317, 401. [OE. rāw.] Rowe. See Roȝ(e). Rowtyn, pres. pl. they crash, beat, XV h 15. [OE. hrūtan; but see N.E.D. for various sources and senses of Rout, n. and v.]
Rude-evyn, n. eve of the feast of the (Exaltation of the) Cross, X 42. [OE. rōd + ǣfen.] See Rode, n.1 Ruful. See Reweful. Rugge; Ruȝe. See Rigge; Roȝ(e). Rugh-fute, n. rough-footed, XIV a 19. [OE. rūh + fōt.] See Roȝ(e), Fote. Ruysand, pres. p. glorifying, in r. hyme of, glorying in, taking credit to himself for, IV b 80. [ON. hrósa sér.] Runne; Rurde. See Ryn; Rerd. Rusche, v. to rush; make a loud rushing noise, V 136; rusched on þat rurde, ? went on with that rushing noise, V 151. [Echoic, but app. based on OFr. r(e)usser, AFr. russ(h)er.] Sa, Saat. See So; Sitte(n). Sacramente, n. sacrament, XVI 316. [L. sacrāmentum.] Sacrifise, -ice, n. sacrifice, XI b 202, XII a 15, 40. [OFr. sacrifice.] Sacrylage, n. sacrilege, I 4, 19. [OFr. sacrilege, infl. by suffix - age.] Sad(de), adj. steadfast, IX 92; heavy, grievous, XVI 44; sette hym sadde, give him sorrow, XVI 204; Sadly, adv. sufficiently, long enough, V 341. [OE. sæd, sated, wearied; ME. shows also senses 'heavy, firm', &c.] Sadel, n. saddle, V 42. [OE. sadol.] Saf(e), see Saue; Sagh, see Se(n); Say, Sai-, see Se(n), Sei(e). Saye, v. to make trial of, explore, XIV c 34. [Shortened from Assaie.] Sayf. See Saue, prep. Sayl(l), Sail, n. sail, VII 125, XIV c 50, XVII 153, 271, &c. [OE. segl.] See Seile. Sayn, Saytz, see Sei(e); Saynte, see Seynte.
Sake, n. in for ... sake (with interven. gen. or poss. adj.), (i) for (one's) sake, VIII a 96, XII introd.; (ii) on (one's) account, XV c 23; (with loss of prec. inflexion) I 177, XVII 88 (note). [OE. sacu; cf. ON. fyrir sakir because of.] Sakke, n. sack, VIII a 9. [OE. sacc.] Sakles, adj. innocent (i.e. against whom you had no just quarrel), XIV a 3. [OE. sac-lēas, from ON. sak-lauss.] Sale, n. in to the sale, for sale, XII b 148. [OE. *salu, (once) sala.] Sal(l), Saltou. See Schal. Salt(e), adj. salt, VIII a 279, IX 13, XII a 166, &c.; n. XIII a 30. [OE. salt, adj. and n.] Salvacioun, n. salvation, IX 333. [OFr. salvacioun.] Sam(e), Samen, Somyn (VII), adv. together, VII 66, XVI 170, 239, XVII 316; brether sam, brothers both, XVII 320; al samen, all sam (togeder), (all) together, XVII 292, 530; with one accord, VI 158; see Alsaume. [OE. æt samne, somne; (late) somen; cf. ON. allir saman.] Same, adj. same I 188, &c.; pron. in þe (þis) same, the very one (or thing), XII b 78, XVI 56, 71, &c. [ON. sam-r.] Samon, n. salmon, XIII a 64. [OFr. saumon.] Sample, n. illustration, parable, VI 139. [Shortened from OFr. essample.] See Ensample. Sand, n. sand, shore; bi see and bi sand, everywhere, XVII 75. [OE. sánd.] Sang, Santis. See Song(e), Seynte. Sap, n. sap, XIV c 90. [OE. sæp.] Saphire, n. sapphire, IX 115, 116 (see Loupe), 122. [OFr. safir.] Sapience, n. Wisdom; personif. of the 'sapiential' books (Proverbs, Ecclesiastes, Canticles, Wisdom, Ecclesiasticus), VIII a 231 (the ref. is to Prov. xx. 4). [L. sapientia.] Sare. See Sore.
Sarri, adj. ? vigorous, XIV c 90. [OFr. serré; see note.] Sarteyne; Sat. See Certeyne; Sitte(n). Sauce, n. sauce, VIII a 259. [OFr. sauce.] Saue, Saf, adj. safe; a saue, have safe, save, I 127 (see Habben); vochen saf, VIII b 51, see Vouche-saf. [OFr. sauf, sauve (fem.).] Saue, Saf, Sayf (XVII), prep. save, except, IX 174, 228, XVII 106; saue þat (conj.), V 161. [OFr. sauf.] Saue, Safe (XVII), v. to preserve, keep safe, V 5 (subj.), 71, XV i 19, XVII 309, 517, &c.; rescue, bring to salvation, XI a 38, b 305, XVI 108, &c. Sauynge, n. preservation, XI b 304. [OFr. sa(u)ver.] Saufly, adv. safely, XII b 174. [From Saue, adj.] Saugh. See Se(n). Saul(e), Saull, Sawl(e), Soule, n. soul, IV a 24, 32, 61, VIII a 81, XVI 272, XVII 390, &c.; distrib. sg. (see Herte), XI b 250; Soule, gen. sg. I 212. [OE. sāwol.] Sauour (to), n. savour, IX 153; relish (for), XI b 254. [OFr. savour.] Sauoure, v. to give a savour to, VIII a 259. [OFr. savourer.] Sauter, Sawter, n. the Psalter, Book of Psalms, VI 233, VIII a 246, b 49, XVI 187. [OFr. saut(i)er.] Sawe, n. saying; aftir þi sawe, according to thy word, XVI 397; proverb, XVI 281. [OE. sagu.] Saw(e). See Se(n). Sawte, n. assault, VII 57, 85. [Shortened from OFr. as(s)aut.] Saxon, adj. Saxon, XIII b 49; Saxonlych, adv. in the Saxon fashion, XIII b 8. [OFr. saxon.] Scaffatis, n. pl. scaffoldings, temporary wooden structures for assailing walls, X 9. [Cf. OFr. escadafaut, eschaffaut.] Scarslych, adv. scantily, scarcely, XIII b 50. [From ONFr. escars.]
Scaþe, Skathe, n. damage, injury, V 285, XV i 13. [ON. skaði.] Scere, adj. bright, pure, in Scere Þorsday, Sheer, Holy, or Maundy, Thursday, XV g 1. [OE. *scǣre, rel. to scīr; cf. ON. skǽr-r, skír-r, and ON. Skíri-Þórsdagr, OSwed. Skær(a)- Þorsdagher.] See Schyre, Skyre. Schadewe (aȝen), v. to screen (from), IX 19. [OE. sceadwian.] Schaft, n. handle, V 264. [OE. sceaft.] Schaȝe, n. shaw, small wood, V 93 (see Side). [OE. scaga.] Schakeled, pp. shackled; protected with greaves, XV h 12. [OE. sceacul, fetter.] Schal, Schall(e), Shal(l), Sal(l), v. auxil. 1 and 3 sg. pres. am (is) to, must, shall, will, I 22, II 172, 207, IV a 7, 79, IX 69, XIV a 34, XV a 10, XVI 15, XVII 164, &c.; 2 sg. Sal(l), IV a 17, 40; Schal(l), Shal(l), V 79, XVI 299, XVII 121, 381, &c.; Schalt(e), Shalt, I 206, II 130, VI 204, &c.; (with suffixed pron.) Saltou, XIV a 23; Shaltow, VIII a 223; pl. Sal(l), IV a 62, XIV b 18, &c.; Schal, Schall(e), V 332, XVI 49, 192, &c.; Schyn, V 333; Scholle, XIII b 39; Schull, Schulle(n), Shul(en), I 38, VIII a 140, IX 63, 210, XI a 9, b 82, &c. Pa. t. (ind. and subj.), was going to, ought to, was (were) to, should, would; Schold(e), Shold(e), II 467, VIII a 36, b 67, 80, IX 89, XII a 111, &c.; Schuld(e), Shuld(e), I 50, 69, 106, II 44, 190, V 16, XI a 21, &c.; Ssolde, III 7; Suld(e), IV a 91, b 19, X 12, &c.; 2 sg. Schulde, XVI 241; Schust, II 420, 570, &c. Note ellipse of a foll. verb, as 'have', XVII 227; freq. 'go', 'come', II 130, IV a 91, V 16, 332. Which slepe schal, that may (at any time) sleep, XII a 117; when it schuld be, whenever it was, II 370. [OE. sceal; sculon, scylon; scólde, &c.] Schalk, Shalke, n. man, V 200, 304, VII 72, 89. [OE. scealc, servant, (in verse) man.] Scham(e), Schome (V), Shame, n. shame, XIV c 13; disgrace, XII b 224; disgraceful thing, V 304; ignominy, disaster, harm,
XIV a 12, b 84, XV i 18, XVII 301; pl. shameful things, I 2. [OE. scamu, scomu.] Schamfully, adv. ignominiously, IV a 66. [OE. scamful-līce.] Schank(e), n. leg (below the knee), XV h 12. [OE. scanca.] Schapellis. See Chapel(le). Schap(e), Schappe, Shappe, v.; Schop, Shope, pa. t. V 260, VII 72; Schaped, pp. V 272; Schape(n), XII a 130, 169, &c.; Yschape, XIII a 45. Trans. to fashion, make, V *261, 272, VII 72, VIII b 18, IX 107; to turn (into), XII a 169, XIII a 45; to contrive, bring (it) about, V 70, XII a 130; ordain, appoint, V 260; schappe ȝou to, appoint for yourselves, XIV d 7; refl. in shappis hym, designs, intends, XVI 155; intr. to prepare, be about (to), X 14. [OE. sceppan, scōp, ge- scapen.] See Forschape. Schapp, n. shape, IX 248. [OE. ge-sceap.] Scharp(e), Sharp(e), adj. keen, sharp, harsh, bitter, severe, II 38, 539, V 199, XI b 142, XIII b 59, XIV c 21, 33, XVII 350, 356, &c.; as sb., the sharp blade, V 245, 264. [OE. scearp.] Schaterande, pres. p. intr. dashing, splashing, V 15. [OE. *scaterian; cf. MDu. scheteren.] Schaued, pa. t. shaved, II 585. [OE. scafan, str.] Schawys. See Schewe(n). Sche, pron. fem. sg. she, II 75, 77, 323, &c.; She, I 48, &c.; Scho, IV b 1, 2, 4, 6, &c.; ref. to inanimate thing (gyne), X 80. For obl. cases, &c., see Hi, fem. [See N.E.D. s.v. She.] Schede, v. to spill; intr. fall, VI 51 (cf. Pearl 10); Shedyng, n. spilling, VIII a 9. [OE. scādan, scēadan.] Scheep, Shep, n. pl. sheep, VIII b 18, IX 238. [OE. scē(a)p.] See Schep. Schelde, n. shield, V 250. [OE. scéld.] Scheltrom, n. rank of armed men, II 187. [OE. sceld-truma.] Schene, Shene (VII), Schine (II), adj. fair, goodly, VII 89, 120, 151, 157; bright, II 358, V 246; as sb., bright blade, V 200.
Welcome to our website – the perfect destination for book lovers and knowledge seekers. We believe that every book holds a new world, offering opportunities for learning, discovery, and personal growth. That’s why we are dedicated to bringing you a diverse collection of books, ranging from classic literature and specialized publications to self-development guides and children's books. More than just a book-buying platform, we strive to be a bridge connecting you with timeless cultural and intellectual values. With an elegant, user-friendly interface and a smart search system, you can quickly find the books that best suit your interests. Additionally, our special promotions and home delivery services help you save time and fully enjoy the joy of reading. Join us on a journey of knowledge exploration, passion nurturing, and personal growth every day! ebookbell.com

More Related Content

PDF
Java Complete Reference Fifth Edition
umavanth
 
PDF
Download full ebook of Java Cookbook Ian F Darwin Darwin Ian F instant downlo...
tvuxidu670
 
PDF
Core Java Volume I Fundamentals 12th Horstmann Cay
luellarensdw
 
PDF
Learning Java An Introduction to Real World Programming with Java Marc Loy
fraistomovgo
 
PDF
Core Java Vol 1 2 For The Impatient And Effective Pack 12th Ed Cay S Horstmann
makozoleva
 
PPTX
Java programmingjsjdjdjdjdjdjdjdjdiidiei
rajputtejaswa12
 
PDF
Learning Java An Introduction to Real World Programming with Java Marc Loy
hajzikairin
 
PDF
Essential Java For Scientists And Engineers 1st Brian D Hahn
yralabasah
 
Java Complete Reference Fifth Edition
umavanth
 
Download full ebook of Java Cookbook Ian F Darwin Darwin Ian F instant downlo...
tvuxidu670
 
Core Java Volume I Fundamentals 12th Horstmann Cay
luellarensdw
 
Learning Java An Introduction to Real World Programming with Java Marc Loy
fraistomovgo
 
Core Java Vol 1 2 For The Impatient And Effective Pack 12th Ed Cay S Horstmann
makozoleva
 
Java programmingjsjdjdjdjdjdjdjdjdiidiei
rajputtejaswa12
 
Learning Java An Introduction to Real World Programming with Java Marc Loy
hajzikairin
 
Essential Java For Scientists And Engineers 1st Brian D Hahn
yralabasah
 

Similar to Learning Java 4th Edition Patrick Niemeyer Daniel Leuck (20)

PPT
java-corporate-training-institute-in-mumbai
Unmesh Baile
 
PPT
java-corporate-training-institute-in-mumbai
vibrantuser
 
PPT
Java Simple Introduction in single course
binzbinz3
 
PPT
java01.pptbvuyvyuvvvvvvvvvvvvvvvvvvvvyft
nagendrareddy104104
 
PDF
Core Java An Integrated Approach 2nd R Nageswara Rao
jasonarkadiethet
 
PDF
1.Java_programming2017.pdf
MohamedTarekAbdelsal
 
PPTX
Java tutorial for beginners-tibacademy.in
TIB Academy
 
PDF
(eBook PDF) Java How to Program, Late Objects Global Edition 11th Edition
zcrowmatye
 
PPT
Java PPt.ppt
NavneetSheoran3
 
PPT
JAVA ppt tutorial basics to learn java programming
pradeepjava2016
 
PPT
Java
Manav Prasad
 
PDF
Class 1
Dario Pilozo
 
PDF
Class 1
Dario Pilozo
 
PPT
java01.ppt
Godwin585235
 
PDF
Core Java Vol Iiadvanced Features 12th Edition Cay S Horstmann
broasutschdy
 
PDF
Java
Srikanth Raju
 
PDF
[FREE PDF sample] Object Oriented Programming and Java Second Edition Danny P...
ackeylocusr5
 
PPT
INTRODUCTION TO JAVA
Pintu Dasaundhi (Rahul)
 
PDF
Objectoriented Programming And Java 2nd Ed Danny C C Poo Derek Beng Kee Kiong...
orianzotto3i
 
PDF
Java programming-language-handbook
Philip Solomon
 
java-corporate-training-institute-in-mumbai
Unmesh Baile
 
java-corporate-training-institute-in-mumbai
vibrantuser
 
Java Simple Introduction in single course
binzbinz3
 
java01.pptbvuyvyuvvvvvvvvvvvvvvvvvvvvyft
nagendrareddy104104
 
Core Java An Integrated Approach 2nd R Nageswara Rao
jasonarkadiethet
 
1.Java_programming2017.pdf
MohamedTarekAbdelsal
 
Java tutorial for beginners-tibacademy.in
TIB Academy
 
(eBook PDF) Java How to Program, Late Objects Global Edition 11th Edition
zcrowmatye
 
Java PPt.ppt
NavneetSheoran3
 
JAVA ppt tutorial basics to learn java programming
pradeepjava2016
 
Java
Manav Prasad
 
Class 1
Dario Pilozo
 
Class 1
Dario Pilozo
 
java01.ppt
Godwin585235
 
Core Java Vol Iiadvanced Features 12th Edition Cay S Horstmann
broasutschdy
 
Java
Srikanth Raju
 
[FREE PDF sample] Object Oriented Programming and Java Second Edition Danny P...
ackeylocusr5
 
INTRODUCTION TO JAVA
Pintu Dasaundhi (Rahul)
 
Objectoriented Programming And Java 2nd Ed Danny C C Poo Derek Beng Kee Kiong...
orianzotto3i
 
Java programming-language-handbook
Philip Solomon
 
Ad

Recently uploaded (20)

PPTX
PPT- ENG7_QUARTER1_LESSON1_WEEK1. IMAGERY -DESCRIPTIONS pptx.pptx
KMDee
 
PPTX
PPH.pptx obstetrics and gynecology in nursing
SrideviDevaraj5
 
PDF
Sports Quiz easy sports quiz sports quiz
nikunj2757
 
PPTX
GDM (1) (1).pptx small presentation for students
shrawanbpkihs
 
PDF
Abdominal Access Techniques with Prof. Dr. R K Mishra
mohitsuren827
 
PPTX
master seminar digital applications in india
ananyaray35
 
PDF
Classroom Observation Tools for Teachers
Nicaramirez
 
PPTX
Microbial diseases, their pathogenesis and prophylaxis
DevlinaSengupta
 
PDF
Module 4: Burden of Disease Tutorial Slides S2 2025
Jonathan Hallett
 
PPTX
1st Inaugural Professorial Lecture held on 19th February 2020 (Governance and...
kawisojames10
 
PDF
O5-L3 Freight Transport Ops (International) V1.pdf
labyankof
 
PDF
Basic Mud Logging Guide for educational purpose
wdandworks
 
PDF
RMMM.pdf make it easy to upload and study
sajedul2
 
PPTX
human mycosis Human fungal infections are called human mycosis..pptx
shilpa939953
 
PDF
Anesthesia in Laparoscopic Surgery in India
mohitsuren827
 
PPTX
Renaissance Architecture: A Journey from Faith to Humanism
DrMonicaSharma
 
PDF
Saundersa Comprehensive Review for the NCLEX-RN Examination.pdf
sreejithcareers
 
PPTX
Pharma ospi slides which help in ospi learning
rameetkumar304
 
PPTX
Institutional Correction lecture only . . .
limvtheghins
 
PDF
BÀI TẬP BỔ TRỢ 4 KỸ NĂNG TIẾNG ANH 9 GLOBAL SUCCESS - CẢ NĂM - BÁM SÁT FORM Đ...
Nguyen Thanh Tu Collection
 
PPT- ENG7_QUARTER1_LESSON1_WEEK1. IMAGERY -DESCRIPTIONS pptx.pptx
KMDee
 
PPH.pptx obstetrics and gynecology in nursing
SrideviDevaraj5
 
Sports Quiz easy sports quiz sports quiz
nikunj2757
 
GDM (1) (1).pptx small presentation for students
shrawanbpkihs
 
Abdominal Access Techniques with Prof. Dr. R K Mishra
mohitsuren827
 
master seminar digital applications in india
ananyaray35
 
Classroom Observation Tools for Teachers
Nicaramirez
 
Microbial diseases, their pathogenesis and prophylaxis
DevlinaSengupta
 
Module 4: Burden of Disease Tutorial Slides S2 2025
Jonathan Hallett
 
1st Inaugural Professorial Lecture held on 19th February 2020 (Governance and...
kawisojames10
 
O5-L3 Freight Transport Ops (International) V1.pdf
labyankof
 
Basic Mud Logging Guide for educational purpose
wdandworks
 
RMMM.pdf make it easy to upload and study
sajedul2
 
human mycosis Human fungal infections are called human mycosis..pptx
shilpa939953
 
Anesthesia in Laparoscopic Surgery in India
mohitsuren827
 
Renaissance Architecture: A Journey from Faith to Humanism
DrMonicaSharma
 
Saundersa Comprehensive Review for the NCLEX-RN Examination.pdf
sreejithcareers
 
Pharma ospi slides which help in ospi learning
rameetkumar304
 
Institutional Correction lecture only . . .
limvtheghins
 
BÀI TẬP BỔ TRỢ 4 KỸ NĂNG TIẾNG ANH 9 GLOBAL SUCCESS - CẢ NĂM - BÁM SÁT FORM Đ...
Nguyen Thanh Tu Collection
 
Ad

Learning Java 4th Edition Patrick Niemeyer Daniel Leuck

  • 1. Learning Java 4th Edition Patrick Niemeyer Daniel Leuck download https://ebookbell.com/product/learning-java-4th-edition-patrick- niemeyer-daniel-leuck-4318126 Explore and download more ebooks at ebookbell.com
  • 2. Here are some recommended products that we believe you will be interested in. You can click the link to download. Learning Java An Introduction To Realworld Programming With Java 6th Edition Marc Loy https://ebookbell.com/product/learning-java-an-introduction-to- realworld-programming-with-java-6th-edition-marc-loy-52200556 Learning Java With Games 1st Ed 2018 Chongwei Xu https://ebookbell.com/product/learning-java-with-games-1st- ed-2018-chongwei-xu-23480728 Learning Java By Building Android Games Learn Java And Android From Scratch By Building Five Exciting Games 3rd John Horton https://ebookbell.com/product/learning-java-by-building-android-games- learn-java-and-android-from-scratch-by-building-five-exciting- games-3rd-john-horton-23721610 Learning Java 3rd Edition Covers J2se 50 3rd Edition Patrick Niemeyer https://ebookbell.com/product/learning-java-3rd-edition- covers-j2se-50-3rd-edition-patrick-niemeyer-2406906
  • 3. Learning Java Programming In Claras World 1st Anton Bogdanovych https://ebookbell.com/product/learning-java-programming-in-claras- world-1st-anton-bogdanovych-33453718 Learning Java 5th Edition Marc Loy Patrick Niemeyer And Daniel Leuck https://ebookbell.com/product/learning-java-5th-edition-marc-loy- patrick-niemeyer-and-daniel-leuck-37239172 Learning Java Through Applications A Graphical Approach Duane J Jarc https://ebookbell.com/product/learning-java-through-applications-a- graphical-approach-duane-j-jarc-4720722 Learning Java By Building Android Games John Horton https://ebookbell.com/product/learning-java-by-building-android-games- john-horton-5058278 Learning Java Through Games Stanchev Lubomir https://ebookbell.com/product/learning-java-through-games-stanchev- lubomir-5085918
  • 7. Patrick Niemeyer and Daniel Leuck FOURTH EDITION Learning Java
  • 8. Learning Java, Fourth Edition by Patrick Niemeyer and Daniel Leuck Copyright © 2013 Patrick Niemeyer, Daniel Leuck. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are alsoavailableformosttitles(http://my.safaribooksonline.com).Formoreinformation,contactourcorporate/ institutional sales department: 800-998-9938 or corporate@oreilly.com. Editors: Mike Loukides and Meghan Blanchette Production Editor: Rachel Steely Copyeditor: Gillian McGarvey Proofreader: Rachel Monaghan Indexer: BIM Publishing Services, Inc. Cover Designer: Randy Comer Interior Designer: David Futato Illustrators: Robert Romano and Rebecca Demarest June 2013: Fourth Edition Revision History for the Fourth Edition: 2013-06-06: First release See http://oreilly.com/catalog/errata.csp?isbn=9781449319243 for release details. Nutshell Handbook, the Nutshell Handbook logo, and the O’Reilly logo are registered trademarks of O’Reilly Media, Inc. Learning Java, Fourth Edition, the image of a Bengal tigress and her cubs, and related trade dress are trademarks of O’Reilly Media, Inc. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and O’Reilly Media, Inc., was aware of a trade‐ mark claim, the designations have been printed in caps or initial caps. While every precaution has been taken in the preparation of this book, the publisher and authors assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein. ISBN: 978-1-449-31924-3 [LSI]
  • 9. Table of Contents Preface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi 1. A Modern Language. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Enter Java 2 Java’s Origins 2 Growing Up 3 A Virtual Machine 4 Java Compared with Other Languages 7 Safety of Design 10 Simplify, Simplify, Simplify... 10 Type Safety and Method Binding 11 Incremental Development 12 Dynamic Memory Management 13 Error Handling 14 Threads 14 Scalability 15 Safety of Implementation 15 The Verifier 17 Class Loaders 18 Security Managers 19 Application and User-Level Security 19 A Java Road Map 20 The Past: Java 1.0–Java 1.6 20 The Present: Java 7 21 The Future 23 Availability 23 2. A First Application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Java Tools and Environment 25 iii
  • 10. Configuring Eclipse and Creating a Project 26 Importing the Learning Java Examples 28 HelloJava 29 Classes 32 The main() Method 33 Classes and Objects 34 Variables and Class Types 34 HelloComponent 35 Inheritance 36 The JComponent Class 37 Relationships and Finger Pointing 38 Package and Imports 39 The paintComponent() Method 40 HelloJava2: The Sequel 41 Instance Variables 43 Constructors 44 Events 45 The repaint() Method 47 Interfaces 48 HelloJava3: The Button Strikes! 49 Method Overloading 51 Components 52 Containers 52 Layout 53 Subclassing and Subtypes 54 More Events and Interfaces 54 Color Commentary 55 Static Members 55 Arrays 56 Our Color Methods 56 HelloJava4: Netscape’s Revenge 58 Threads 60 The Thread Class 61 The Runnable Interface 61 Starting the Thread 62 Running Code in the Thread 62 Exceptions 63 Synchronization 64 3. Tools of the Trade. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 JDK Environment 67 The Java VM 68 iv | Table of Contents
  • 11. Running Java Applications 68 System Properties 70 The Classpath 70 javap 72 The Java Compiler 72 JAR Files 74 File Compression 74 The jar Utility 75 The pack200 Utility 78 Policy Files 78 The Default Security Manager 79 The policytool Utility 79 Using a Policy File with the Default Security Manager 81 4. The Java Language. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Text Encoding 83 Comments 84 Javadoc Comments 85 Types 86 Primitive Types 87 Reference Types 91 A Word About Strings 93 Statements and Expressions 93 Statements 94 Expressions 100 Exceptions 104 Exceptions and Error Classes 105 Exception Handling 107 Bubbling Up 109 Stack Traces 110 Checked and Unchecked Exceptions 111 Throwing Exceptions 112 try Creep 115 The finally Clause 116 Try with Resources 117 Performance Issues 119 Assertions 119 Enabling and Disabling Assertions 120 Using Assertions 121 Arrays 122 Array Types 123 Array Creation and Initialization 123 Table of Contents | v
  • 12. Using Arrays 125 Anonymous Arrays 127 Multidimensional Arrays 127 Inside Arrays 129 5. Objects in Java. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 Classes 132 Accessing Fields and Methods 133 Static Members 135 Methods 138 Local Variables 139 Shadowing 139 Static Methods 140 Initializing Local Variables 141 Argument Passing and References 142 Wrappers for Primitive Types 144 Autoboxing and Unboxing of Primitives 146 Variable-Length Argument Lists 147 Method Overloading 148 Object Creation 149 Constructors 150 Working with Overloaded Constructors 151 Static and Nonstatic Initializer Blocks 153 Object Destruction 154 Garbage Collection 154 Finalization 155 Weak and Soft References 155 Enumerations 156 Enum Values 158 Customizing Enumerations 158 6. Relationships Among Classes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Subclassing and Inheritance 161 Shadowed Variables 163 Overriding Methods 165 Special References: this and super 172 Casting 172 Using Superclass Constructors 174 Full Disclosure: Constructors and Initialization 175 Abstract Methods and Classes 176 Interfaces 177 Interfaces as Callbacks 179 vi | Table of Contents
  • 13. Interface Variables 180 Subinterfaces 181 Packages and Compilation Units 182 Compilation Units 182 Package Names 183 Class Visibility 183 Importing Classes 184 Visibility of Variables and Methods 186 Basic Access Modifiers 186 Subclasses and Visibility 188 Interfaces and Visibility 189 Arrays and the Class Hierarchy 189 ArrayStoreException 190 Inner Classes 190 Inner Classes as Adapters 192 Inner Classes Within Methods 194 7. Working with Objects and Classes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 The Object Class 201 Equality and Equivalence 202 Hashcodes 203 Cloning Objects 203 The Class Class 206 Reflection 208 Modifiers and Security 211 Accessing Fields 212 Accessing Methods 213 Accessing Constructors 215 What About Arrays? 216 Accessing Generic Type Information 216 Accessing Annotation Data 217 Dynamic Interface Adapters 217 What Is Reflection Good For? 218 Annotations 219 Using Annotations 220 Standard Annotations 221 The apt Tool 222 8. Generics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 Containers: Building a Better Mousetrap 224 Can Containers Be Fixed? 224 Enter Generics 225 Table of Contents | vii
  • 14. Talking About Types 228 “There Is No Spoon” 229 Erasure 230 Raw Types 231 Parameterized Type Relationships 232 Why Isn’t a List<Date> a List<Object>? 234 Casts 235 Writing Generic Classes 236 The Type Variable 236 Subclassing Generics 237 Exceptions and Generics 238 Parameter Type Limitations 239 Bounds 240 Erasure and Bounds (Working with Legacy Code) 241 Wildcards 242 A Supertype of All Instantiations 243 Bounded Wildcards 243 Thinking Outside the Container 243 Lower Bounds 244 Reading, Writing, and Arithmetic 245 <?>, <Object>, and the Raw Type 247 Wildcard Type Relationships 247 Generic Methods 248 Generic Methods Introduced 249 Type Inference from Arguments 250 Type Inference from Assignment Context 251 Explicit Type Invocation 252 Wildcard Capture 252 Wildcard Types Versus Generic Methods 253 Arrays of Parameterized Types 253 Using Array Types 254 What Good Are Arrays of Generic Types? 255 Wildcards in Array Types 255 Case Study: The Enum Class 256 Case Study: The sort() Method 257 Conclusion 258 9. Threads. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 Introducing Threads 260 The Thread Class and the Runnable Interface 261 Controlling Threads 265 Death of a Thread 267 viii | Table of Contents
  • 15. Threading an Applet 268 Issues Lurking 270 Synchronization 271 Serializing Access to Methods 272 Accessing class and instance Variables from Multiple Threads 274 The wait() and notify() Methods 275 Passing Messages 277 ThreadLocal Objects 281 Scheduling and Priority 282 Thread State 283 Time-Slicing 284 Priorities 285 Yielding 285 Thread Groups 286 Working with ThreadGroups 287 Uncaught Exceptions 287 Thread Performance 288 The Cost of Synchronization 288 Thread Resource Consumption 289 Concurrency Utilities 289 Executors 291 Locks 303 Synchronization Constructs 306 Atomic Operations 311 Conclusion 313 10. Working with Text. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315 Text-Related APIs 316 Strings 316 Constructing Strings 317 Strings from Things 318 Comparing Strings 319 Searching 321 Editing 322 String Method Summary 322 StringBuilder and StringBuffer 323 Internationalization 325 The java.util.Locale Class 325 Resource Bundles 326 Parsing and Formatting Text 328 Parsing Primitive Numbers 328 Tokenizing Text 330 Table of Contents | ix
  • 16. Printf-Style Formatting 332 Formatter 333 The Format String 333 String Conversions 334 Primitive and Numeric Conversions 336 Flags 337 Miscellaneous 338 Formatting with the java.text Package 338 MessageFormat 340 Regular Expressions 342 Regex Notation 342 The java.util.regex API 352 11. Core Utilities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359 Math Utilities 359 The java.lang.Math Class 360 Big/Precise Numbers 361 Floating-Point Components 362 Random Numbers 363 Dates and Times 364 Working with Calendars 365 Time Zones 366 Parsing and Formatting with DateFormat 368 Printf-Style Date and Time Formatting 370 Timers 371 Collections 373 The Collection Interface 374 Iterator 376 Collection Types 378 The Map Interface 380 Collection Implementations 382 Hash Codes and Key Values 387 Synchronized and Unsynchronized Collections 388 Read-Only and Read-Mostly Collections 390 WeakHashMap 390 EnumSet and EnumMap 390 Sorting Collections 391 A Thrilling Example 392 Properties 393 Loading and Storing 394 System Properties 395 The Preferences API 396 x | Table of Contents
  • 17. Preferences for Classes 397 Preferences Storage 398 Change Notification 398 The Logging API 399 Overview 399 Logging Levels 401 A Simple Example 402 Logging Setup Properties 403 The Logger 405 Performance 406 Observers and Observables 406 12. Input/Output Facilities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409 Streams 409 Basic I/O 412 Character Streams 415 Stream Wrappers 416 Pipes 420 Streams from Strings and Back 422 Implementing a Filter Stream 423 File I/O 425 The java.io.File Class 425 File Streams 430 RandomAccessFile 433 Resource Paths 434 The NIO File API 436 FileSystem and Path 436 NIO File Operations 438 Directory Operations 441 Watching Paths 443 Serialization 444 Initialization with readObject() 446 SerialVersionUID 447 Data Compression 448 Archives and Compressed Data 448 Decompressing Data 450 Zip Archive As a Filesystem 452 The NIO Package 453 Asynchronous I/O 453 Performance 454 Mapped and Locked Files 454 Channels 454 Table of Contents | xi
  • 18. Buffers 455 Character Encoders and Decoders 459 FileChannel 461 Scalable I/O with NIO 467 13. Network Programming. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469 Sockets 471 Clients and Servers 472 The DateAtHost Client 477 The TinyHttpd Server 478 Socket Options 482 Proxies and Firewalls 484 Datagram Sockets 486 The HeartBeat Applet 487 InetAddress 491 Simple Serialized Object Protocols 491 A Simple Object-Based Server 492 Remote Method Invocation 496 Real-World Usage 497 Remote and Nonremote Objects 497 An RMI Example 500 RMI and CORBA 508 Scalable I/O with NIO 509 Selectable Channels 509 Using Select 510 LargerHttpd 512 Nonblocking Client-Side Operations 517 14. Programming for the Web. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519 Uniform Resource Locators (URLs) 519 The URL Class 520 Stream Data 521 Getting the Content as an Object 522 Managing Connections 523 Handlers in Practice 524 Useful Handler Frameworks 524 Talking to Web Applications 525 Using the GET Method 526 Using the POST Method 527 The HttpURLConnection 530 SSL and Secure Web Communications 530 URLs, URNs, and URIs 530 xii | Table of Contents
  • 19. Web Services 531 XML-RPC 532 WSDL 532 The Tools 532 The Weather Service Client 533 15. Web Applications and Web Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535 Web Application Technologies 536 Page-Oriented Versus “Single Page” Applications 536 JSPs 537 XML and XSL 538 Web Application Frameworks 538 Google Web Toolkit 539 HTML5, AJAX, and More... 539 Java Web Applications 539 The Servlet Lifecycle 540 Servlets 541 The HelloClient Servlet 542 The Servlet Response 544 Servlet Parameters 545 The ShowParameters Servlet 546 User Session Management 548 The ShowSession Servlet 548 The ShoppingCart Servlet 550 Cookies 553 The ServletContext API 554 Asynchronous Servlets 555 WAR Files and Deployment 559 Configuration with web.xml and Annotations 560 URL Pattern Mappings 562 Deploying HelloClient 563 Error and Index Pages 564 Security and Authentication 566 Protecting Resources with Roles 566 Secure Data Transport 568 Authenticating Users 569 Procedural Authorization 570 Servlet Filters 571 A Simple Filter 572 A Test Servlet 573 Declaring and Mapping Filters 574 Filtering the Servlet Request 575 Table of Contents | xiii
  • 20. Filtering the Servlet Response 577 Building WAR Files with Ant 580 A Development-Oriented Directory Layout 581 Deploying and Redeploying WARs with Ant 582 Implementing Web Services 582 Defining the Service 583 Our Echo Service 584 Using the Service 585 Data Types 587 Conclusion 588 16. Swing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589 Components 592 Peers and Look-and-Feel 594 The MVC Framework 595 Painting 596 Enabling and Disabling Components 597 Focus, Please 598 Other Component Methods 598 Layout Managers 600 Insets 601 Z-Ordering (Stacking Components) 601 The revalidate() and doLayout() Methods 601 Managing Components 602 Listening for Components 602 Windows, Frames and Splash Screens 602 Other Methods for Controlling Frames 604 Content Panes 605 Desktop Integration 605 Events 607 Event Receivers and Listener Interfaces 608 Event Sources 610 Event Delivery 611 Event Types 612 The java.awt.event.InputEvent Class 613 Mouse and Key Modifiers on InputEvents 613 Focus Events 614 Event Summary 616 Adapter Classes 619 Dummy Adapters 622 The AWT Robot! 623 xiv | Table of Contents
  • 21. Multithreading in Swing 623 17. Using Swing Components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627 Buttons and Labels 627 HTML Text in Buttons and Labels 630 Checkboxes and Radio Buttons 631 Lists and Combo Boxes 634 The Spinner 637 Borders 639 Menus 642 Pop-Up Menus 646 Component-Managed Pop Ups 648 The JScrollPane Class 650 The JSplitPane Class 652 The JTabbedPane Class 653 Scrollbars and Sliders 657 Dialogs 659 File Selection Dialog 662 The Color Chooser 664 18. More Swing Components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667 Text Components 667 The TextEntryBox Application 668 Formatted Text 670 Filtering Input 671 Validating Data 673 Say the Magic Word 674 Sharing a Data Model 675 HTML and RTF for Free 677 Managing Text Yourself 680 Focus Navigation 682 Trees 684 Nodes and Models 684 Save a Tree 685 Tree Events 685 A Complete Example 686 Tables 688 A First Stab: Freeloading 688 Round Two: Creating a Table Model 690 Round Three: A Simple Spreadsheet 693 Sorting and Filtering 697 Printing JTables 699 Table of Contents | xv
  • 22. Desktops 699 Pluggable Look-and-Feel 701 Creating Custom Components 704 Generating Events 704 A Dial Component 704 Model and View Separation 708 19. Layout Managers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 709 FlowLayout 711 GridLayout 712 BorderLayout 713 BoxLayout 716 CardLayout 717 GridBagLayout 719 The GridBagConstraints Class 719 Grid Coordinates 721 The fill Constraint 722 Spanning Rows and Columns 724 Weighting 725 Anchoring 728 Padding and Insets 728 Relative Positioning 730 Composite Layouts 731 Other Layout Managers 734 Absolute Positioning 735 20. Drawing with the 2D API. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737 The Big Picture 737 The Rendering Pipeline 739 A Quick Tour of Java 2D 742 Filling Shapes 742 Drawing Shape Outlines 742 Convenience Methods 743 Drawing Text 744 Drawing Images 744 The Whole Iguana 745 Filling Shapes 748 Solid Colors 748 Color Gradients 749 Textures 749 Desktop Colors 749 Stroking Shape Outlines 750 xvi | Table of Contents
  • 23. Using Fonts 751 Font Metrics 752 Displaying Images 756 The Image Class 756 Image Observers 758 Scaling and Size 759 Drawing Techniques 760 Double Buffering 763 Limiting Drawing with Clipping 764 Offscreen Drawing 766 Printing 769 21. Working with Images and Other Media. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 771 Loading Images 772 ImageObserver 773 MediaTracker 775 ImageIcon 777 ImageIO 777 Producing Image Data 778 Drawing Animations 779 BufferedImage Anatomy 782 Color Models 783 Creating an Image 784 Updating a BufferedImage 786 Filtering Image Data 790 How ImageProcessor Works 792 Converting an Image to a BufferedImage 793 Using the RescaleOp Class 793 Using the AffineTransformOp Class 793 Saving Image Data 794 Simple Audio 795 Java Media Framework 796 22. JavaBeans. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 799 What’s a Bean? 799 What Constitutes a Bean? 801 The NetBeans IDE 801 Installing and Running NetBeans 802 Properties and Customizers 805 Event Hookups and Adapters 807 Taming the Juggler 808 Molecular Motion 810 Table of Contents | xvii
  • 24. Binding Properties 811 Constraining Properties 812 Building Beans 813 The Dial Bean 813 Design Patterns for Properties 816 Limitations of Visual Design 817 Serialization Versus Code Generation 818 Customizing with BeanInfo 819 Getting Properties Information 819 Handcoding with Beans 822 Bean Instantiation and Type Management 823 Working with Serialized Beans 823 Runtime Event Hookups with Reflection 825 BeanContext and BeanContextServices 827 The Java Activation Framework 828 Enterprise JavaBeans and POJO-Based Enterprise Frameworks 828 23. Applets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 831 The Politics of Browser-Based Applications 831 Applet Support and the Java Plug-in 833 The JApplet Class 833 Applet Lifecycle 834 The Applet Security Sandbox 837 Getting Applet Resources 838 The <applet> Tag 842 Attributes 843 Parameters 843 ¿Habla Applet? 844 The Complete <applet> Tag 844 Loading Class Files 846 Packages 846 appletviewer 847 Java Web Start 847 Conclusion 848 24. XML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 849 The Butler Did It 849 A Bit of Background 850 Text Versus Binary 851 A Universal Parser 851 The State of XML 851 The XML APIs 852 xviii | Table of Contents
  • 25. XML and Web Browsers 852 XML Basics 852 Attributes 853 XML Documents 854 Encoding 854 Namespaces 855 Validation 856 HTML to XHTML 856 SAX 856 The SAX API 857 Building a Model Using SAX 858 XMLEncoder/Decoder 864 DOM 865 The DOM API 865 Test-Driving DOM 866 Generating XML with DOM 868 JDOM 869 XPath 869 Nodes 870 Predicates 871 Functions 871 The XPath API 872 XMLGrep 873 XInclude 874 Enabling XInclude 875 Validating Documents 876 Using Document Validation 876 DTDs 877 XML Schema 879 The Validation API 883 JAXB Code Binding and Generation 885 Annotating Our Model 885 Generating a Java Model from an XML Schema 890 Generating an XML Schema from a Java Model 891 Transforming Documents with XSL/XSLT 891 XSL Basics 892 Transforming the Zoo Inventory 894 XSLTransform 896 XSL in the Browser 897 Web Services 897 Table of Contents | xix
  • 26. The End of the Book 898 A. The Eclipse IDE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 899 B. BeanShell: Java Scripting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 911 Glossary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 917 Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 931 xx | Table of Contents
  • 27. Preface This book is about the Java programming language and environment. Whether you are a software developer or just someone who uses the Internet in your daily life, you’ve undoubtedly heard about Java. Its introduction was one of the most exciting develop‐ ments in the history of the Web and Java applications have powered much of the growth of business on the Internet in the past 15 years. Java is, arguably, the most popular programming language in the world, used by millions of developers on almost every kind of computer imaginable. In the past decade, Java has surpassed languages such as C++ and Visual Basic in terms of developer demand and has become the de facto lan‐ guage for certain kinds of development—especially for web-based services. Most uni‐ versities are now using Java in their introductory courses alongside the other important modern languages. Perhaps you are using this text in one of your classes right now! This book gives you a thorough grounding in Java fundamentals and APIs. Learning Java, Fourth Edition, attempts to live up to its name by mapping out the Java language and its class libraries, programming techniques, and idioms. We’ll dig deep into inter‐ esting areas and at least scratch the surface of the rest. Other titles from O’Reilly pick up where we leave off and provide more comprehensive information on specific areas and applications of Java. Whenever possible, we provide compelling, realistic, and fun examples and avoid mere‐ ly cataloging features. The examples are simple, but hint at what can be done. We won’t bedevelopingthenextgreat“killerapp”inthesepages,butwehopetogiveyouastarting point for many hours of experimentation and inspired tinkering that will lead you to develop one yourself. Who Should Read This Book This book is for computer professionals, students, technical people, and Finnish hack‐ ers. It’s for everyone who has a need for hands-on experience with the Java language with an eye toward building real applications. This book could also be considered a xxi
  • 28. crash course in object-oriented programming, networking, GUIs, and XML. As you learn about Java, you’ll also learn a powerful and practical approach to software devel‐ opment, beginning with a deep understanding of the fundamentals of Java and its APIs. Superficially, Java looks like C or C++, so you’ll have a tiny head start in using this book if you have some experience with one of these languages. If you do not, don’t worry. Don’t make too much of the syntactic similarities between Java and C or C++. In many respects, Java acts like more dynamic languages such as Smalltalk and Lisp. Knowledge of another object-oriented programming language should certainly help, although you may have to change some ideas and unlearn a few habits. Java is considerably simpler than languages such as C++ and Smalltalk. If you learn well from concise examples and personal experimentation, we think you’ll like this book. The last part of this book branches out to discuss Java in the context of web applications, web services, and XML processing, so you should be familiar with the basic ideas behind web browsers, servers, and documents. New Developments This edition of Learning Java is actually the sixth edition—updated and retitled—of our original, popular Exploring Java. With each edition, we’ve taken great care not only to add new material covering additional features, but to thoroughly revise and update the existing content to synthesize the coverage and add years of real-world perspective and experience to these pages. One noticeable change in recent editions is that we’ve deemphasized the use of applets, reflecting their diminished role in recent years in creating interactive web pages. In contrast, we’ve greatly expanded our coverage of Java web applications, web services, and XML, which are now mature technologies. We cover all of the important features of the latest release of Java, officially called Java Standard Edition (SE) 7, JDK 1.7. Sun (Java’s keeper before Oracle) has changed the naming scheme many times over the years. Sun coined the term Java 2 to cover the major new features introduced in Java version 1.2 and dropped the term JDK in favor of SDK. With the sixth release, Sun skipped from Java version 1.4 to Java 5.0, but re‐ prieved the term JDK and kept its numbering convention there. After that, we had Java 6 and now we reach Java 7. This release of Java reflects a mature language with relatively few syntactic changes but significant updates to APIs and libraries. We’ve tried to capture these new features and update every example in this book to reflect not only the current Java practice, but style as well. xxii | Preface
  • 29. New in This Edition (Java 6 and 7) This edition of the book has been significantly reworked to be as complete and up-to- date as possible. It incorporates changes from both the Java 6 and Java 7 releases that occurred since the last edition of this book. New topics in this edition include: • New language features, including type inference in generics and improved excep‐ tion handling and automatic resource management syntax • New concurrency utilities including the Fork-Join framework • The new NIO Files API, which allows new types of filesystem access to be imple‐ mented in Java • New versions of the Java Servlets (3.0) and web services APIs, including use of the new annotations-based deployment and built-in web service container • New version of JAXB (2.2) Java XML Binding, including use of the new annotations for binding Java to XML • Improved Swing desktop integration and enhancements to key Swing components such as JTable • Updated examples and analysis throughout the book Using This Book This book is organized roughly as follows: • Chapters 1 and 2 provide a basic introduction to Java concepts and a tutorial to give you a jump start on Java programming. • Chapter 3 discusses fundamental tools for developing with Java (the compiler, the interpreter, and the JAR file package). • Chapters 4 through 7 describe the Java language itself, beginning with the basic syntax and then covering classes and objects, exceptions, arrays, enumerations, annotations, and much more. • Chapter 8 covers generics and parameterized types in Java. • Chapter 9 covers the language’s built-in thread facilities and the Java Concurrency package, which should be of particular interest to advanced programmers. • Chapter 10 covers text processing, formatting, scanning, string utilities, and the powerful regular expressions API. • Chapter 11 covers much of the core API including utilities and collections. • Chapter 12 covers Java I/O, streams, files, and the NIO package. Preface | xxiii
  • 30. • Chapters 13 and 14 cover Java networking, including sockets and NIO, URLs, and RMI. • Chapter 15 covers web applications using servlets, servlet filters, and WAR files, as well as web services. • Chapters 16 through 21 cover GUI development with the Abstract Window Toolkit (AWT) and Swing, which provide graphical user interface (GUI) and image support. • Chapter 22 covers the JavaBeans component architecture and introduces the Net‐ Beans IDE. • Chapter 23 covers applets. • Chapter 24 covers the Java APIs for working with XML and XSLT, including XML Schema, validation, XPath, and XInclude, as well as XML binding with JAXB. • Appendix A covers using the Eclipse IDE with the examples in this book. • AppendixBdescribesBeanShell,alightweightscriptinglanguageforJavadeveloped by the authors of this book. If you’re like us, you don’t read books from front to back. If you’re really like us, you usually don’t read the Preface at all. However, on the off chance that you will see this in time, here are a few suggestions: • IfyouareanexperiencedprogrammerwhohastolearnJavainthenextfiveminutes, you are probably looking for the examples. You might want to start by glancing at the tutorial in Chapter 2. If that doesn’t float your boat, you should at least look at the information in Chapter 3, which explains how to use the compiler and inter‐ preter, or Appendix A, which shows how to run the examples in the Eclipse IDE. This should get you started. • Chapters 12 through 15 are essential if you are interested in writing advanced net‐ worked or web-based applications and services. This is one of the more interesting and important parts of Java. • Chapters 16 through 22 discuss Java’s graphics features and component architec‐ ture. You should read this if you are interested in writing graphical Java applications or applets. • Chapter 24 covers the Java APIs for working with XML, including SAX, DOM, DTDs,XMLSchema,andusingXSLtorenderoutputfortheWeb.XMLtechnology is becoming key to cross-platform development. xxiv | Preface
  • 31. Online Resources There are many online sources for information about Java. Oracle’s official website for Java topics is http://java.sun.com; look here for the software, updates, and Java releases. This is where you’ll find the JDK, which includes the compiler, the interpreter, and other tools. You should also visit O’Reilly’s Java site at http://oreilly.com/java. There you’ll find in‐ formation about other O’Reilly Java books, and a pointer to the home page for Learning Java, http://oreil.ly/Java_4E, where you’ll find the source code examples for this book. Conventions Used in This Book The font conventions used in this book are quite simple. Italic is used for: • Unix pathnames, filenames, and program names • Internet addresses, such as domain names and URLs • New terms where they are defined • Program names, compilers, interpreters, utilities, and commands • Threads Constant width is used for: • Anything that might appear in a Java program, including method names, variable names, and class names • Tags that might appear in an HTML or XML document • Keywords, objects, and environment variables Constant width bold is used for: • Text that is typed by the user on the command line Constant width italic is used for: • Replaceable items in code This icon designates a note, which is an important aside to the near‐ by text. Preface | xxv
  • 32. This icon designates a warning relating to the nearby text. In the main body of text, we always use a pair of empty parentheses after a method name to distinguish methods from variables and other creatures. In the Java source listings, we follow the coding conventions most frequently used in the Java community. Class names begin with capital letters; variable and method names begin with lowercase. All the letters in the names of constants are capitalized. We don’t use underscores to separate words in a long name; following common practice, we capitalize individual words (after the first) and run the words together. For example: thisIsAVariable, thisIsAMethod(), ThisIsAClass, and THISISACONSTANT. Also, note thatwedifferentiatebetweenstaticandnonstaticmethodswhenwerefertothem.Unlike some books, we never write Foo.bar() to mean the bar() method of Foo unless bar() is a static method (paralleling the Java syntax in that case). Using Code Examples This book is here to help you get your job done. In general, if this book includes code examples, you may use the code in your programs and documentation. You do not need to contact us for permission unless you’re reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from this book does not require permission. Selling or distributing a CD-ROM of examples from O’Reilly books does require permission. Answering a question by citing this book and quoting example code does not require permission. Incorporating a significant amount of ex‐ ample code from this book into your product’s documentation does require permission. We appreciate, but do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: “Learning Java, Fourth Edition, by Patrick Niemeyer and Daniel Leuck. Copyright 2013 Patrick Niemeyer and Daniel Leuck, 978-1-449-31924-3.” If you feel your use of code examples falls outside fair use or the permission given above, feel free to contact us at permissions@oreilly.com. Safari® Books Online Safari Books Online (www.safaribooksonline.com) is an on- demand digital library that delivers expert content in both book and video form from the world’s leading authors in technology and busi‐ ness. xxvi | Preface
  • 33. Technology professionals, software developers, web designers, and business and crea‐ tive professionals use Safari Books Online as their primary resource for research, prob‐ lem solving, learning, and certification training. Safari Books Online offers a range of product mixes and pricing programs for organi‐ zations, government agencies, and individuals. Subscribers have access to thousands of books, training videos, and prepublication manuscripts in one fully searchable database from publishers like O’Reilly Media, Prentice Hall Professional, Addison-Wesley Pro‐ fessional, Microsoft Press, Sams, Que, Peachpit Press, Focal Press, Cisco Press, John Wiley & Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe Press, FT Press, Apress, Manning, New Riders, McGraw-Hill, Jones & Bartlett, Course Technol‐ ogy, and dozens more. For more information about Safari Books Online, please visit us online. How to Contact Us Please address comments and questions concerning this book to the publisher: O’Reilly Media, Inc. 1005 Gravenstein Highway North Sebastopol, CA 95472 800-998-9938 (in the United States or Canada) 707-829-0515 (international or local) 707-829-0104 (fax) We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at http://oreil.ly/Java_4E. To comment or ask technical questions about this book, send email to bookques tions@oreilly.com. For more information about our books, courses, conferences, and news, see our website at http://www.oreilly.com. Find us on Facebook: http://facebook.com/oreilly Follow us on Twitter: http://twitter.com/oreillymedia Watch us on YouTube: http://www.youtube.com/oreillymedia Acknowledgments Many people have contributed to putting this book together, both in its Exploring Java incarnation and in its current form as Learning Java. Foremost, we would like to thank Tim O’Reilly for giving us the opportunity to write this book. Thanks to Mike Loukides, the series editor, whose patience and experience helped us get started on this Preface | xxvii
  • 34. journey. Thanks to Paula Ferguson and John Posner, who contributed their organiza‐ tional and editing abilities at various times. And a special thanks to Deb Cameron, the tireless editor of this book, without whom the previous two editions might never have been finished and certainly wouldn’t have resembled English. We could not have asked for a more skillful or responsive team of people with whom to work. Speakingofborrowings,theoriginalversionoftheglossarycamefromDavidFlanagan’s book Java in a Nutshell (O’Reilly). We also borrowed several class hierarchy diagrams from David’s book. These diagrams were based on similar diagrams by Charles L. Perkins. Thanks also to Marc Wallace and Steven Burkett for reading the original work in pro‐ gress and for the support of our friends at Washington University: Bryan O’Connor and Brian Gottlieb. Thanks also to Josh Peck, coauthor of the original book, Exploring Java. Thanks to all those who reviewed or answered questions: David Flanagan for generics; Henry Wong for the concurrency utilities; Jim Elliott, Marc Loy, and Brian ColeforSwing;JackShiraziforNIO;TimBoudreauforNetBeans;MartinAeschlimann, Jim Farley, and John Norman for Eclipse; Ed Howland for XML; and Ian Darwin for regular expressions. (Check out Ian’s Java Cookbook [O’Reilly] for more examples.) Thanks also to Ray O’Leary, Mario Aquino, and Mark Volkmann for their reviews. And finally, thanks to my beautiful wife, Ellen Song, for putting up with me through all this work. xxviii | Preface
  • 35. CHAPTER 1 A Modern Language The greatest challenges and most exciting opportunities for software developers today lie in harnessing the power of networks. Applications created today, whatever their intended scope or audience, will almost certainly run on machines linked by a global network of computing resources. The increasing importance of networks is placing new demands on existing tools and fueling the demand for a rapidly growing list of com‐ pletely new kinds of applications. We want software that works—consistently, anywhere, on any platform—and that plays well with other applications. We want dynamic applications that take advantage of a connected world, capable of accessing disparate and distributed information sources. We want truly distributed software that can be extended and upgraded seamlessly. We want intelligent applications that can roam the Net for us, ferreting out information and serving as electronic emissaries. We have known for some time what kind of software we want, but it is really only in the past few years that we have begun to get it. The problem, historically, has been that the tools for building these applications have fallen short. The requirements of speed and portability have been, for the most part, mutually exclusive, and security has been largely ignored or misunderstood. In the past, truly portable languages were bulky, interpreted, and slow. These languages were pop‐ ular as much for their high-level functionality as for their portability. Fast languages usually provided speed by binding themselves to particular platforms, so they met the portability issue only halfway. There were even a few safe languages, but they were primarily offshoots of the portable languages and suffered from the same problems. Java is a modern language that addresses all three of these fronts: portability, speed, and security. This is why it has been a dominant language in the world of programming for more than a decade and a half. 1
  • 36. Enter Java The Java programming language, developed at Sun Microsystems under the guidance ofNetluminariesJamesGoslingandBillJoy,wasdesignedtobeamachine-independent programming language that is both safe enough to traverse networks and powerful enough to replace native executable code. Java addresses the issues raised here and played a starring role in the growth of the Internet, leading to where we are today. Initially, most of the enthusiasm for Java centered on its capabilities for building em‐ bedded applications for the Web called applets. But in the early days, applets and other client-side GUI applications written in Java were limited. Today, Java has Swing, one of the most sophisticated toolkits for building graphical user interfaces (GUIs) in any lan‐ guage. This development has allowed Java to become a popular platform for developing traditional client-side application software. Of even more importance, however, Java has become the premier platform for web- based applications and web services. These applications use technologies including the Java Servlet API, Java web services, and many popular open source and commercial Java application servers and frameworks. Java’s portability and speed make it the platform of choice for modern business applications. Java servers running on open source Linux platforms are at the heart of the business and financial world today. This book will show you how to use Java to accomplish real-world programming tasks. In the coming chapters we’ll cover everything from text processing to networking, building rich client-side GUI applications with Swing and lightweight web-based ap‐ plications and services. Java’s Origins The seeds of Java were planted in 1990 by Sun Microsystems patriarch and chief re‐ searcherBillJoy.Atthetime,Sunwascompetinginarelativelysmallworkstationmarket while Microsoft was beginning its domination of the more mainstream, Intel-based PC world. When Sun missed the boat on the PC revolution, Joy retreated to Aspen, Colo‐ rado, to work on advanced research. He was committed to the idea of accomplishing complex tasks with simple software and founded the aptly named Sun Aspen Smallworks. Of the original members of the small team of programmers assembled in Aspen, James Gosling will be remembered as the father of Java. Gosling first made a name for himself in the early 80s as the author of Gosling Emacs, the first version of the popular Emacs editor that was written in C and ran under Unix. Gosling Emacs became popular but was soon eclipsed by a free version, GNU Emacs, written by Emacs’s original designer. By that time, Gosling had moved on to design Sun’s NeWS, which briefly contended with the X Window System for control of the Unix GUI desktop in 1987. Although some people would argue that NeWS was superior to X, NeWS lost because Sun kept it 2 | Chapter 1: A Modern Language
  • 37. proprietary and didn’t publish source code while the primary developers of X formed the X Consortium and took the opposite approach. Designing NeWS taught Gosling the power of integrating an expressive language with a network-aware windowing GUI. It also taught Sun that the Internet programming community will ultimately refuse to accept proprietary standards, no matter how good they may be. The seeds of Java’s licensing scheme and open (if not quite “open source”) code were sown by NeWS’s failure. Gosling brought what he had learned to Bill Joy’s nascent Aspen project. In 1992, work on the project led to the founding of the Sun subsidiary FirstPerson, Inc. Its mission was to lead Sun into the world of consumer electronics. The FirstPerson team worked on developing software for information appliances, such as cellular phones and personal digital assistants (PDAs). The goal was to enable the transfer of information and real-time applications over cheap infrared and traditional packet-based networks. Memory and bandwidth limitations dictated small, efficient code. The nature of the applications also demanded they be safe and robust. Gosling and his teammates began programming in C++, but they soon found themselves con‐ founded by a language that was too complex, unwieldy, and insecure for the task. They decided to start from scratch, and Gosling began working on something he dubbed “C++ minus minus.” With the foundering of the Apple Newton (Apple’s earliest handheld computer), it be‐ came apparent that the PDA’s ship had not yet come in, so Sun shifted FirstPerson’s efforts to interactive TV (ITV). The programming language of choice for ITV set-top boxes was to be the near ancestor of Java, a language called Oak. Even with its elegance and ability to provide safe interactivity, Oak could not salvage the lost cause of ITV at that time. Customers didn’t want it, and Sun soon abandoned the concept. Atthattime,JoyandGoslinggottogethertodecideonanewstrategyfortheirinnovative language. It was 1993, and the explosion of interest in the Web presented a new oppor‐ tunity. Oak was small, safe, architecture-independent, and object-oriented. As it happens, these are also some of the requirements for a universal, Internet-savvy pro‐ gramminglanguage.Sunquicklychangedfocus,and,withalittleretooling,Oakbecame Java. Growing Up It would not be overstating it to say that Java caught on like wildfire. Even before its first official release when Java was still a nonproduct, nearly every major industry player had jumped on the Java bandwagon. Java licensees included Microsoft, Intel, IBM, and vir‐ tually all major hardware and software vendors. However, even with all this support Java took a lot of knocks and experienced some growing pains during its first few years. Enter Java | 3
  • 38. A series of breach of contract and antitrust lawsuits between Sun and Microsoft over the distribution of Java and its use in Internet Explorer hampered its deployment on the world’s most common desktop operating system—Windows. Microsoft’s involve‐ ment with Java also become one focus of a larger federal lawsuit over serious anticom‐ petitive practices at the company, with court testimony revealing concerted efforts by the software giant to undermine Java by introducing incompatibilities in its version of the language. Meanwhile, Microsoft introduced its own Java-derived language called C# (C-sharp) as part of its .NET initiative and dropped Java from inclusion in Windows. C# has gone on to become a very good language in its own right, enjoying more inno‐ vation in recent years than has Java. But Java continues to spread on a wide variety of platforms. As we begin looking at the Java architecture, you’ll see that much of what is exciting about Java comes from the self-contained, virtual machine environment in which Java applications run. Java was carefully designed so that this supporting architecture can be implemented either in software, for existing computer platforms, or in customized hardware. Hardware im‐ plementations of Java are used in some smart cards and other embedded systems. You can even buy “wearable” devices, such as rings and dog tags, that have Java interpreters embedded in them. Software implementations of Java are available for all modern com‐ puter platforms down to portable computing devices. Today, an offshoot of the Java platform is the basis for Google’s Android operating system that powers billions of phones and other mobile devices. In 2010, Oracle corporation bought Sun Microsystems and became the steward of the Java language. In a somewhat rocky start to its tenure, Oracle sued Google over its use of the Java language in Android and lost. In July of 2011, Oracle released Java SE 7, a significant Java release. A Virtual Machine Java is both a compiled and an interpreted language. Java source code is turned into simple binary instructions, much like ordinary microprocessor machine code. How‐ ever, whereas C or C++ source is reduced to native instructions for a particular model of processor, Java source is compiled into a universal format—instructions for a virtual machine. Compiled Java bytecode is executed by a Java runtime interpreter. The runtime system performs all the normal activities of a hardware processor, but it does so in a safe, virtual environment. It executes a stack-based instruction set and manages memory like an operating system. It creates and manipulates primitive data types and loads and invokes newly referenced blocks of code. Most importantly, it does all this in accordance with a strictly defined open specification that can be implemented by anyone who wants to produce a Java-compliant virtual machine. Together, the virtual machine and language definition provide a complete specification. There are no features of the base Java 4 | Chapter 1: A Modern Language
  • 39. language left undefined or implementation-dependent. For example, Java specifies the sizes and mathematical properties of all its primitive data types rather than leaving it up to the platform implementation. The Java interpreter is relatively lightweight and small; it can be implemented in what‐ ever form is desirable for a particular platform. The interpreter may be run as a separate application or it can be embedded in another piece of software, such as a web browser. Put together, this means that Java code is implicitly portable. The same Java application bytecode can run on any platform that provides a Java runtime environment, as shown in Figure 1-1. You don’t have to produce alternative versions of your application for different platforms, and you don’t have to distribute source code to end users. Figure 1-1. The Java runtime environment The fundamental unit of Java code is the class. As in other object-oriented languages, classes are application components that hold executable code and data. Compiled Java classesaredistributedinauniversalbinaryformatthatcontainsJavabytecodeandother class information. Classes can be maintained discretely and stored in files or archives locally or on a network server. Classes are located and loaded dynamically at runtime as they are needed by an application. In addition to the platform-specific runtime system, Java has a number of fundamental classes that contain architecture-dependent methods. These native methods serve as the gateway between the Java virtual machine and the real world. They are implemented in A Virtual Machine | 5
  • 40. a natively compiled language on the host platform and provide low-level access to re‐ sources such as the network, the windowing system, and the host filesystem. The vast majority of Java, however, is written in Java itself—bootstrapped from these basic primitives—and is therefore portable. This includes fundamental Java tools such as the Java compiler, networking, and GUI libraries, which are also written in Java and are therefore available on all Java platforms in exactly the same way without porting. Historically, interpreters have been considered slow, but Java is not a traditional inter‐ preted language. In addition to compiling source code down to portable bytecode, Java has also been carefully designed so that software implementations of the runtime system can further optimize their performance by compiling bytecode to native machine code on the fly. This is called just-in-time (JIT) or dynamic compilation. With JIT compila‐ tion, Java code can execute as fast as native code and maintain its transportability and security. This is an often misunderstood point among those who want to compare language performance. There is only one intrinsic performance penalty that compiled Java code suffers at runtime for the sake of security and virtual machine design—array bounds checking. Everything else can be optimized to native code just as it can with a statically compiled language. Going beyond that, the Java language includes more structural in‐ formation than many other languages, providing for more types of optimizations. Also remember that these optimizations can be made at runtime, taking into account the actual application behavior and characteristics. What can be done at compile time that can’t be done better at runtime? Well, there is a tradeoff: time. The problem with a traditional JIT compilation is that optimizing code takes time. So a JIT compiler can produce decent results, but may suffer a significant latency when the application starts up. This is generally not a problem for long-running server-side ap‐ plications, but is a serious problem for client-side software and applications that run on smaller devices with limited capabilities. To address this, Java’s compiler technology, called HotSpot, uses a trick called adaptive compilation. If you look at what programs actually spend their time doing, it turns out that they spend almost all their time exe‐ cuting a relatively small part of the code again and again. The chunk of code that is executed repeatedly may be only a small fraction of the total program, but its behavior determines the program’s overall performance. Adaptive compilation also allows the Java runtime to take advantage of new kinds of optimizations that simply can’t be done in a statically compiled language, hence the claim that Java code can run faster than C/ C++ in some cases. To take advantage of this fact, HotSpot starts out as a normal Java bytecode interpreter, but with a difference: it measures (profiles) the code as it is executing to see what parts are being executed repeatedly. Once it knows which parts of the code are crucial to performance, HotSpot compiles those sections into optimal native machine code. Since it compiles only a small portion of the program into machine code, it can afford to take 6 | Chapter 1: A Modern Language
  • 41. the time necessary to optimize those portions. The rest of the program may not need to be compiled at all—just interpreted—saving memory and time. In fact, the Java VM can run in one of two modes: client and server, which determine whether it emphasizes quick startup time and memory conservation or flat out performance. A natural question to ask at this point is, Why throw away all this good profiling infor‐ mation each time an application shuts down? Well, Sun partially broached this topic with the release of Java 5.0 through the use of shared, read-only classes that are stored persistently in an optimized form. This significantly reduced both the startup time and overhead of running many Java applications on a given machine. The technology for doing this is complex, but the idea is simple: optimize the parts of the program that need to go fast and don’t worry about the rest. Java Compared with Other Languages Java draws on many years of programming experience with other languages in its choice of features. It is worth taking a moment to compare Java at a high level with some other languages, both for the benefit of those of you with other programming experience and for the newcomers who need to put things in context. We do not expect you to have a knowledge of any particular programming language in this book and when we refer to other languages by way of comparison, we hope that the comments are self-explanatory. At least three pillars are necessary to support a universal programming language today: portability, speed, and security. Figure 1-2 shows how Java compares to a a few of the languages that were popular when it was created. Figure 1-2. Programming languages compared You may have heard that Java is a lot like C or C++, but that’s really not true except at a superficial level. When you first look at Java code, you’ll see that the basic syntax looks like C or C++. But that’s where the similarities end. Java is by no means a direct Java Compared with Other Languages | 7
  • 42. descendant of C or a next-generation C++. If you compare language features, you’ll see that Java actually has more in common with highly dynamic languages such as Smalltalk and Lisp. In fact, Java’s implementation is about as far from native C as you can imagine. Ifyouarefamiliarwiththecurrentlanguagelandscape,youwillnoticethatC#,apopular language, is missing from this comparison. C# is largely Microsoft’s answer to Java, admittedly with a number of niceties layered on top. Given their common design goals and approach (e.g., use of a virtual machine, bytecode, sandbox, etc.), the platforms don’t differ substantially in terms of their speed or security characteristics. C# is theo‐ retically as portable as Java, but to date it is supported on far fewer platforms. Like Java, C#borrowsheavilyfromCsyntaxbutisreallyacloserrelativeofthedynamiclanguages. Most Java developers find it relatively easy to pick up C# and vice versa. The majority of time spent moving from one to the other is learning the standard library. Thesurface-levelsimilaritiestotheselanguagesareworthnoting,however.Javaborrows heavily from C and C++ syntax, so you’ll see terse language constructs, including an abundance of curly braces and semicolons. Java subscribes to the C philosophy that a good language should be compact; in other words, it should be sufficiently small and regular so a programmer can hold all the language’s capabilities in his or her head at once. Just as C is extensible with libraries, packages of Java classes can be added to the core language components to extend its vocabulary. C has been successful because it provides a reasonably feature-packed programming environment, with high performance and an acceptable degree of portability. Java also tries to balance functionality, speed, and portability, but it does so in a very different way. C trades functionality for portability; Java initially traded speed for portability. Java also addresses security issues that C does not (although in modern systems many of those concerns are now addressed in the operating system and hardware). In the early days before JIT and adaptive compilation, Java was slower than statically compiled languages and there was a constant refrain from detractors that it would never catch up. But as we described in the previous section, Java’s performance is now com‐ parable to C or C++ for equivalent tasks and those criticisms have generally fallen quiet. ID Software’s open source Quake2 video game engine has been ported to Java. If Java is fast enough for first-person combat video games, it’s certainly fast enough for business applications. Scripting languages such as Perl, Python, and Ruby are very popular. There’s no reason ascriptinglanguagecan’tbesuitableforsafe,networkedapplications.Butmostscripting languages are not well suited for serious, large-scale programming. The attraction to scripting languages is that they are dynamic; they are powerful tools for rapid develop‐ ment. Some scripting languages such as Perl also provide powerful tools for text-processing tasks that more general-purpose languages find unwieldy. Scripting languages are also highly portable, albeit at the source code level. 8 | Chapter 1: A Modern Language
  • 43. 1. See, for example, G. Phipps, “Comparing Observed Bug and Productivity Rates for Java and C++,”Software —Practice & Experience, volume 29, 1999. Not to be confused with Java, JavaScript is an object-based scripting language originally developed by Netscape for the web browser. It serves as a web browser resident language for dynamic, interactive web-based applications. JavaScript takes its name from its in‐ tegration with and similarities to Java, but the comparison really ends there. While there have been applications of JavaScript outside of the browser, it has not truly caught on as a general scripting language. For more information on JavaScript, check out Java‐ Script: The Definitive Guide by David Flanagan (O’Reilly). The problem with scripting languages is that they are rather casual about program structure and data typing. Most scripting languages (with a hesitant exception for Python and later versions of Perl) are not object-oriented. They also have simplified type systems and generally don’t provide for sophisticated scoping of variables and functions. These characteristics make them less suitable for building large, modular applications. Speed is another problem with scripting languages; the high-level, usually source-interpreted nature of these languages often makes them quite slow. Advocates of individual scripting languages would take issue with some of these gen‐ eralizations, and no doubt they’d be right in some cases. Scripting languages have im‐ proved in recent years—especially JavaScript, which has had an enormous amount of research poured into its performance. But the fundamental tradeoff is undeniable: scripting languages were born as loose, less structured alternatives to systems program‐ ming languages and are generally not ideal for large or complex projects for a variety of reasons, at least not today. Java offers some of the essential advantages of a scripting language: it is highly dynamic, along with the added benefits of a lower-level language. Java has a powerful Regular Expression API that competes with Perl for working with text and language features that streamline coding with collections, variable argument lists, static imports of meth‐ ods, and other syntactic sugar that make it more concise. Incremental development with object-oriented components, combined with Java’s sim‐ plicity, make it possible to develop applications rapidly and change them easily. Studies havefoundthatdevelopmentinJavaisfasterthaninCorC++,strictlybasedonlanguage features.1 Java also comes with a large base of standard core classes for common tasks such as building GUIs and handling network communications. But along with these features, Java has the scalability and software-engineering advantages of more static languages. It provides a safe structure on which to build higher-level frameworks (and even other languages). As we’ve already said, Java is similar in design to languages such as Smalltalk and Lisp. However, these languages were used mostly as research vehicles rather than for Java Compared with Other Languages | 9
  • 44. development of large-scale systems. One reason is that these languages never developed a standard portable binding to operating system services, such as the C standard library or the Java core classes. Smalltalk is compiled to an interpreted bytecode format, and it can be dynamically compiled to native code on the fly, just like Java. But Java improves on the design by using a bytecode verifier to ensure the correctness of compiled Java code. This verifier gives Java a performance advantage over Smalltalk because Java code requires fewer runtime checks. Java’s bytecode verifier also helps with security issues, something that Smalltalk doesn’t address. Throughout the rest of this chapter, we’ll present a bird’s-eye view of the Java language. We’ll explain what’s new and what’s not-so-new about Java and why. Safety of Design You have no doubt heard a lot about the fact that Java is designed to be a safe language. Butwhatdowemeanbysafe?Safefromwhatorwhom?Thesecurityfeaturesthatattract the most attention for Java are those features that make possible new types of dynami‐ cally portable software. Java provides several layers of protection from dangerously flawed code as well as more mischievous things such as viruses and Trojan horses. In the next section, we’ll take a look at how the Java virtual machine architecture assesses the safety of code before it’s run and how the Java class loader (the bytecode loading mechanismoftheJavainterpreter)buildsawallarounduntrustedclasses.Thesefeatures provide the foundation for high-level security policies that can allow or disallow various kinds of activities on an application-by-application basis. In this section, though, we’ll look at some general features of the Java programming language. Perhaps more important than the specific security features, although often overlooked in the security din, is the safety that Java provides by addressing common design and programming problems. Java is intended to be as safe as possible from the simple mistakes we make ourselves as well as those we inherit from legacy software. The goal with Java has been to keep the language simple, provide tools that have demon‐ strated their usefulness, and let users build more complicated facilities on top of the language when needed. Simplify, Simplify, Simplify... With Java, simplicity rules. Since Java started with a clean slate, it was able to avoid features that proved to be messy or controversial in other languages. For example, Java doesn’t allow programmer-defined operator overloading (which in some languages al‐ lows programmers to redefine the meaning of basic symbols like + and –). Java doesn’t have a source code preprocessor, so it doesn’t have things like macros, #define state‐ ments, or conditional source compilation. These constructs exist in other languages primarily to support platform dependencies, so in that sense, they should not be needed in Java. Conditional compilation is also commonly used for debugging, but Java’s 10 | Chapter 1: A Modern Language
  • 45. sophisticated runtime optimizations and features such as assertions solve the problem more elegantly (we’ll cover these in Chapter 4). Java provides a well-defined package structure for organizing class files. The package system allows the compiler to handle some of the functionality of the traditional make utility (a tool for building executables from source code). The compiler can also work with compiled Java classes directly because all type information is preserved; there is no need for extraneous source “header” files, as in C/C++. All this means that Java code requires less context to read. Indeed, you may sometimes find it faster to look at the Java source code than to refer to class documentation. Java also takes a different approach to some structural features that have been trouble‐ some in other languages. For example, Java supports only a single inheritance class hierarchy (each class may have only one “parent” class), but allows multiple inheritance of interfaces. An interface, like an abstract class in C++, specifies the behavior of an object without defining its implementation. It is a very powerful mechanism that allows the developer to define a “contract” for object behavior that can be used and referred to independently of any particular object implementation. Interfaces in Java eliminate the need for multiple inheritance of classes and the associated problems. As you’ll see in Chapter 4, Java is a fairly simple and elegant programming language and that is still a large part of its appeal. Type Safety and Method Binding One attribute of a language is the kind of type checking it uses. Generally, languages are categorized as static or dynamic, which refers to the amount of information about vari‐ ables known at compile time versus what is known while the application is running. In a strictly statically typed language such as C or C++, data types are etched in stone when the source code is compiled. The compiler benefits from this by having enough information to catch many kinds of errors before the code is executed. For example, the compiler would not allow you to store a floating-point value in an integer variable. The code then doesn’t require runtime type checking, so it can be compiled to be small and fast. But statically typed languages are inflexible. They don’t support collections as nat‐ urally as languages with dynamic type checking, and they make it impossible for an application to safely import new data types while it’s running. In contrast, a dynamic language such as Smalltalk or Lisp has a runtime system that manages the types of objects and performs necessary type checking while an application isexecuting.Thesekindsoflanguagesallowformorecomplexbehaviorandareinmany respects more powerful. However, they are also generally slower, less safe, and harder to debug. Safety of Design | 11
  • 46. 2. The credit for the car analogy goes to Marshall P. Cline, author of the C++ FAQ. The differences in languages have been likened to the differences among kinds of au‐ tomobiles.2 Statically typed languages such as C++ are analogous to a sports car: rea‐ sonably safe and fast, but useful only if you’re driving on a nicely paved road. Highly dynamic languages such as Smalltalk are more like an off-road vehicle: they afford you more freedom but can be somewhat unwieldy. It can be fun (and sometimes faster) to go roaring through the backwoods, but you might also get stuck in a ditch or mauled by bears. Another attribute of a language is the way it binds method calls to their definitions. In a static language such as C or C++, the definitions of methods are normally bound at compile time, unless the programmer specifies otherwise. Languages like Smalltalk, on the other hand, are called late binding because they locate the definitions of methods dynamically at runtime. Early binding is important for performance reasons; an appli‐ cation can run without the overhead incurred by searching for methods at runtime. But late binding is more flexible. It’s also necessary in an object-oriented language where new types can be loaded dynamically and only the runtime system can determine which method to run. Java provides some of the benefits of both C++ and Smalltalk; it’s a statically typed, late- binding language. Every object in Java has a well-defined type that is known at compile time. This means the Java compiler can do the same kind of static type checking and usageanalysisasC++.Asaresult,youcan’tassignanobjecttothewrongtypeofvariable or call nonexistent methods on an object. The Java compiler goes even further and prevents you from using uninitialized variables and creating unreachable statements (see Chapter 4). However, Java is fully runtime-typed as well. The Java runtime system keeps track of all objects and makes it possible to determine their types and relationships during execu‐ tion. This means you can inspect an object at runtime to determine what it is. Unlike C or C++, casts from one type of object to another are checked by the runtime system, and it’s possible to use new kinds of dynamically loaded objects with a degree of type safety. And because Java is a late binding language, it’s always possible for a subclass to override methods in its superclass, even a subclass loaded at runtime. Incremental Development Java carries all data type and method signature information with it from its source code to its compiled bytecode form. This means that Java classes can be developed incre‐ mentally. Your own Java source code can also be compiled safely with classes from other sources your compiler has never seen. In other words, you can write new code that references binary class files without losing the type safety you gain from having the source code. 12 | Chapter 1: A Modern Language
  • 47. Java does not suffer from the “fragile base class” problem. In languages such as C++, the implementation of a base class can be effectively frozen because it has many derived classes; changing the base class may require recompilation of all of the derived classes. This is an especially difficult problem for developers of class libraries. Java avoids this problem by dynamically locating fields within classes. As long as a class maintains a valid form of its original structure, it can evolve without breaking other classes that are derived from it or that make use of it. Dynamic Memory Management Some of the most important differences between Java and lower-level languages such as C and C++ involve how Java manages memory. Java eliminates ad hoc “pointers” that can reference arbitrary areas of memory and adds object garbage collection and high- level arrays to the language. These features eliminate many otherwise insurmountable problems with safety, portability, and optimization. Garbage collection alone has saved countless programmers from the single largest source of programming errors in C or C++: explicit memory allocation and dealloca‐ tion. In addition to maintaining objects in memory, the Java runtime system keeps track of all references to those objects. When an object is no longer in use, Java automatically removesitfrommemory.Youcan,forthemostpart,simplyignoreobjectsyounolonger use, with confidence that the interpreter will clean them up at an appropriate time. Java uses a sophisticated garbage collector that runs in the background, which means that most garbage collecting takes place during idle times, between I/O pauses, mouse clicks, or keyboard hits. Advanced runtime systems, such as HotSpot, have more ad‐ vanced garbage collection that can differentiate the usage patterns of objects (such as short-lived versus long-lived) and optimize their collection. The Java runtime can now tune itself automatically for the optimal distribution of memory for different kinds of applications based on their behavior. With this kind of runtime profiling, automatic memory management can be much faster than the most diligently programmer- managed resources, something that some old-school programmers still find hard to believe. We’ve said that Java doesn’t have pointers. Strictly speaking, this statement is true, but it’s also misleading. What Java provides are references—a safe kind of pointer. A refer‐ ence is a strongly typed handle for an object. All objects in Java, with the exception of primitive numeric types, are accessed through references. You can use references to build all the normal kinds of data structures a C programmer would be accustomed to building with pointers, such as linked lists, trees, and so forth. The only difference is that with references, you have to do so in a typesafe way. Another important difference between a reference and a pointer is that you can’t play games (perform pointer arithmetic) with references to change their values; they can point only to specific objects or elements of an array. A reference is an atomic thing; Safety of Design | 13
  • 48. you can’t manipulate the value of a reference except by assigning it to an object. Refer‐ ences are passed by value, and you can’t reference an object through more than a single level of indirection. The protection of references is one of the most fundamental aspects of Java security. It means that Java code has to play by the rules; it can’t peek into places it shouldn’t and circumvent the rules. Java references can point only to class types. There are no pointers to methods. People sometimes complain about this missing feature, but you will find that most tasks that call for pointers to methods can be accomplished more cleanly using interfaces and adapter classes instead. We should also mention that Java has a sophisticated Reflection API that actually allows you to reference and invoke individual methods. However, this is not the normal way of doing things. We discuss reflection in Chapter 7. Finally, we should mention that arrays in Java are true, first-class objects. They can be dynamically allocated and assigned like other objects. Arrays know their own size and type, and although you can’t directly define or subclass array classes, they do have a well- defined inheritance relationship based on the relationship of their base types. Having true arrays in the language alleviates much of the need for pointer arithmetic, such as that used in C or C++. Error Handling Java’s roots are in networked devices and embedded systems. For these applications, it’s important to have robust and intelligent error management. Java has a powerful excep‐ tion handling mechanism, somewhat like that in newer implementations of C++. Ex‐ ceptions provide a more natural and elegant way to handle errors. Exceptions allow you to separate error handling code from normal code, which makes for cleaner, more readable applications. When an exception occurs, it causes the flow of program execution to be transferred to a predesignated “catch” block of code. The exception carries with it an object that con‐ tains information about the situation that caused the exception. The Java compiler re‐ quires that a method either declare the exceptions it can generate or catch and deal with them itself. This promotes error information to the same level of importance as argu‐ ment and return types for methods. As a Java programmer, you know precisely what exceptional conditions you must deal with, and you have help from the compiler in writing correct software that doesn’t leave them unhandled. Threads Modern applications require a high degree of parallelism. Even a very single-minded application can have a complex user interface—which requires concurrent activities. As machinesgetfaster,usersbecomemoresensitivetowaitingforunrelatedtasksthatseize controloftheirtime.Threadsprovideefficientmultiprocessinganddistributionoftasks 14 | Chapter 1: A Modern Language
  • 49. for both client and server applications. Java makes threads easy to use because support for them is built into the language. Concurrency is nice, but there’s more to programming with threads than just perform‐ ing multiple tasks simultaneously. In most cases, threads need to be synchronized (co‐ ordinated), which can be tricky without explicit language support. Java supports synchronization based on the monitor and condition model—a sort of lock and key system for accessing resources. The keyword synchronized designates methods and blocksofcodeforsafe,serializedaccesswithinanobject.Therearealsosimple,primitive methodsforexplicitwaitingandsignalingbetweenthreadsinterestedinthesameobject. Java also has a high-level concurrency package that provides powerful utilities address‐ ing common patterns in multithreaded programming, such as thread pools, coordina‐ tion of tasks, and sophisticated locking. With the addition of the concurrency package and related utilities, Java provides some of the most advanced thread-related utilities of any language. Although some developers may never have to write multithreaded code, learning to program with threads is an important part of mastering programming in Java and something all developers should grasp. See Chapter 9 for a discussion of this topic. Scalability At the lowest level, Java programs consist of classes. Classes are intended to be small, modular components. Over classes, Java provides packages, a layer of structure that groups classes into functional units. Packages provide a naming convention for organ‐ izing classes and a second tier of organizational control over the visibility of variables and methods in Java applications. Within a package, a class is either publicly visible or protected from outside access. Packages form another type of scope that is closer to the application level. This lends itself to building reusable components that work together in a system. Packages also help in designing a scalable application that can grow without becoming a bird’s nest of tightly coupled code. Safety of Implementation It’s one thing to create a language that prevents you from shooting yourself in the foot; it’s quite another to create one that prevents others from shooting you in the foot. Encapsulation is the concept of hiding data and behavior within a class; it’s an important part of object-oriented design. It helps you write clean, modular software. In most lan‐ guages, however, the visibility of data items is simply part of the relationship between the programmer and the compiler. It’s a matter of semantics, not an assertion about the actual security of the data in the context of the running program’s environment. Safety of Implementation | 15
  • 50. When Bjarne Stroustrup chose the keyword private to designate hidden members of classes in C++, he was probably thinking about shielding a developer from the messy details of another developer’s code, not the issues of shielding that developer’s classes and objects from attack by someone else’s viruses and Trojan horses. Arbitrary casting and pointer arithmetic in C or C++ make it trivial to violate access permissions on classes without breaking the rules of the language. Consider the following code: // C++ code class Finances { private: char creditCardNumber[16]; ... }; main() { Finances finances; // Forge a pointer to peek inside the class char *cardno = (char *)&finances; printf("Card Number = %.16sn", cardno); } In this little C++ drama, we have written some code that violates the encapsulation of the Finances class and pulls out some secret information. This sort of shenanigan— abusing an untyped pointer—is not possible in Java. If this example seems unrealistic, consider how important it is to protect the foundation (system) classes of the runtime environment from similar kinds of attacks. If untrusted code can corrupt the compo‐ nentsthatprovideaccesstorealresourcessuchasthefilesystem,network,orwindowing system, it certainly has a chance at stealing your credit card numbers. IfaJavaapplicationistobeabletodynamicallydownloadcodefromanuntrustedsource on the Internet and run it alongside applications that might contain confidential infor‐ mation, protection has to extend very deep. The Java security model wraps three layers of protection around imported classes, as shown in Figure 1-3. Figure 1-3. The Java security model 16 | Chapter 1: A Modern Language
  • 51. At the outside, application-level security decisions are made by a security manager in conjunction with a flexible security policy. A security manager controls access to system resourcessuchasthefilesystem,networkports,andwindowingenvironment.Asecurity manager relies on the ability of a class loader to protect basic system classes. A class loader handles loading classes from local storage or the network. At the innermost level, all system security ultimately rests on the Java verifier, which guarantees the integrity of incoming classes. The Java bytecode verifier is a fixed part of the Java runtime system. Class loaders and security managers (or security policies to be more precise), however, are components that may be implemented differently by different applications, such as servers or web browsers. All three of these pieces need to be functioning properly to ensure security in the Java environment. The Verifier Java’s first line of defense is the bytecode verifier. The verifier reads bytecode before it is run and makes sure it is well behaved and obeys the basic rules of the Java language. A trusted Java compiler won’t produce code that does otherwise. However, it’s possible for a mischievous person to deliberately assemble bad Java bytecode. It’s the verifier’s job to detect this. Once code has been verified, it’s considered safe from certain inadvertent or malicious errors. For example, verified code can’t forge references or violate access permissions on objects (as in our credit card example). It can’t perform illegal casts or use objects in unintended ways. It can’t even cause certain types of internal errors, such as overflowing or underflowing the internal stack. These fundamental guarantees underlie all of Java’s security. Youmightbewondering,isn’tthiskindofsafetyimplicitinlotsofinterpretedlanguages? Well, while it’s true that you shouldn’t be able to corrupt a BASIC interpreter with a bogus line of BASIC code, remember that the protection in most interpreted languages happens at a higher level. Those languages are likely to have heavyweight interpreters that do a great deal of runtime work, so they are necessarily slower and more cumbersome. By comparison, Java bytecode is a relatively light, low-level instruction set. The ability to statically verify the Java bytecode before execution lets the Java interpreter run at full speed later with full safety, without expensive runtime checks. This was one of the fun‐ damental innovations in Java. The verifier is a type of mathematical “theorem prover.” It steps through the Java byte‐ code and applies simple, inductive rules to determine certain aspects of how the byte‐ code will behave. This kind of analysis is possible because compiled Java bytecode contains a lot more type information than the object code of other languages of this Safety of Implementation | 17
  • 52. kind. The bytecode also has to obey a few extra rules that simplify its behavior. First, most bytecode instructions operate only on individual data types. For example, with stack operations, there are separate instructions for object references and for each of the numeric types in Java. Similarly, there is a different instruction for moving each type of value into and out of a local variable. Second, the type of object resulting from any operation is always known in advance. No bytecode operations consume values and produce more than one possible type of value as output. As a result, it’s always possible to look at the next instruction and its operands and know the type of value that will result. Because an operation always produces a known type, it’s possible to determine the types of all items on the stack and in local variables at any point in the future by looking at the starting state. The collection of all this type information at any given time is called the type state of the stack; this is what Java tries to analyze before it runs an application. Java doesn’t know anything about the actual values of stack and variable items at this time; it only knows what kind of items they are. However, this is enough information to enforce the security rules and to ensure that objects are not manipulated illegally. To make it feasible to analyze the type state of the stack, Java places an additional re‐ striction on how Java bytecode instructions are executed: all paths to the same point in the code must arrive with exactly the same type state. Class Loaders Java adds a second layer of security with a class loader. A class loader is responsible for bringing the bytecode for Java classes into the interpreter. Every application that loads classes from the network must use a class loader to handle this task. After a class has been loaded and passed through the verifier, it remains associated with its class loader. As a result, classes are effectively partitioned into separate namespaces based on their origin. When a loaded class references another class name, the location of the new class is provided by the original class loader. This means that classes retrieved from a specific source can be restricted to interact only with other classes retrieved from that same location. For example, a Java-enabled web browser can use a class loader to build a separate space for all the classes loaded from a given URL. Sophisticated security based on cryptographically signed classes can also be implemented using class loaders. The search for classes always begins with the built-in Java system classes. These classes are loaded from the locations specified by the Java interpreter’s classpath (see Chap‐ ter 3). Classes in the classpath are loaded by the system only once and can’t be replaced. This means that it’s impossible for an application to replace fundamental system classes with its own versions that change their functionality. 18 | Chapter 1: A Modern Language
  • 53. Security Managers A security manager is responsible for making application-level security decisions. A security manager is an object that can be installed by an application to restrict access to system resources. The security manager is consulted every time the application tries to access items such as the filesystem, network ports, external processes, and the window‐ ing environment; the security manager can allow or deny the request. Security managers are primarily of interest to applications that run untrusted code as partoftheirnormaloperation.Forexample,aJava-enabledwebbrowsercanrunapplets that may be retrieved from untrusted sources on the Net. Such a browser needs to install a security manager as one of its first actions. This security manager then restricts the kinds of access allowed after that point. This lets the application impose an effective level of trust before running an arbitrary piece of code. And once a security manager is installed, it can’t be replaced. The security manager works in conjunction with an access controller that lets you im‐ plement security policies at a high level by editing a declarative security policy file. Access policies can be as simple or complex as a particular application warrants. Some‐ times it’s sufficient simply to deny access to all resources or to general categories of services, such as the filesystem or network. But it’s also possible to make sophisticated decisions based on high-level information. For example, a Java-enabled web browser could use an access policy that lets users specify how much an applet is to be trusted or that allows or denies access to specific resources on a case-by-case basis. Of course, this assumes that the browser can determine which applets it ought to trust. We’ll discuss how this problem is addressed through code-signing shortly. The integrity of a security manager is based on the protection afforded by the lower levels of the Java security model. Without the guarantees provided by the verifier and the class loader, high-level assertions about the safety of system resources are mean‐ ingless. The safety provided by the Java bytecode verifier means that the interpreter can’t becorruptedorsubvertedandthatJavacodehastousecomponentsastheyareintended. This, in turn, means that a class loader can guarantee that an application is using the core Java system classes and that these classes are the only way to access basic system resources. With these restrictions in place, it’s possible to centralize control over those resources at a high level with a security manager and user-defined policy. Application and User-Level Security There’s a fine line between having enough power to do something useful and having all the power to do anything you want. Java provides the foundation for a secure environ‐ ment in which untrusted code can be quarantined, managed, and safely executed. How‐ ever, unless you are content with keeping that code in a little black box and running it just for its own benefit, you will have to grant it access to at least some system resources Application and User-Level Security | 19
  • 54. so that it can be useful. Every kind of access carries with it certain risks and benefits. For example, in the web browser environment, the advantages of granting an untrusted (unknown) applet access to your windowing system are that it can display information and let you interact in a useful way. The associated risks are that the applet may instead display something worthless, annoying, or offensive. At one extreme, the simple act of running an application gives it a resource—compu‐ tation time—that it may put to good use or burn frivolously. It’s difficult to prevent an untrusted application from wasting your time or even attempting a “denial of service” attack. At the other extreme, a powerful, trusted application may justifiably deserve access to all sorts of system resources (e.g., the filesystem, process creation, network interfaces); a malicious application could wreak havoc with these resources. The mes‐ sage here is that important and sometimes complex security issues have to be addressed. In some situations, it may be acceptable to simply ask the user to “okay” requests. The Java language provides the tools to implement any security policies you want. However, what these policies will be ultimately depends on having confidence in the identity and integrity of the code in question. This is where digital signatures come into play. Digital signatures, together with certificates, are techniques for verifying that data truly comes from the source it claims to have come from and hasn’t been modified en route. If the Bank of Boofa signs its checkbook application, you can verify that the app actually came from the bank rather than an imposter and hasn’t been modified. Therefore, you can tell your browser to trust applets that have the Bank of Boofa’s signature. A Java Road Map With everything that’s going on, it’s hard to keep track of what’s available now, what’s promised, and what has been around for some time. The following sections constitute a road map that imposes some order on Java’s past, present, and future. The Past: Java 1.0–Java 1.6 Java 1.0 provided the basic framework for Java development: the language itself plus packages that let you write applets and simple applications. Although 1.0 is officially obsolete, there are still a lot of applets in existence that conform to its API. Java 1.1 superseded 1.0, incorporating major improvements in the Abstract Window Toolkit (AWT) package (Java’s original GUI facility), a new event pattern, new language facilities such as reflection and inner classes, and many other critical features. Java 1.1 is the version that was supported natively by most versions of Netscape and Microsoft Internet Explorer for many years. For various political reasons, the browser world was frozen in this condition for a long time. This version of Java is still considered a sort of baseline for applets, although even this will fall away as Microsoft drops support for Java in its platforms. 20 | Chapter 1: A Modern Language
  • 55. Another Random Document on Scribd Without Any Related Topics
  • 56. Poletes, n. pl. pullets, chickens, VIII a 275. [OFr. polete.] Polyse (V), Pollis(s)che, Pollysch, v. to polish, IX 35, 41, 119, 121, &c.; to cleanse, V 325. [OFr. polir, poliss-.] Pond, n.1 pool, lake, XIII a 19, 31, 43, &c.; Pound, XIII a 21, 23, 24, 25. [OE. *púnd, cf. pýndan.] Pond, n.2 pl. pounds, III 21, 24, &c.; Poundis, XI b 162. [OE. púnd.] Pope, n. Pope, I 249, VIII b 82, IX 286, XI b 46. [OE. pāpa.] Popi, n. poppy, XII a 81. [OE. popig.] Por-. See Pur-. Porche, n. porch, I 77. [OFr. porche.] Pore. See Pouer(e). Poret(te), n. (young) leek or onion, VIII a 281; collect. sg. VIII a 293. [OFr. poret, leek; porette, small onion.] Porful, adj. poverty-stricken, XV f 2. [From Pouer(e), Pore.] Porpos. See Purpos. Porter, n. porter (at the gates), II 380, V 4, &c. [OFr. port(i)er.] Portos, n. (pl. as sg.) breviary, XI b 228 (see note). [OFr. portehors.] Possyble, adj. possible, VI 92. [OFr. possible.] Post(e)les, n. pl. apostles, XV g 24, 25; itinerant preachers, VIII a 143. [OE. postol.] See Apostel. Potage, n. (vegetable) soup, VIII a 144. [OFr. potage.] Potful, n. potful, VIII a 180. [OE. pott + full (properly adj. with prec. noun).] Pound. See Pond. Pouerlich, adv. in humble guise, II 236, 567. [From prec.] Pouer(e), adj. poor, humble, II 430, 486, XII b 20, 36, &c.; Poeuere, XI b 272; Poure, III 48, IV b 20, VIII b 82; Pore, VI 213, VIII a 18, XI b 255, &c.; adj. pl. as sb., poor
  • 57. (people), the poor, III 8, 41, VIII a 18, &c.; Pouren, dat. pl. III 7. [OFr. pov(e)re, poure.] Pour-. See Pur-. Power(e), Pouer, Poure, n. ability, power, VIII a 35, XII a 187, XVI 219; authority, VIII a 143; forces, XIV c 46. [OFr. po(u)eir, pouer.] Pray(e), n. prey, II 313, XVI 175; fig. (of good things won as prize) VI 79. [OFr. preie.] Prece, Pres(s), v. to press; thrust, force, X 49, 69, &c.; intr. and refl. to press forward, hasten, V 29, X 131; pressit on, assailed, X 190; hardest pressit, most hard pressed, X 150. See Prees. [OFr. presser; on forms prece, pre(e)s, see N.E.D.] Preche, v. to preach, VIII a 143, XI b 7, 24, XVI 51, &c.; Prechinge, -ynge, n. preaching, III 49, XI b 3, &c. [OFr. prech(i)er.] Precious, Precy(i)ous(e), adj. precious, costly, IX 42, 99, XI b 257; precious ston, II 151, 366, IX 123. [OFr. precious.] Preef, n. test, IX 128. [OFr. proeve.] See Preue. Prees, Press, n. press; crowd, XII b 213; uproar, commotion, XVI 125. [From Prece, q.v.] Preeued. See Preue. Preie, Preye(n), Prey, Pray(e), v. to pray, beg, II 534, IV b 8, VIII a 119, 250, XI b 37, XVII 242, &c.; Praid, Preide, Preyd(e), pa. t. I 89, II 224, VIII a 117, XII b 69; pray, pray to, VI 124; preye of, beg for, VIII a 38, 117; preye to, pray (to), IX 320, 322; Preiynge, n. in p. of lippes, prayer with lips (only), XI b 89. [OFr. preier.] Preiere, Preyer(e), Preȝer (XIV c), n. prayer, VIII a 244, b 88, XI b 36, XIV c 78, &c.; preiere in lippis, p. with the lips (only), XI b 90. [OFr. preiere.] Preise(n), Preyse, Prayse, v. to praise, esteem, V 4, VIII a 102, b 31, XI b 176, 182. [OFr. preis(i)er.] See Prese, Prys,
  • 58. Prist. Preostes. See Prest(e), n. Pres(s). See Prece, Prees. Prese, n. praise, great worth, VI 59. [Stem of Preise(n) with AFr. monophthongization.] Presence, n. presence, IX 94, XII b 127, &c. [OFr. presence.] Present(e), adj. present, IX 128, 336; as sb. in in your presente, in your presence, VI 29. [OFr. present.] Present, n. present, gift, I 123, VIII a 42, 290. [OFr. present.] Presente, v. to give gifts to, IX 24. [OFr. presenter.] Prest, adj. prompt, quick, VIII a 190, XIV b 67; Prestly, adv. promptly, VIII a 87. [OFr. prest.] Prest(e), n. priest, I 8, 9, III 49 (dat.), 53, &c.; Preost, XI b 291. [OE. prēost.] Presthod, n. priesthood, XI b 47. [OE prēost-hād.] Pretermynable, adj. who predetermines, fore-ordains, VI 236. [Appar. invented for rhyme from pre + terminable used actively.] Preue, Preeue, v. to prove, show, VII 47, IX 298; to test, IX 297; to approve, IX 305. [OFr. preuv-, proev-, &c. accented stem of prover.] See Preef, Proue. Pryde, Pride, n. pride, magnificence, IV a 59, b 14, XI b 55, XVII 543, &c.; of pryde, proud, XVI 182. [OE. prȳdo.] See Proude. Priis. See Prys. Prike, v. to spur; intr. gallop, II 141, XIV a 15. [OE. prician, to prick.] Pryme, n. prime, first division of the day according to the sun (varying with the season), or a fixed period 6-9 a.m.; heighe pryme, fully prime, end of the period of prime, about 9 a.m., VIII a 106. [OE. prīm, from L. prīma (hōra).]
  • 59. Prymer, n. devotional manual, VIII b 48 (note). [Origin of name doubtful; see N.E.D.] Primerole, n. primrose, XV e 9, 10, 13. [OFr. primerole.] Prynce, Prince, n. prince, V 4 (i.e. Sir Gawayne), XIV c 59, XVI 182, &c. [OFr. prince.] Princypall, Principall, adj. and n. chief, IX 1, 28, XVI 111; Principaly, adv. in the first place, XI b 96. [OFr. principal, or L. principālis.] Pryour, n. priory, VIII b 95. [OFr. priorie; with this form of the suffix cf. Oritore.] Prys, Prise, Priis (II), n. worth, excellence, V 296, VI 59; of priis, &c., worthy, excellent, noble, II 51, 64, 249, V 330, VII 47. [OFr. pris, earlier prieis.] See Preise(n), Prist. Prisoune, Prison, n. prison, XI b 126, XVI 220 (or read prisounes, prisoners; see note). [OFr. priso(u)n.] Prist, pp. esteemed, VII 33. [OFr. pris(i)er.] See Preise(n). Processioun, n. procession; pomp, II 587. [OFr. procession.] Proferi, Profre, v. to offer, II 434, V 278, VIII a 25, XII b 122, &c. [OFr. proffrir; proferer.] Profession, n. declaration; vows (on entering religious order), in singular prof., special vows, as opposed to the regular vows taken by all priests, XI b 101. [OFr. profession.] Profit, n. profit, VIII b 107. [OFr. profit.] Profit-, Profytable, adj. profitable, advantageous, VIII a 270, XIII b 68. [OFr. profitable.] Prologe, n. prologue, VII 96, [OFr. prologue.] Property, n. property, special virtue, VI 86. [OFr. proprieté.] Prophet(t)e, n. prophet, XI b 18, XV g 9, XVI 267, &c. [OFr. prophete, L. prophēta.] Prophecye, Prophicye, n. prophecy, IX 216, XVI 27. [OFr. prophecie.]
  • 60. Prophicied, pa. t. prophesied (MS. prophicie), XVI 188. [From prec.] Propre, adj. proper, separate, IX 187; Propurly, adv. properly, rightly (or of my own knowledge, at first hand), IX 264. [OFr. propre.] Proude, Prowd(e), adj. magnificent, glorious, II 376; proud, haughty, arrogant, V 36, 201, VIII a 191, XV b 32, &c.; prowdist of pryde, greatest in pride (or splendour), XVII 543; Prowdly, adv. out of pride, XVII 17. [OE. prūt (rarely prūd), from OFr. prout, prou(d), valiant.] Proue, Prufe, v. to prove; demonstrate, show, X 74, XVI 255; test, try, XVII 460. [OFr. prover; cf. OE. prōfian.] See Preue. Prow(e) (to), n. benefit, good (of), IV b 82, XVI 220, 326; may to prow, may be of benefit ('prow' prob. apprehended as infin.), I introd. [OFr. prou.] Psalme, n. psalm, VIII a 246; Seuene Psalmes, the Seven Penitential Psalms, VIII b 49; note allit. with s. [OE. (p)salm, L. psalmus.] Puire, Puit. See Pure, Putte(n). Pull, v.; Puld, pa. t.; to drag, VII 178; pull up, hoist, VII 125, XVII 153. [OE. pullian.] Puple. See Peopull. Puplisshid, pp. (rime requires puplist), openly declared, XVI 59. [OFr. puplier + -is(h) from other verbs of Fr. origin.] Purchase, Porchase, Pourchace, v. to acquire, obtain, VI 79, VIII b 81, XII a 18. [OFr. p(o)urchac(i)er.] Pure, Puire, adj. pure; elegant, seemly (cf. Clene), V 330; utter, sheer, VIII a 111, IX 31, XIV c 13. [OFr. pur.] Pure(n), v. to purify, V 325, IX 45. [OFr. purer.] Purgatorie, n. Purgatory, VIII a 45. [L. Purgātōrium.] Purge, v. to purge out, IV b 77. [OFr. purg(i)er.] Purper, adj. purple, II 242. [OFr. purpre; cf. OE. purpuren.]
  • 61. Purpos(e), Pourpos, Porpos, n. intention, purpose, resolve, IV b 73, VI 148, VII 118, XII a 21, XIV b 39; put in a p., resolved, VII 112. [OFr. po(u)rpos.] Purpose(n), v. to intend, XI b 110. [OFr. po(u)rposer.] Purs, n. purse, XII b 157, 173, 182. [OE. purs.] Pursewe, Pursuen, Poursuie, v. to follow, pursue, IX 229. XII b 7; persecute, torment, IX 93; pursewe to, go eagerly to, XVI 316. [OFr. pursiwer, pursuer.] Purvaye, Purueye (to), v. to provide, prepare (for), XVI 69, XVII 553. [OFr. po(u)rveier.] Putte(n), Puit (XIV c), v.; Put(te), pa. t. and pp.; to thrust, IV b 3, 10, X 187, XVI 259, XVII 39; to put, set, VII 112 (see Purpos), VIII a 191, XII b 141, XIV c 12, XVII 21; to impose, XI a 64; putte awey, do away with, XI b 127; putten errour in, impute error to, XI b 77; put hom þerto, set themselves to the task, VII 33; putten hem into, put out on, IX 183; put vnto payn, set in torment, XVII 547; putte wryten, set in writing, IX 318. [OE. pū̆ tian, pȳtan, potian; see N.E.D.]
  • 62. Qu(h)-. See also Wh-. Qualitee, n. degree (of goodness), question of how good, IX 335. [OFr. qualité.] Quantytee, Quantité, n. limitation of greatness, question of how great, IX 336; capacity, quantity, X 26. [OFr. quantité.] Quarell, n. cross-bow bolt, IX 258. [OFr. quar(r)el.] Quaþ, Quath, pa. t. sg. quoth, said, II 127, VIII b 26, &c.; Quatȝ, VIII a 3; Quod, V 58, VI 61, &c. [OE. cwæþ.] Queer, n. choir, VIII b 63, XI b 172. [OFr. cuer.] Queynt, adj. skilful, elegant, II 299, 300 (see Pas); Koyntly, adv. cunningly, V 345. [OFr. cointe, queinte, &c.] Quelle, Qwell, v. to kill, destroy, IV a 92, V 41. [OE. cwellan.] Queme, adj. pleasant, V 41. [OE. cwēme.] Quen. See Whan(ne). Quen(e), Queen(e), n. queen, II 51, 71, VI 55, IX 190, XII a 195, &c. [OE. cwēn.] Querele, n. (legal) complaint, accusation, XII b 209. [OFr. querel(l)e.] Questioun, n. question, IX 178. [OFr. questioun.] Quhedirand, pres. p. whirling, or whirring, X 92. [Cf. Early ME. to-hwideren, -hwiðeren, whirl to pieces; OE. hwaþerian, make a rushing noise.] Quhelis, n. pl. wheels, X 17. [OE. hwē(o)l.] Quhen; Quhill. See Whan(ne), Whil. Quyk, adj. alive, V 41. [OE. cwic.] Quyte; Qwyte, Qwite (XVII); v. to pay, repay, V 176, 256, VI 235, XVII 216, 228; Quitte, pp. paid, VIII a 92. [OFr. quiter.] Quite, Quyte. See Whyyt. Quo(m); Quod. See Who; Quaþ. Qwake, v. to tremble, IV a 61. [OE. cwacian.]
  • 63. Qwart, n. health; mase in qwart, heals, IV a 15. [ON. kvirt, (neut. adj.) untroubled.] Qwiles. See Whiles. Race, Rase, n. headlong course, XVII 429; onslaught, violent blow, V 8. [ON. rás infl. by senses of related OE. rǣs.] Raȝt, Raid. See Reche; Ride. Rayle, v. to order, array, XV b 13. [OFr. reiller.] Rayn, v. to rain, XVII 147; Renys, pl. are raining down, XVII 351. [OE. regnian.] Rayn(e), n.1 rain, VII 109, 132, XVII 445; Reyn(e), I 162, XIII a 18. [OE. regn.] Rayne, n.2 rein, V 109. [OFr. raigne, rainne, &c.] Raysede, pp. uplifted, IV b 71. [ON. reisa.] Rake, n. path, V 76, 92. [OE. racu, water-course, or ON. rák, streak (Norw. dial. raak, path).] Ram-skyt, n. a term of abuse, XVII 217. [OE. ramm + ON. skita.] Ran(ne). See Ryn. Randoune, n.; in a randoune, with a rush, X 102. [OFr. en un randon.] Ranke, adj. brave, fine, VII 122. [OE. ranc.] Rape, v. refl. to hasten, VIII a 112, b 108. [ON. hrapa.] Rapely, adv. hastily; quickly, V 151; rashly, VI 3. [ON. hrapalliga.] Rapes; Rase. See Ropis; Race. Rather, adv. earlier, VIII a 112. [OE. hraþor.] Rathly, adv. quickly, XIV b 6. [OE. hræþ-līce.] Raton, n. rat, XV i 1, 9, 18. [OFr. raton.] Raþeled, pp. entwined, V 226. [See N.E.D. s.vv. Raddle, v.1 , Ratheled.]
  • 64. Raue, v. rave, talk foolishly, VI 3. [OFr. raver.] Ravyn, n. raven, XVII 479, 499. [OE. hræfn.] Rauysche, v. to carry off captive, carry away, IV a 16; Reuey<se>d, pp. II 82. [OFr. ravir, raviss-.] Rawe; Rawþe. See Rowe; Reuþe. Real, adj. royal, II 356. [OFr. real.] Reame, n. realm, kingdom, VIII b 78; Reume, XI a 25, 32, 52; Rem(e), VI 88, XIII b 47, 48; Roialme, IX 261. [OFr. re(i)alme, re(a)ume; later roialme.] Reasoune. See Reson. Rebalde, n. Rascal, XVI 99. [OFr. ribauld.] See Rybaudry. Rebuke, v. to rebuke, VI 7, VIII b 86. [ONFr. rebuk(i)er.] Receyue, v. to receive, take, VIII b 73; Res(s)ayue, V 8, XVI 390; Resceyued, pp. XI b 265. [OFr. receiv-re.] Reche, Recche, v.1 to reck, care, VIII a 114; me no reche, I care not (mixed pers. and impers. constr.), II 342. [OE. reccan.] Reche, v.2 to give, V 256; Raȝt, pa. t. V 229; Raȝteȝ, 2 sg. V 283. [OE. rǣcan, rǣ̆ hte, rā̆ hte.] Reches, n. sg. riches, IV b 61. [OFr. richesse.] Recorde, v. to ponder, go over in one's mind, IX 317; record, XII introd., b 111. [OFr. recorder.] Recoueren, v. to regain, IX 131. [OFr. recovrer.] See Keuer(e). Recuyell, n. compilation, VII introd. [OFr. recueil.] Red(e), adj. red, II 107, XIV b 41, XV e 19; red(e) gold, red gold, II 150, 362. [OE. rēad.] Red(e), n. advice, III 51 (dat.); counsel, plan, in can no other red, sees nothing else for it, XII b 102 (cf. Wane, n.). [OE. rǣd, rēd.] Red(e), Redyn, Reede, v. to advise, counsel, IV a 45, V 43 (note), VIII b 108, XIV c 97, XVII 341, &c.; to read, II 1, IV b 9, X introd., XII a 112, &c.; to read aloud, I 14; to reckon,
  • 65. VIII b 73; to think, XVII 427; hard red (inf.), heard read, XVII 46; Ret (OE. rǣ̆ tt, rē̆ t), 3 sg. pres. reads, III 3, 16; Rede, pp. read, XVI 317. [OE. rǣdan, rēdan, str., later wk.] Redere, n. reader, IX 321. [OE. rǣdere.] Redi, Redy, adj. prompt, ready (to hand), II 380, VI 231, X 34, XII b 119, XVI 394; al redy, prompt(ly), XVI 120; Redyly, adv. promptly, V 256. [Extended from OE. (ge-)rǣde.] Redresse, v. to redress, set right, XII b 206. [OFr. re-dresser.] Reformed (of), pp. changed back to his proper form (from), XII a 19. [OFr. reformer.] Refuseþ, pres. pl. reject, VIII b 82. [OFr. refuser.] Reghtewysnes, Reghtwysely. See Ryghtwyse. Regioun, n. region, IX 161, XII a 13. [OFr. regioun.] Regne, n. kingdom, VI 141. [OFr. regne.] Regni, Regne, v. to reign, II 425, IX 339. [OFr. regner.] Reherce, Reherse, v. to repeat, XI a 4, XII a 103; Rehercyng(e), n. recounting, IX 274, 279. [OFr. rehercer.] Reyll, n. reel, XVII 298 (see Garn). [OE. hrēol.] Reynand. See Ren. Reyny, adj. rainy, XII a 53. [OE. regnig.] See Rayn(e), n.1 Rele, v. to reel, behave wildly, sway (in combat); rele as vs likeȝ, let us fight as fiercely as we please, V 178. [Prob. related to Reyll.] Relece, v. to release, V 274. [OFr. relaissier, relesser.] Relees, Reles, n. release, discharge, VIII a 84, XVI 288, 290. [OFr. reles.] Releif, Releue, v. to relieve, give relief to, X 151, 161, XI b 255. [OFr. relever.] Religioun, n. religious rule, or order, VIII a 145. [OFr. religion.] Relikes, n. pl. heirlooms, precious things, VII 122. [OFr. relique.] Rem(e). See Reame.
  • 66. Remembraunce, n. recollection, VIII b 11. [OFr. remembra(u)nce.] Remene (to), v. to compare (to), interpret (as), XIV c 41. [? OFr. remener, bring back; senses seem due to assoc. with Mene, v.1 ] Remissioun, n. discharge, pardon, VIII a 84. [OFr. remissioun.] Remytte, v. to hand on, refer (for consideration), IX 296. [L. remittere.] Remnaunt, Remenaunte, n. remainder, V 274, 333, VIII a 94. [OFr. remenant.] Remorde, pp. afflicted, VI 4. [OFr. remord-re.] Remwe, v. to take away, VI 67. [OFr. remuer.] Ren, Renne, v. to run, XIV b 6; to flow, IX 179, XII a 84; ? Reynand, pres. p. XVII 111; see Ryn. [ON. renna.] Renys. See Rayn, v. Renk, n. knight, man, V 138 (see note), 178, 269. [OE. rinc.] Renne-aboute, Gad-about, Vagabond, VIII a 142. [From Ren.] Renoun, Renowne, n. renown, glorious name, in of renoun, renouns (pl. in Fr. constr., with ref. to several persons), I 248, II 202, XIV b 81. [OFr. renoun.] Rent, pp. torn, VII 147. [OE. rendan.] Rental, n. rent-book, VIII a 84 (see note). [OFr. rental.] Rentes, n. revenues from property, VIII b 77, XI b 96. [OFr. rente.] Reparde, pp. shut off, barred, VI 251. [OFr. re- + ME. parren.] Repe, v. to reap, VIII b 15. [OE. rī̆pan; on stem-vowel see N.E.D. s.v. Reap.] Repent(e), v. to repent, XVII 81, 91, 117. [OFr. repentir.] Repentance, n. repentance, XVII 56. [OFr. repentance.] Repereyue, n. head-reaper, harvest-overseer, VIII b 15. [OE. rip, harvest (or stem of prec.) + rēfa.] See Reue, n.
  • 67. Repleye, v. XVI 380 (see note). [Cf. OFr. repley(i)er, &c. or replevir; see N.E.D. s.vv. Repledge, Replevy, &c.] Reprené, v. to reprehend, find fault with, VI 184. [OFr. reprendre, preign-.] Repreue, Reprouen (of), v. to reprove (for), V 201, XI b 187. [OFr. repro(u)ver, repreuv-.] Reprufe, n. disgrace, XVII 84. [OFr. repro(u)ve.] Rerd, Rurde (V), n. loud voice V 269, XVII 230; noise, V 151 (see Rusche), XVII 101. [OE. réord.] Rert, pp. ? (aroused), ready, VI 231. [OE. rǣran.] Res(s)ayue, Resceyued. See Receyue. Rescowe, Rescoghe, n. rescue, V 240; matȝ rescoghe, ? comes to the rescue (cf. make reschewes, Morte Arthure 433), VI 250 (see note). [Stem of ME. rescouen, v., OFr. rescourre.] Resette, n. (place of) refuge, shelter, V 96. [OFr. recet.] Residue, n. residue, VIII a 94. [OFr. residu.] Reson, Resoun(e), Reasoune, n. reason, (good) sense, VIII a 311, XI a 30, 48, b 6, XII b 225, XVII 501, &c.; (personified) VIII b 5, &c.; what is reasonable, XVI 263; reasoning, XVI 255; argument, saying, XVI 337; by reson, as a logical consequence, XVII 81; motive, in by þat resoune, with that intent, XVI 248. [OFr. raison, re(i)son.] Resonabele, adj. reasonable, VI 163. [OFr. resonable.] See Vnresounable. Restay, v. to stop; intr. to pause, VI 77. [OFr. resteir; see N.E.D., s.v. Stay, v.] Restor(e), v. to restore, V 215, XVI 13, XVII 29; trwe mon trwe restore, let an honest man honestly restore (another's property), V 286. [OFr. restorer.] Ret. See Red(e), v. Reue, n. reeve, manager of an estate, VI 182, XI b 288. [OE. (ge-)rēfa.]
  • 68. Reue, v. to rob, steal, IV b 20; constr. with dat. pron. of person deprived, IV a 83, XV c 31. [OE. rēafian.] Reuey<se>d. See Rauysche. Reuel, v. revel, V 333. [OFr. reveler.] Reuerence, n. reverence; at þe r., out of respect, V 138; do a r., make an obeisance, XII b 128. [OFr. reverence.] Reuerse, v. to reverse, countermand, XI a 15. [OFr. reverser.] Reuest, pa. t. (refl.) vested, robed (himself), I 70. [OFr. revestir.] Reulis, n. pl. rules, XI b 203. [OFr. reule.] See Rewle. Reume. See Reame. Reuþe, Rawþe, n. (mental) pain, grief; hedde r. þerof, was grieved at that, III 20; r. to here, grievous to hear, V 136 (cf. Noy, Pine). [Extended with suffix -þ from OE. hrēow; cf. ON. hrygð.] See Rewe(ful). Reward(e), n. regard, consideration, in takeþ r. of (to), give a thought (to), XIV c 105-7; reward, VI 244, XII b 42. [ONFr. reward.] Rewardeþ, 3 sg. pres. gives reward, VIII b 32. [ONFr. rewarder.] Rew(e), v. to rue, regret, II 570, XVII 202; it shal him rewe, he shall rue it, XV a 23. [OE. hrēowan, pers. and impers.] Reweful, Ruful (V), adj. rueful; piteous, II 114; grievous, V 8. [OE. hrēow + full.] Rewle, v. to guide, XVII 429. [OFr. reuler.] See Reulis. Rybaudry, n. ribaldry, coarse jesting, II 9. [OFr. ribauderie.] See Rebalde. Ribbes, n. pl. ribs, IX 257. [OE. ribb.] Riche, Ryche, adj. of high rank, noble, II 326, 446, VIII b 26, XV g 18, &c.; wealthy, III 52, &c.; splendid, costly, rich, II 81, 161, 356, &c.; high (feast), V 333; quasi-sb. noble (steed),
  • 69. V 109; adv. (or predic. adj.) richly, II 362. [OE. rīce; OFr. riche.] Ryche, n. kingdom, VI 241. [OE. rīce.] See Heuenryche. Ryched, pp. directed, intended, V 138. [OE. reccan, but form prob. due to confusion with ME. richen, ruchen (OE. *ryccan), draw.] Richt, Rycht. See Right. Rydde, v. to separate (combatants), V 178. [Blend of OE. hreddan, rescue, and ON. ryðja, rid.] Ride, Ryde, v. to ride, II 340 (subj.), 347, V 39, 76 (note), &c., Raid, pa. t. sg. X 149; Rod(e); I 62, V 21, XV a 4; him rod, sailed, XIV c 61; Riden, pl. II 308; Ryden, pp. gone on military service (as knights), VIII b 78. [OE. rīdan.] Rifild, pp. despoiled, XIV a 16, 17. [OFr. rifler.] Rife, adj. plentiful, VII 122. [Late OE. rȳfe, *rīfe.] Ryfis. See Ryue. Rigge, n. back, II 500; Rugge, XV g 4. [OE. hrycg.] Right, Ryght, Rihte (XII), adj. right, proper, true, XII a 124, XVI 255, XVII 471, &c.; right (hand), IX 70. [OE. riht.] Right, Ryght, Riȝt(e), Ryȝt, Riht (XII, XIV c); Richt, Rycht (X); adv. straight, right, II 100, 186, V 94, &c.; ful riȝt, straight (away), II 85, 191; ryght vprise (cf. Vpperight), rise up, XVI 31; correctly, XVII 139; exactly, just, right, I 94, II 166, V 236, IX 64, X introd., 102, XII a 146, XVII 513, &c.; richt evin, just, X 93; (with neg.) at all, VI 160, VIII a 145, b 86, XVII 524, &c.; very, IX 150, X 138, XIV c 10, &c. [OE. rihte.] Right, Ryght, Ryȝt, n. right, XIV b 37; justice, V 278, VI 136, 231; just cause, VIII b 78; by þe way of ryȝt to aske dome, if they demand an award acc. to strict justice, VI 220; Ryȝtes, Riȝttis, pl. duties, XI b 203; obligations, V 274. [OE. riht.] Right, pa. t. corrected, VII 69. [OE. rihtan.]
  • 70. Rightfull, adj. just, IX 82; Riȝtfulleste, superl. XI b 193. [OE. (late) riht-ful.] Ryghtfulnesse, n. Justice, VIII b 32. [From prec.] Ryghtwyse, adj. righteous, IV b 7; Reghtwysely, adv. righteously, IV b 55; Reghtewysnes, n. righteousness, IV b 80. [OE. rihtwīs (rehtwīs), -līce, -nes.] Riȝtes; al to riȝtes, quite correctly, fittingly, II 136; to his riȝtes, as he should be, fittingly, II 292. [Extension of to riȝt, according to what is right (see Right, n.), with adv. -es.] Ryme, n. riming poem, I introd.; Rymys, pl. (trivial) popular poems, I 14; Ryme couwee, see Couwee. [OFr. rime.] Ryn, v. to run, flow, pass swiftly, X 17, XVII 101, 277, 305, 357; Ran(ne), pa. t. I 155, IV a 9 (note), X 107; Runne, pp. in be runne, may have mounted up, VI 163. [OE. rinnan.] See Eorne, Ren(ne). Rinde, n. bark, II 260. [OE. rínd.] Ryne, v. to touch, V 222 (see note). [OE. hrīnan.] Rynge, v. to ring, resound, XV b 12; Ronge, pa. t. V 136; Ry<n>kande, pres. p. V 269 (confus. of ng, nk, freq. in this poem). [OE. hríngan, wk.] Ryot, n. strife, violence, IX 83. [OFr. riot(e).] Rype, Ripe, adj. ripe, VIII a 289, IX 140. [OE. rīpe.] Ris, n. leafy spray, II 305. [OE. hrīs.] Rise, Ryse, v. to rise, IV a 62, V 17, XVI 394, &c.; Ros, pa. t. sg. VI 77, 146, 159; Ryse, pl. I 208; Rysen, pp. XVII 442; Rysing, n. resurrection, XVI 317. [OE. ā-rīsan.] Ryste, n. repose, rest, IV b 10; Rest(e), II 74, IV a 3, &c. [OE. rest; on y-form see N.E.D. s.v. Rest.] Ryste, Rest(e), v. to rest; intr. IV b 42, V 263; refl. IV b 38, IX 20. [OE. restan; see prec.] Ryue, v. to tear (asunder), cleave, V 222 (note); Ryfis, 3 sg. pres. intr. is torn, XVII 399; Roue, pa. t. V 278; Ryue, pp. I 121. [ON. rīfa.]
  • 71. Riueling, n. a rough shoe (as nickname for a Scot), XIV a 19. [OE. rifeling.] Riuer(e), Ryuer(e), n. river, II 160, 308, IX 12, XII a 85, XIII a 16, &c. [OFr. rivere.] Ro, n. peace, XVII 237. [OE. rōw, ON. rō.] Robbe, v. to rob; Yrobbed, pp. III 18; Robbing, n. XIV b 6. [OFr. rob(b)er.] Robbere, n. robber, XIV a 6. [From prec.; OFr. robbour.] Robe, n. robe, II 81. [OFr. robe.] Roc, Rokke, n. rock, V 76, 130, XV g 12. [Cf. OE. gloss stānrocc, scopulus; OFr. ro(c)que.] Roche, n. rock, II 347, V 131, IX 33, 62, &c.; Rooch(e), XIII a 21, 22. [OFr. roche.] Roché, adj. rocky, V 226. [From prec.] Rod(e). See Ride. Rode, n.1 rood, cross, VIII a 94, XIV c 73. [OE. rōd.] Rode, n.2 rosy hue, fair face, II 107, XV b 13. [OE. rudu.] Rof, adj. rough; grievous (with sore), or ? n. gash, V 278 (note). [(i) As next with alteration of final spirant (cf. Þof), though this is not the usual form of 'rough' in this text. (ii) Related to Ryue, v.] Roȝ(e), adj. rough, rugged, V 94, 109, 130; Rouh, XIV c 37; Rowe, II 265, 459 (see Blac); Ruȝe, V 98. [OE. rūh, rūg-, rūw-.] Roialme. See Reame. Royis, 2 sg. pres. talkest folly, XVI 99. [Unknown.] Rok, n. distaff, XVII 338. [Cf. ON. rokk-r, MDu., MLG. rocke(n).] Rokke. See Roc. Romayn, n. a Roman, VII 69. [OFr. romain.] Romance, n. (French) romance, story, XIV b heading. [OFr. romanz.]
  • 72. Rome, v. to wander, make one's way, V 130, VIII b 11. [ME. forms point to OE. *rāmian.] Rooch(es). See Roche. Rooris, 2 sg. pres. roarest, XVI 99. [OE. rārian.] Rooþur. See Roþur. Ropis, Rapes, n. pl. ropes, VII 147, XIV b 68. [OE. rāp.] Ros. See Rise. Rose, n. rose, XV b 13, e 19. [OE. rose from L. rosa.] Rote, n.1 root, V 226, VI 60 (origin), VIII a 97, XIV c 82; Rote, pl. (or collect. sg.), II 256, 260. [ON. rōt.] Rote, n.2 way, in bi rote, on the way, V 139. [OFr. rote.] Roted, pa. t. rotted, I 236. [OE. rotian.] Roþur, Rooþur, n. rudder, XIV c 25, 29, 36, 57. [OE. rōþor.] Roue; Rouh. See Ryue; Roȝ(e). Roun(e), n. speech, voice, XV b 2, 29 (see note), c 36; [OE. rūn.] Round, adj. round; adv. in al aboute round (as prep.) round, XII a 79; Roundnesse, n. roundness, IX 67. [OFr. roönd, round.] Rout(e), n.1 host, company, (great) number, II 283, X 176, XII b 118, XIV a 16; on a route, in a mass, tumultuously, XVII 305. [OFr. route.] Rout, n.2 roar, loud noise, X 92. [Stem of OE. hrūtan, or ON. rauta; see Rowtyn.] Rouwed, pa. t. rowed, XIV c 61. [OE. rōwan, str.] Rowe, Rawe, n. row, VI 185; be rowe (rawe), on rawe, in (due) order, in turn, XV h 15, XVI 317, 401. [OE. rāw.] Rowe. See Roȝ(e). Rowtyn, pres. pl. they crash, beat, XV h 15. [OE. hrūtan; but see N.E.D. for various sources and senses of Rout, n. and v.]
  • 73. Rude-evyn, n. eve of the feast of the (Exaltation of the) Cross, X 42. [OE. rōd + ǣfen.] See Rode, n.1 Ruful. See Reweful. Rugge; Ruȝe. See Rigge; Roȝ(e). Rugh-fute, n. rough-footed, XIV a 19. [OE. rūh + fōt.] See Roȝ(e), Fote. Ruysand, pres. p. glorifying, in r. hyme of, glorying in, taking credit to himself for, IV b 80. [ON. hrósa sér.] Runne; Rurde. See Ryn; Rerd. Rusche, v. to rush; make a loud rushing noise, V 136; rusched on þat rurde, ? went on with that rushing noise, V 151. [Echoic, but app. based on OFr. r(e)usser, AFr. russ(h)er.] Sa, Saat. See So; Sitte(n). Sacramente, n. sacrament, XVI 316. [L. sacrāmentum.] Sacrifise, -ice, n. sacrifice, XI b 202, XII a 15, 40. [OFr. sacrifice.] Sacrylage, n. sacrilege, I 4, 19. [OFr. sacrilege, infl. by suffix - age.] Sad(de), adj. steadfast, IX 92; heavy, grievous, XVI 44; sette hym sadde, give him sorrow, XVI 204; Sadly, adv. sufficiently, long enough, V 341. [OE. sæd, sated, wearied; ME. shows also senses 'heavy, firm', &c.] Sadel, n. saddle, V 42. [OE. sadol.] Saf(e), see Saue; Sagh, see Se(n); Say, Sai-, see Se(n), Sei(e). Saye, v. to make trial of, explore, XIV c 34. [Shortened from Assaie.] Sayf. See Saue, prep. Sayl(l), Sail, n. sail, VII 125, XIV c 50, XVII 153, 271, &c. [OE. segl.] See Seile. Sayn, Saytz, see Sei(e); Saynte, see Seynte.
  • 74. Sake, n. in for ... sake (with interven. gen. or poss. adj.), (i) for (one's) sake, VIII a 96, XII introd.; (ii) on (one's) account, XV c 23; (with loss of prec. inflexion) I 177, XVII 88 (note). [OE. sacu; cf. ON. fyrir sakir because of.] Sakke, n. sack, VIII a 9. [OE. sacc.] Sakles, adj. innocent (i.e. against whom you had no just quarrel), XIV a 3. [OE. sac-lēas, from ON. sak-lauss.] Sale, n. in to the sale, for sale, XII b 148. [OE. *salu, (once) sala.] Sal(l), Saltou. See Schal. Salt(e), adj. salt, VIII a 279, IX 13, XII a 166, &c.; n. XIII a 30. [OE. salt, adj. and n.] Salvacioun, n. salvation, IX 333. [OFr. salvacioun.] Sam(e), Samen, Somyn (VII), adv. together, VII 66, XVI 170, 239, XVII 316; brether sam, brothers both, XVII 320; al samen, all sam (togeder), (all) together, XVII 292, 530; with one accord, VI 158; see Alsaume. [OE. æt samne, somne; (late) somen; cf. ON. allir saman.] Same, adj. same I 188, &c.; pron. in þe (þis) same, the very one (or thing), XII b 78, XVI 56, 71, &c. [ON. sam-r.] Samon, n. salmon, XIII a 64. [OFr. saumon.] Sample, n. illustration, parable, VI 139. [Shortened from OFr. essample.] See Ensample. Sand, n. sand, shore; bi see and bi sand, everywhere, XVII 75. [OE. sánd.] Sang, Santis. See Song(e), Seynte. Sap, n. sap, XIV c 90. [OE. sæp.] Saphire, n. sapphire, IX 115, 116 (see Loupe), 122. [OFr. safir.] Sapience, n. Wisdom; personif. of the 'sapiential' books (Proverbs, Ecclesiastes, Canticles, Wisdom, Ecclesiasticus), VIII a 231 (the ref. is to Prov. xx. 4). [L. sapientia.] Sare. See Sore.
  • 75. Sarri, adj. ? vigorous, XIV c 90. [OFr. serré; see note.] Sarteyne; Sat. See Certeyne; Sitte(n). Sauce, n. sauce, VIII a 259. [OFr. sauce.] Saue, Saf, adj. safe; a saue, have safe, save, I 127 (see Habben); vochen saf, VIII b 51, see Vouche-saf. [OFr. sauf, sauve (fem.).] Saue, Saf, Sayf (XVII), prep. save, except, IX 174, 228, XVII 106; saue þat (conj.), V 161. [OFr. sauf.] Saue, Safe (XVII), v. to preserve, keep safe, V 5 (subj.), 71, XV i 19, XVII 309, 517, &c.; rescue, bring to salvation, XI a 38, b 305, XVI 108, &c. Sauynge, n. preservation, XI b 304. [OFr. sa(u)ver.] Saufly, adv. safely, XII b 174. [From Saue, adj.] Saugh. See Se(n). Saul(e), Saull, Sawl(e), Soule, n. soul, IV a 24, 32, 61, VIII a 81, XVI 272, XVII 390, &c.; distrib. sg. (see Herte), XI b 250; Soule, gen. sg. I 212. [OE. sāwol.] Sauour (to), n. savour, IX 153; relish (for), XI b 254. [OFr. savour.] Sauoure, v. to give a savour to, VIII a 259. [OFr. savourer.] Sauter, Sawter, n. the Psalter, Book of Psalms, VI 233, VIII a 246, b 49, XVI 187. [OFr. saut(i)er.] Sawe, n. saying; aftir þi sawe, according to thy word, XVI 397; proverb, XVI 281. [OE. sagu.] Saw(e). See Se(n). Sawte, n. assault, VII 57, 85. [Shortened from OFr. as(s)aut.] Saxon, adj. Saxon, XIII b 49; Saxonlych, adv. in the Saxon fashion, XIII b 8. [OFr. saxon.] Scaffatis, n. pl. scaffoldings, temporary wooden structures for assailing walls, X 9. [Cf. OFr. escadafaut, eschaffaut.] Scarslych, adv. scantily, scarcely, XIII b 50. [From ONFr. escars.]
  • 76. Scaþe, Skathe, n. damage, injury, V 285, XV i 13. [ON. skaði.] Scere, adj. bright, pure, in Scere Þorsday, Sheer, Holy, or Maundy, Thursday, XV g 1. [OE. *scǣre, rel. to scīr; cf. ON. skǽr-r, skír-r, and ON. Skíri-Þórsdagr, OSwed. Skær(a)- Þorsdagher.] See Schyre, Skyre. Schadewe (aȝen), v. to screen (from), IX 19. [OE. sceadwian.] Schaft, n. handle, V 264. [OE. sceaft.] Schaȝe, n. shaw, small wood, V 93 (see Side). [OE. scaga.] Schakeled, pp. shackled; protected with greaves, XV h 12. [OE. sceacul, fetter.] Schal, Schall(e), Shal(l), Sal(l), v. auxil. 1 and 3 sg. pres. am (is) to, must, shall, will, I 22, II 172, 207, IV a 7, 79, IX 69, XIV a 34, XV a 10, XVI 15, XVII 164, &c.; 2 sg. Sal(l), IV a 17, 40; Schal(l), Shal(l), V 79, XVI 299, XVII 121, 381, &c.; Schalt(e), Shalt, I 206, II 130, VI 204, &c.; (with suffixed pron.) Saltou, XIV a 23; Shaltow, VIII a 223; pl. Sal(l), IV a 62, XIV b 18, &c.; Schal, Schall(e), V 332, XVI 49, 192, &c.; Schyn, V 333; Scholle, XIII b 39; Schull, Schulle(n), Shul(en), I 38, VIII a 140, IX 63, 210, XI a 9, b 82, &c. Pa. t. (ind. and subj.), was going to, ought to, was (were) to, should, would; Schold(e), Shold(e), II 467, VIII a 36, b 67, 80, IX 89, XII a 111, &c.; Schuld(e), Shuld(e), I 50, 69, 106, II 44, 190, V 16, XI a 21, &c.; Ssolde, III 7; Suld(e), IV a 91, b 19, X 12, &c.; 2 sg. Schulde, XVI 241; Schust, II 420, 570, &c. Note ellipse of a foll. verb, as 'have', XVII 227; freq. 'go', 'come', II 130, IV a 91, V 16, 332. Which slepe schal, that may (at any time) sleep, XII a 117; when it schuld be, whenever it was, II 370. [OE. sceal; sculon, scylon; scólde, &c.] Schalk, Shalke, n. man, V 200, 304, VII 72, 89. [OE. scealc, servant, (in verse) man.] Scham(e), Schome (V), Shame, n. shame, XIV c 13; disgrace, XII b 224; disgraceful thing, V 304; ignominy, disaster, harm,
  • 77. XIV a 12, b 84, XV i 18, XVII 301; pl. shameful things, I 2. [OE. scamu, scomu.] Schamfully, adv. ignominiously, IV a 66. [OE. scamful-līce.] Schank(e), n. leg (below the knee), XV h 12. [OE. scanca.] Schapellis. See Chapel(le). Schap(e), Schappe, Shappe, v.; Schop, Shope, pa. t. V 260, VII 72; Schaped, pp. V 272; Schape(n), XII a 130, 169, &c.; Yschape, XIII a 45. Trans. to fashion, make, V *261, 272, VII 72, VIII b 18, IX 107; to turn (into), XII a 169, XIII a 45; to contrive, bring (it) about, V 70, XII a 130; ordain, appoint, V 260; schappe ȝou to, appoint for yourselves, XIV d 7; refl. in shappis hym, designs, intends, XVI 155; intr. to prepare, be about (to), X 14. [OE. sceppan, scōp, ge- scapen.] See Forschape. Schapp, n. shape, IX 248. [OE. ge-sceap.] Scharp(e), Sharp(e), adj. keen, sharp, harsh, bitter, severe, II 38, 539, V 199, XI b 142, XIII b 59, XIV c 21, 33, XVII 350, 356, &c.; as sb., the sharp blade, V 245, 264. [OE. scearp.] Schaterande, pres. p. intr. dashing, splashing, V 15. [OE. *scaterian; cf. MDu. scheteren.] Schaued, pa. t. shaved, II 585. [OE. scafan, str.] Schawys. See Schewe(n). Sche, pron. fem. sg. she, II 75, 77, 323, &c.; She, I 48, &c.; Scho, IV b 1, 2, 4, 6, &c.; ref. to inanimate thing (gyne), X 80. For obl. cases, &c., see Hi, fem. [See N.E.D. s.v. She.] Schede, v. to spill; intr. fall, VI 51 (cf. Pearl 10); Shedyng, n. spilling, VIII a 9. [OE. scādan, scēadan.] Scheep, Shep, n. pl. sheep, VIII b 18, IX 238. [OE. scē(a)p.] See Schep. Schelde, n. shield, V 250. [OE. scéld.] Scheltrom, n. rank of armed men, II 187. [OE. sceld-truma.] Schene, Shene (VII), Schine (II), adj. fair, goodly, VII 89, 120, 151, 157; bright, II 358, V 246; as sb., bright blade, V 200.
  • 78. Welcome to our website – the perfect destination for book lovers and knowledge seekers. We believe that every book holds a new world, offering opportunities for learning, discovery, and personal growth. That’s why we are dedicated to bringing you a diverse collection of books, ranging from classic literature and specialized publications to self-development guides and children's books. More than just a book-buying platform, we strive to be a bridge connecting you with timeless cultural and intellectual values. With an elegant, user-friendly interface and a smart search system, you can quickly find the books that best suit your interests. Additionally, our special promotions and home delivery services help you save time and fully enjoy the joy of reading. Join us on a journey of knowledge exploration, passion nurturing, and personal growth every day! ebookbell.com