Jdk 14 Tutorial G Travis download

https://ebookbell.com/product/jdk-14-tutorial-g-travis-4114252

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.

Jdk 14 Tutorial 1 No Book Cover Gregory Travis

https://ebookbell.com/product/jdk-14-tutorial-1-no-book-cover-gregory-
travis-5470696

Logging In Java With The Jdk 14 Logging Api And Apache Log4j Samudra
Gupta Auth

https://ebookbell.com/product/logging-in-java-with-the-jdk-14-logging-
api-and-apache-log4j-samudra-gupta-auth-11854038

Logging In Java With The Jdk 14 Logging Api And Apache Log4j 1st
Edition Samudra Gupta

https://ebookbell.com/product/logging-in-java-with-the-jdk-14-logging-
api-and-apache-log4j-1st-edition-samudra-gupta-922752

Professional Java Jdk 6 Edition W Clay Richardson Donald Avondolio

https://ebookbell.com/product/professional-java-jdk-6-edition-w-clay-
richardson-donald-avondolio-5473692
Professional Java Jdk 6 Edition 6th Ed W Clay Richardson Donald
Avondolio

https://ebookbell.com/product/professional-java-jdk-6-edition-6th-ed-
w-clay-richardson-donald-avondolio-4106356

Professional Java Programming Jdk 5 5th Edition W Clay Richardson

https://ebookbell.com/product/professional-java-programming-jdk-5-5th-
edition-w-clay-richardson-981632

Ivor Hortons Beginning Java 2 Jdk 5 Edition 1st Edition Ivor Horton

https://ebookbell.com/product/ivor-hortons-beginning-
java-2-jdk-5-edition-1st-edition-ivor-horton-2391088

Mastering Java 11 Develop Modular And Secure Java Applications Using

Concurrency And Advanced Jdk Libraries 2nd Edition Lavieri

https://ebookbell.com/product/mastering-java-11-develop-modular-and-
secure-java-applications-using-concurrency-and-advanced-jdk-
libraries-2nd-edition-lavieri-55588330
jdk.book Page i Monday, March 11, 2002 3:38 PM

JDK 1.4 Tutorial

jdk.book Page ii Monday, March 11, 2002 3:38 PM
jdk.book Page iii Monday, March 11, 2002 3:38 PM

JDK 1.4 Tutorial

GREG M. TRAVIS

MANNING
Greenwich
(74° w. long.)
jdk.book Page iv Monday, March 11, 2002 3:38 PM

For electronic information and ordering of this and other Manning books,
go to www.manning.com. The publisher offers discounts on this book
when ordered in quantity. For more information, please contact:
Special Sales Department
Manning Publications Co.
209 Bruce Park Avenue Fax: (203) 661-9018
Greenwich, CT 06830 email: orders@manning.com
©2002 by Manning Publications Co. All rights reserved.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted,

in any form or by means electronic, mechanical, photocopying, or otherwise, without
prior written permission of the publisher.

Many of the designations used by manufacturers and sellers to distinguish their products
are claimed as trademarks. Where those designations appear in the book, and Manning
Publications was aware of a trademark claim, the designations have been printed in initial
caps or all caps.

Recognizing the importance of preserving what has been written, it is Manning’s policy to have
the books they publish printed on acid-free paper, and we exert our best efforts to that end.

Library of Congress Cataloging-in-Publication Data

Travis, Greg
Book Title /Bill J. Author.
p. cm.
Includes bibliographical references and index.
ISBN ?-??????-??-? (alk. paper)
1. Java (Computer program language). 2. Title.
????????????? 1998
?????????—???? ??-?????
CIP

Manning Publications Co. Copyeditor: Andy Carroll

209 Bruce Park Avenue Typesetter: Tony Roberts
Greenwich, CT 06830 Cover designer: Leslie Haimes

ISBN 1-930110-66-9

Printed in the United States of America

1 2 3 4 5 6 7 8 9 10 – VHG – 05 04 03 02
jdk.book Page v Monday, March 11, 2002 3:38 PM

To Susan
jdk.book Page vi Monday, March 11, 2002 3:38 PM
jdk.book Page vii Monday, March 11, 2002 3:38 PM

contents
preface xv
acknowledgments xvii
about this book xix
author online xxvii
about the cover illustration xxix

1 Basic NIO (New Input/Output)

1.1 Doing I/O with channels and buffers 2
1

Getting a channel from a stream 3 Creating a buffer

■

revision 4 Reading from a channel 4 Writing to a

■ ■

channel 5 Reading and writing together 6

■

1.2 Understanding buffers 7

Creating buffers 7 get() and put() 7 Buffer state values 9
■ ■

flip() and clear() 10 slice() and subbuffers 12 Buffers of

■ ■

other types 13 Reading and writing other types from a

■

ByteBuffer 14 Direct buffers 16 Example: TCP/IP

■ ■

forwarding 17 Doing I/O with channels and buffers 27

■

1.3 The File Locking facility 28

Types of locks 28 Using locks 29 Acquiring locks 30
■ ■

Portability issues 31 Example: a simple database 32

■

1.4 Summary 36

vii
jdk.book Page viii Monday, March 11, 2002 3:38 PM

viii CONTENTS

2 Advanced NIO (New Input/Output) 37

2.1 Reading and writing with MappedByteBuffers 38
Advantages of MappedByteBuffers 38 Disadvantages of ■

MappedByteBuffers 40 Using MappedByteBuffers 40

■

Example: checksumming 41
2.2 Nonblocking I/O 42
The multithreaded approach 43 The really bad single-
■

threaded approach 44 Polling 44 Example: a polling chat

■ ■

server 46 Multiplexing with select() 49

■

2.3 Encoding and decoding with Charsets 58

Decoding and encoding 59 Finding available Charsets 59
■

Using encoders and decoders 61

2.4 Network interfaces 63
When to use a network interface 64 Getting a list of ■

NetworkInterfaces 64 Reporting on NetworkInterfaces 64

■

Getting a list of InetAddresses 66 Getting a ■

NetworkInterface by InetAddress 66 Getting a ■

NetworkInterface by name 67 Listening on a■

particular address 67
2.5 Summary 73

3 Java2D
3.1
75
The Print Service API 76
Print Service packages 76 Document flavors 77 Printer
■ ■

discovery 77 Printer attributes 79 The SimpleDoc class 80

■ ■

The DocPrintJob interface 81 Example: printing an

■

image 81 Example: a custom print dialog box 83

■

3.2 Reading and writing images with the Image I/O API 88
The plug-in model 89 Simple reading 89 Simple
■ ■

writing 90 The ImageIO class 90 Discovering available

■ ■

formats 90 Example: reading and displaying an image 92

■

Example: writing an image 92 The ImageReader class 93

■

The ImageWriter class 95 Customizing the reading

■

process 97 Listeners 99 Example: generating a graph 102

■ ■
jdk.book Page ix Monday, March 11, 2002 3:38 PM

CONTENTS ix

3.3 Summary 105

4 Java Web Start (JAWS)

4.1
107
Understanding the JAWS execution model 108
Client, server, and application 109 The sandbox 110
■

Consider the possibilities 110

4.2 Building and deploying a JAWS application 111
JAR files 111 The JNLP file 111
■

Configuring the web server 113

4.3 Using the sandbox: services 113
Using the sandbox: resources 114
4.4 Bypassing the sandbox 115
4.5 Example: a simple drawing program 117
PicoDraw.java 118 DrawCanvas.java 131
■

TransferableImage.java 135
4.6 Summary 136

5 Logging
5.1
137
Logging overview 138
Log message format 139 Logging levels 139 Logger
■ ■

names and the logger hierarchy 140 Logging methods 141

■

The LogRecord class 141 Handlers 142 Filters 143

■ ■

Formatters 143 Logging efficiency 144

■

The philosophy of logging 144

5.2 Configuring the Logging system 145
Configuring handlers 145 Configuration values for
■

standard handlers 146 Configuring loggers 148

■

Global handlers 149

5.3 Using logging in a program 149
5.4 Writing a custom handler 155
5.5 Writing a custom formatter 165
5.6 Summary 168
jdk.book Page x Monday, March 11, 2002 3:38 PM

x CONTENTS

6 Assertion facility
6.1
171
Assertion basics 172
Why use assertions? 172 Assertions vs. other error code 173
■

Designing by contract 174

6.2 Working with assertions 174
Assertion syntax 175 Compiling with assertions 177
■

Controlling assertions from the command line 178

Controlling assertions programmatically 181 Removing
■

assertions completely 182 Determining if assertions are

■

enabled 183 Catching an assertion failure 184

■

Assertions and class initialization 185

6.3 Assertion examples 187
Avoiding inconsistent states 187 Narrowing the range
■

of states 189 Ensuring consistency between container

■

objects and contained objects 189 More complicated

■

consistency checks 192

6.4 Knowing when to use assertions 193
Rules of use 193 What to check for 197
■

Miscellaneous rules 202

6.5 Summary 204

7 Exceptions
7.1
205
Chained exceptions 206
7.2 StackTraceElements 208
What is a stack trace? 208 Using StackTraceElements 210
■

Writing a custom stack trace dumper 210

Synthesizing a stack trace 215
7.3 Summary 228
jdk.book Page xi Monday, March 11, 2002 3:38 PM

CONTENTS xi

8 Collections 229
8.1 Utilities 230
Rotating list elements 230 Replacing list elements 232
■

Finding sublists within lists 232 Swapping list elements 233

■

Converting enumerations to lists 233

8.2 LinkedHashMap and LinkedHashSet 235
Using LinkedHashMap 235 Using LinkedHashSet 238
■

Efficiency of LinkedHashMap and LinkedHashSet 240

Example: searching a file path 241
8.3 IdentityHashMap 246
Object equality 246 Hashing and equality 247
■

Example: using the IdentityHashMap 247

8.4 The RandomAccess interface 252
8.5 Summary 255

9 Regular Expressions
9.1
257
Overview of regular expressions 258
Literals 259 The . wildcard 259 Quantifiers: * and + 259
■ ■

Grouping with () 260 Character classes 260 Predefined

■ ■

character classes 261 Sequencing and alternation 263

■

Boundary matchers 263 Reluctant (non-greedy)

■

matching 264 Other features 265

■

9.2 Pattern and Matcher 265

Capturing groups 267 Find and replace 268 Flags 269
■ ■

9.3 Transitioning from Perl to Java 270

Finding the longest word in a line 270 Parsing a tab- ■

delimited file 273 A command-line processor 276

■

Parsing and modifying names 280

9.4 Example: HTML templating system 285
9.5 Example: a lexical analyzer 288
9.6 Summary 296
jdk.book Page xii Monday, March 11, 2002 3:38 PM

xii CONTENTS

10 The Preferences API

10.1
297
What the Preferences API is for 298
Simple Preferences API example 298 Appropriate ■

applications of the Preferences API 299 Design goals ■

of the Preferences API 301

10.2 Knowing when to use the Preferences API 304
Comparison with java.util.Properties 304
Comparison with JNDI 305
10.3 Understanding the data hierarchy 305
Tree-like structure 305 Key/value pairs 305 System vs.
■ ■

user 306 Definition of a user 306 Pathnames 307

■ ■

Per-package subtrees 308

10.4 Using the API 308
Traversing the data hierarchy 308 Reading and writing
■

values 311 Allowable types 311 Allowable keys 312

■ ■

Allowable values 312 Allowable node names 313

■

Default values 313 Removing values 314 Iterating through

■ ■

the values in a node 314 Distinguishing between user and

■

system nodes 314 Node names and paths 315 Getting

■ ■

parent and child nodes 316 Determining the presence of

■

nodes 316 Removing nodes 317 Flushing 318

■ ■

Syncing 318 Example: storing GUI configuration 319

■

10.5 Change listeners 324

Preference change listeners 325 Node change listeners 325
■

Example: listening for a GUI change request 326

Example: changing server ports on the fly 329
10.6 Stored defaults 335
10.7 Importing and exporting 335
10.8 Summary 337
jdk.book Page xiii Monday, March 11, 2002 3:38 PM

CONTENTS xiii

11 The Java Secure Socket Extension (JSSE) 339

11.1 Cryptographic terminology 340
11.2 SSL—the Secure Sockets Layer 342
Components of the default implementation 342
SSL handshaking 343
11.3 Managing keys 343
Creating keys with keytool 344 Store keys in a KeyStore 344
■

Creating a KeyManagerFactory 344 Creating a

■

TrustManagerFactory 345 Creating an SSLContext 345

■

11.4 Example: a trivial secure web server 346

The authentication model 346 Generating the key 347
■

The configuration file 348 The code 349

■

11.5 Example: a secure credit card authorization system 359

The authentication model 359 Generating the keys 360
■

The code 362

11.6 Summary 370

index 371
jdk.book Page xiv Monday, March 11, 2002 3:38 PM
jdk.book Page xv Monday, March 11, 2002 3:38 PM

preface
In the summer of 1995, I moved to New York City to work at a web start-up.
On my first day of work, I saw Netscape for the first time; by the end of the day,
I had written my first applet, a trivial graphics program I called Thingy.
Thingy just drew a bunch of lines from
the cursor to the edge of the screen. You
moved the cursor, and the vortex moved
along with it. Interactive! I announced the
creation of Thingy at the company meeting,
and, to my surprise, everyone cheered. I had
no idea what the big deal was. I had never
used the web before that day, and I didn’t
know why it was exciting, or why it was bor-
ing enough that a program like this could
enliven it. Apparently, being able to run a
program inside a browser was a big deal. A
very big deal.
For a while, that was what Java was all about—putting moving images inside
pages in a fairly static medium. Java competed against other enlivening technolo-
gies, trading moderate complexity for generality, and becoming a very hot
resume item in the process.
However, our start-up had realized at an early point that Java wasn’t just for
the client side. Java was also an excellent server-side language—an application

xv
jdk.book Page xvi Monday, March 11, 2002 3:38 PM

xvi PREFACE

language. For all its flaws, Java seemed to be exceedingly well designed. It felt a
lot like C++, but less. I had come close to being a C++ evangelist at my previous
job, but even I had to admit that I got a headache every time I tried to write C++
code. Java, on the other hand, almost never gave me a headache. On the con-
trary—it was eerily fun.
We heard that the designers (James Gosling and his team) had used a simple
design rule: if you don’t know how to do something really nicely, leave it out. What
an excellent rule! Play to your strengths. Why do lots of things badly when you
can do a few things nicely? Quality isn’t just including good stuff; it’s also know-
ing when to cut the bad stuff.
Java benefited from the fact that it ran in a place where no programs had run
before—inside the browser window. The novelty of this made up for the fact that
it was slow and used a lot of memory. It didn’t allow for the time and space opti-
mizations that C and C++ allowed. But that was okay—it was a different class of
language. It occupied a special niche, one that had been sought by other truly
high-level languages with commercial pretensions, such as SmallTalk and Eiffel.
And so Java thrived. Easy to use, portable (except maybe the GUI stuff), good
for beginners and experts alike. It became a very famous language. Relatives of
mine who had never touched a computer asked me if I knew Java and were
pleased when I said that I did. Eat your heart out, SmallTalk! Take that, Eiffel!
Once Java was firmly ensconced in the canon of programming languages, its
designers increasingly turned their attention to speed. It had gained popularity
because of its simplicity, and that simplicity had brought a certain amount of
sluggishness; now it was time to make up for that.
The last few versions of the JDK have focused on making Java more complete,
faster, and—let’s not be shy—less simple. The simple stuff is still there, but more
sophisticated elements are falling into place. They might be harder to use, but it’s
worth it if they improve performance. Java always had a nice learning curve, and
the curve has retained its gentle slope. You can start with the basics and move on
to the more complex stuff when your projects demand it.
JDK 1.4 is another step on this path. It includes a variety of new features,
some of which have been available in prototype form, but all of which are now
firmly part of the Java platform. These features are not yet available in most
browsers, but if you use Java for true application development, you’ll want to
learn how to use them right away.
jdk.book Page xvii Monday, March 11, 2002 3:38 PM

acknowledgments
This is my first book. Not surprisingly, it was a lot harder than I thought it would
be, even though I had thought I was prepared for it to be harder than I thought
it would be. However, I was fortunate to be surrounded by the extreme compe-
tence of the folks at Manning Publications. Many thanks to Marjan Bace, the
publisher, for approving the book and helping to define its goals; similarly, hearty
thanks to my first contact at Manning, Dan Barthel, for his help both during and
after his formal association with Manning.
Particular thanks to Alex Garrett, who with endless patience shepherded the
book, and its accompanying code, through a brutally accelerated development
and revision process. Thanks also to Lianna Wlasiuk, who served excellently as
interim editor early in the project.
Thanks, in fact, to everyone at Manning who answered my questions, pointed
out my typos, corrected my spelling, marshaled my reviewers, refined my think-
ing, or, in fact, actually edited, re-edited, copyedited, revised, read, reread,
proofread, typeset, designed, marketed, produced, or otherwise created my
book: Syd Brown, Susan Capparelle, Andy Carroll, Lee Fitzpatrick, Leslie
Haimes, Chris Hillman, Ted Kennedy, Elizabeth Martin, Mary Piergies, Sherry
Roberts, Tony Roberts, and Helen Trimes. Double thanks for doing everything
on a very tight schedule. If I’ve left out anyone, either through accident or omis-
sion, please accept my apologies.
Heartfelt thanks to those who read and reviewed the book independently,
serving both as expert witnesses and test subjects: Brian Doyle, Al Giacomucci,

xvii
jdk.book Page xviii Monday, March 11, 2002 3:38 PM

xviii ACKNOWLEDGMENTS

Ian Griffiths, Jasen Halmes, David M. Karr, Stephen Kelvin, Carl Muckenhoupt,
Andrew Silis, Jon Skeet, and Itai Zukerman. I would particularly like to thank
Ian Griffiths, who went over the book with a fine-toothed comb, lending an
expert’s brain and a proofreader’s eye.
Outside the world of book publishing, I would like to thank Kieron Murphy
for commissioning many technical articles from me, effectively jump-starting my
writing career. Thanks to Jim Blandy, Bob Geitz, Chris Gernon, Steve Hawley,
Chris Koch, Tom McHugh, and Rich Salter for teaching me computer science.
Thanks to Mark Cline, wherever you are, for teaching me to program in the first
place.
Thanks and apologies to friends and family who found me scarce during this
project.
Finally, endless thanks to Susan E. Beal, Esq., for her love and patience (and
even a bit of proofreading) throughout the writing of this book, and more
thanks to Hume Beal for his purring and enthusiasm.
jdk.book Page xix Monday, March 11, 2002 3:38 PM

about this book

The JDK 1.4 release of the Java programming language from Sun Microsystems
represents a substantial step in Java’s progress. Some of the new features are
packages that have been in use for some time but have not yet been part of the
core Java platform; other features are completely new.
Whatever their origin, these features extend Java’s capabilities, encapsulating
complex functionality behind simple abstractions. Some of the features help inte-
grate Java further into the host operating system, providing direct access to ser-
vices that had previously only been accessible to native code.
This book is decidedly code-centric. The central feature of each chapter is a
program or set of programs that demonstrate the subject of the chapter within a
complete, real-world program. Although each chapter starts with an overview of
its topic and outlines the main classes and methods of the crucial packages, it
does not duplicate information that can easily be found in the Java documenta-
tion. Thus, this book should be considered a by-example companion to the com-
prehensive documentation.
As you peruse the chapter descriptions that follow, you may notice that this
book does not rigorously cover all topics. I consider a number of topics too broad
to be covered in any useful way in a book of this kind; such topics generally need
their own book. These include CORBA (including the new Portable Object
Adapter (POA) Object Request Broker (ORB)), XML, the Java Cryptography
Extension (JCE), and the Java Authentication and Authorization Service (JAAS).

xix
jdk.book Page xx Monday, March 11, 2002 3:38 PM

xx ABOUT THIS BOOK

At the time this book was being prepared, it did not seem possible to acquire
a driver that supported enough JDBC 3.0 features to make testing possible.
Rather than write from a position of ignorance, and include possibly spurious
code listings, I decided not to include a chapter on this important topic.
Sadly, the Generics (parameterized types) feature was, in the end, not
included with JDK 1.4 as originally promised. This controversial addition to the
language looks like it will be included in JDK 1.5 for sure, and you can download
an early-access version of it from Sun. However, since it requires a change to the
compiler, it can’t really be said to be a part of JDK 1.4 and so is not discussed in
this book.

Who should read this book

The ideal reader of this book is an intermediate or expert Java programmer who
needs to use the new features of JDK 1.4. I’ve tried to include enough introduc-
tory material that beginners will also find this book useful; however, this book
will not teach you to program—it assumes you already know how.
This book is intended to guide the reader through the essentials of most of
the new packages, libraries, and features in the JDK 1.4 release of the Java pro-
gramming language from Sun Microsystems. It is intended to be comprehensive,
but not necessarily complete. I’m assuming that once you’ve learned how to use
an API, you will be comfortable digging into the documentation supplied by
Sun, and that you can explore some of the more obscure features of these new
APIs on your own.

How this book is organized

Each topic is given its own chapter, except for the New Input/Output (NIO )
library, which is given two chapters. Some of the chapters provide a comprehen-
sive review of an entire package because that package has been added to the core
Java distribution for the first time. For these topics, the chapter begins with a
conceptual overview that describes the classes and the intentions behind their
design. Then, each major feature of the package is discussed in its own section.
Other chapters touch on the new features of an already-familiar package. In
these cases, little time is spent explaining the package as a whole. Rather, each
new feature is given its own section, which serves as a kind of “mini-chapter.”
Each chapter (or “mini-chapter,” in the case of chapters covering familiar
packages) can be read on its own. It is assumed that you will read the book in any
jdk.book Page xxi Monday, March 11, 2002 3:38 PM

ABOUT THIS BOOK xxi

order, and dependencies between the chapters have been minimized. Cross-
references have been provided where necessary.
Particular emphasis has been placed on the creation of quality code examples.
The sample programs in this book are intended to be useful, self-contained, and
reusable; they are designed to fully exercise and illustrate a new feature, set of
features, or API. Some of them might seem a bit overlong, but I felt that it
would be better for the programs to be complete and useful than to be concise.
You don’t have to read every line of every program—only the parts that strike
your fancy. Use the annotations to find your way around the code, and remem-
ber, you won’t have to type the programs in—you can download them. (More
about that shortly.)
A chapter-by-chapter outline of the contents of the book follows.

Chapters 1 and 2—Basic and Advanced NIO

NIO, or the New Input/Output API, presents the concept of the channel as an
alternative to the stream. Channels allow for efficient, buffer-based input and
output—buffers are used to read data from, and write data to, channels. Direct
buffers provide direct access to system input and output buffers and thus offer
the potential for transferring data from one channel to another with a minimum
of data copying.
NIO makes it possible to circumvent the potential inefficiencies of Java’s
stream I/O architecture, with the possibility of great gains in speed. The channel
paradigm is not as simple to use as the stream paradigm, but judicious use of it in
cases where I/O speed is essential can help Java applications achieve the through-
put of applications written using native low-level I/O APIs.
NIO also offers asynchronous I/O via selectable channels, fashioned after the
select Unix system call. Select is a powerful way to perform asynchronous I/O,
allowing you to handle a large number of connections at a single time. This goes
a long way in making Java the language of choice for creating high-end Internet
servers.
This topic is divided into two chapters. Chapter 1, “Basic NIO,” covers the
fundamental classes used in the NIO system: channels and buffers. It also has a
section on file locking. Chapter 2, “Advanced NIO,” discusses powerful features
based on the basic classes, including memory-mapped files, asynchronous I/O,
charset translation, and network interfaces.
As examples, these chapters contain a simple channel-based TCP/IP forwarder
and a select-based implementation of a chat (instant messaging) system.
jdk.book Page xxii Monday, March 11, 2002 3:38 PM

xxii ABOUT THIS BOOK

Chapter 3—Java2D
Two new Java2D-related features are described in this book: the Print Service
API and a new Image I /O Framework.
The Print Service API gives your application full access to the set of printers
available on a computer, as well as the full range of printing options available on
each printer. It is intended to supersede the java.awt.print package. Docu-
ment classes allow you to create printable objects in a variety of formats and
submit those documents to printers that support these formats. Listeners allow
your application to track the progress of the print job so you can report back to
the user.
The Image I /O Framework takes Java another step away from the Web-
centeredness it started with. It used to be difficult to load and save images; with
the new API, this is easy. Images can be saved and loaded in a variety of formats,
and there’s no need to mess with annoying MediaTracker objects.
This chapter includes an example implementation of a print dialog box, and
a program for generating professional-looking graphs for displaying web server
statistics.

Chapter 4—Java Web Start (JAWS)

You may have found yourself envying programmers who have created applica-
tions that automatically update themselves when new releases are available. With
Java Web Start (JAWS), you can stop being envious. JAWS is not just an API, but
also a system for automatic download and installation of Java applications. Each
time a JAWS application is executed, the JAWS runtime checks the application’s
web ser ver and downloads any new code or data resources automatically.
Although existing Java applications can run inside JAWS without modification,
the JAWS API provides mechanisms for controlling the way the JAWS runtime
behaves, as well as special secure methods for accessing system resources, such as
the local disk and the system clipboard.
When Java was first released, one of the exciting ideas was the possibility of
being able to deploy complex, full-featured applications via the Web. Browser
security models prevented applets from saving themselves to disk, though, and
this idea fell out of favor. Now JAWS can be integrated into popular browsers via
the Java Web Start plug-in. This allows a user to download and install a complete
application with a single click. Downloaded applications are saved between invo-
cations. A comprehensive security model completes the picture.
jdk.book Page xxiii Monday, March 11, 2002 3:38 PM

ABOUT THIS BOOK xxiii

This chapter comes complete with a simple drawing program that makes
comprehensive use of the JAWS system, including accessing the local disk, print-
ing, controlling the browser, and accessing the system clipboard. The Java Net-
work Launching Protocol & API (JNLP), which is the technology underlying
JAWS, is also discussed.

Chapter 5—Logging
The Logging API provides a mechanism for programs to report about their
behavior. More importantly, it provides a way to turn logging messages on and
off after an application has been deployed in the field, greatly aiding in applica-
tion maintenance.
Logging is hardly a new feature—in fact, many logging systems have been
created for Java. However, the JDK 1.4 release standardizes this API in order to
provide a consistent and reliable mechanism. Widespread use of the Logging API
will mean that it will become much easier for applications to be maintained and
debugged after they have been deployed.
The example programs in this chapter demonstrate the ability to customize the
logging system. A custom handler redirects logging messages to a logging win-
dow (complete with a central control window), and a custom formatter provides
an alternative logging format that takes up less space than the default format.

Chapter 6—Assertion facility

The new Assertion facility provides a way for a programmer to litter the code
with “sanity checks.” Assertions are like error checks, except they can be turned
completely off, and they have a simpler syntax. Because they are so brief, they are
very convenient, and there’s no reason not to use them liberally.
Assertions can be turned on and off even after the software has been released.
When assertions are off, they don’t use system resources, but they can be turned
on whenever the software seems to have a problem. With assertions turned on,
the software is much more likely to find, and report on, its own bugs.
Assertions are important enough that the developers of Java felt it was worth
adding new syntax to the language. For large-scale applications, assertions are
crucial to maintaining software throughout its release cycle.

Chapter 7—Exceptions
While we’re on the subject of errors, there are a couple of nice surprises in JDK
1.4 in the area of Exceptions.
jdk.book Page xxiv Monday, March 11, 2002 3:38 PM

xxiv ABOUT THIS BOOK

The new StackTraceElement object allows a program to access each stack

frame of an exception’s stack trace, giving you access to the source file, method,
and line number of each frame in the stack trace. Previously, you had to parse the
stack trace output; now you can get at this information directly. You can even
synthesize your own stack frames in special circumstances.
Chained exceptions allow for the fact that it is common for one exception to
trigger another. In these cases, the initial exception was lost, unless the program-
mer took pains to stuff the old one inside the new one. This stuffing procedure
has been formalized, since it has proven to be so common. Each Throwable can
now have a cause, which is another Throwable.
The sample program in this chapter uses StackTraceElements to provide a
more detailed stack trace—one that lists the source-code context of each frame in
the stack trace.

Chapter 8—Collections
The Collections Framework has a number of useful new features. Besides some
list-manipulation utilities in the Collections class, we find implementations of
Map and Set that remember the order of their elements, unlike regular Maps and
Sets. Additionally, the new IdentityHashMap class presents a way to circum-
vent an object’s idea of equality, which can be very useful when, for example, tra-
versing a graph of objects.
The ordered Map and Set classes are demonstrated by a program that
searches for files in a file path, and IdentityHashMap is illustrated in a program
that traverses an object graph.

Chapter 9—Regular expressions

The Regular Expression, or regex, facility, brings an incredibly useful feature to
Java. Common in Unix tools, and vastly popularized by Perl, regular expressions
are considered by many programmers to be an indispensable part of their tool-
boxes. Programmers accustomed to regular expressions, as well as the increas-
ingly common split and join functions, will be happy to see that Java now has
them as well.
To illustrate regular expressions, this chapter includes an HTML templating
system and a simple lexical analyzer.
jdk.book Page xxv Monday, March 11, 2002 3:38 PM

ABOUT THIS BOOK xxv

Chapter 10—The Preferences API

The new Preferences API provides a standard way for Java applications to store
and retrieve preference information. Preference information generally consists of
customizations and settings, often user-specific, that are useful but not essential
to the execution of the application.
The Preferences API interfaces with any preferences facility that exists within
the underlying operating system. In particular, some implementations store pref-
erence data in the Windows Registry. (Later implementations will presumably
store it in Application Data directories.)
This chapter presents an example program called PersistentWindows ,
which uses the Preferences API to automatically track a user’s changes to its win-
dow layout.

Chapter 11—The Java Secure Socket Extension (JSSE)

The Java Secure Socket Extension (JSSE) complements the already formidable Java
cryptography architecture with a full implementation of the SSL suite of proto-
cols. The JSSE framework is a generalized framework for secure socket communi-
cations over any protocol, while the SunJSSE security provider implements the
algorithms and protocols for standard SSL communications.
There have been SSL libraries for Java for a while, but SSL is now a compo-
nent of the main Java platform. This makes it easy to create programs that com-
municate with SSL-enabled systems such as secure web servers; it also makes it
easy to create complete client/server systems that can communicate with com-
plete secrecy. Tools and APIs for the creation and manipulation of encryption
keys round out the picture.
To illustrate secure communications, this chapter includes a simple secure
web server and a secure client/server system for credit card verification.

Typographic conventions
Code is displayed in courier font. Annotations are placed off to the side and
are sometimes continued below the code.

public void hello() {

Here ’s where we
System.out.println( "Hello." ); b print “Hello.”
}
jdk.book Page xxvi Monday, March 11, 2002 3:38 PM

xxvi ABOUT THIS BOOK

b Here’s some more information about the printing of “Hello.” Printing “Hello.”
might seem trivial, but it’s very important to do this.
By code we mean any textual material that is (or could be) the actual input to, or
output from, a computer program. This also includes names of classes and inter-
faces such as FilterOutputStream and Preferences , methods such as Sys-
tem.out.println() and hello() , variables such as i and nextValue, and, in
general, any short piece of text that is created by machine production or meant
for machine consumption.
Italics are used to emphasize a new term the first time it is used, and also for
emphasis. Callouts are used for particular emphasis:

WARNING This is a callout. It might be a Warning, a Note, a Definition, or some-

thing else. It’s meant to grab your attention.

Source code downloads

Most of the programs are too long to be conveniently entered by hand; the
book’s web site, at http://www.manning.com/travis/, has all of the code available
for download.
jdk.book Page xxvii Monday, March 11, 2002 3:38 PM

author online
When you purchase JDK 1.4 Tutorial, you also get free access to a private web
forum run by Manning Publications where you can make comments about the
book, ask technical questions, and receive help from the author and from other
readers.
To access the forum and subscribe to it, point your web browser to http://
www.manning.com/travis/. This page provides information on how to get on the
forum once you are registered, what kind of help is available, and the rules of
conduct on the forum.
Manning’s commitment to readers is to provide a venue where a meaningful
dialog between individual readers and between readers and the author can take
place. It is not a commitment to any specific amount of participation on the part
of the author, whose contribution to the Author Online forum remains volun-
tary (and unpaid). We suggest you try asking the author some challenging ques-
tions, lest his interest stray!
The Author Online forum and the archives of previous discussions will be
accessible from the publisher’s web site as long as the book is in print.

xxvii
jdk.book Page xxviii Monday, March 11, 2002 3:38 PM
jdk.book Page xxix Monday, March 11, 2002 3:38 PM

about the cover illustration

The figure on the cover of JDK 1.4 Tutorial is a woman of late eighteenth cen-
tury Armenia, attired in an ornate and beautiful dress. While the details of her life
and position are for us lost in historical fog, there is no doubt that we are looking
at a woman of wealth and high social standing. The illustration is taken from a
Spanish compendium of regional dress customs first published in Madrid in
1799. The book’s title page states:
Coleccion general de los Trages que usan actualmente todas las Nacio-
nas del Mundo desubierto, dibujados y grabados con la mayor exacti-
tud por R.M.V.A.R. Obra muy util y en special para los que tienen la
del viajero universal
which we translate, as literally as possible, thus:
General collection of costumes currently used in the nations of the
known world, designed and printed with great exactitude by
R.M.V.A.R. This work is very useful especially for those who hold them-
selves to be universal travelers
Although nothing is known of the designers, engravers, and workers who col-
ored this illustration by hand, the “exactitude” of their execution is evident in
this drawing. The Armenian woman is just one of many figures in this colorful
collection. Their diversity speaks vividly of the uniqueness and individuality of
the world’s cultures and regions just 200 years ago. This was a time when the
dress codes of two regions separated by a few dozen miles identified people
uniquely as belonging to one or the other. The collection brings to life the sense

xxix
jdk.book Page xxx Monday, March 11, 2002 3:38 PM

xxx ABOUT THE COVER ILLUSTRATION

of isolation and distance of that period—and of every other historic period

except our own hyperkinetic present.
Dress codes have changed since then, and the diversity by region, so rich at
the time, has faded away. It is now often hard to tell the inhabitant of one conti-
nent from another. Perhaps, trying to view it optimistically, we have traded a cul-
tural and visual diversity for a more varied personal life. Or a more varied and
interesting intellectual and technical life.
We at Manning celebrate the inventiveness, the initiative, and the fun of the
computer business with book covers based on the rich diversity of regional life of
two centuries ago‚ brought back to life by the pictures from this collection.
jdk.book Page 1 Monday, March 11, 2002 3:38 PM

This chapter covers

■

■
The New I/O system
Doing I/O with channels and buffers
1
Basic NIO
(New Input/Output)

■ File locking

1
jdk.book Page 2 Monday, March 11, 2002 3:38 PM

2 CHAPTER 1
Basic NIO

The New I/O (NIO) API introduced in JDK 1.4 provides a completely new model of
low-level I/O. Unlike the original I/O libraries in the java.io package, which were
strongly stream-oriented, the New I/O API in the java.nio package is block-
oriented. This means that I/O operations, wherever possible, are performed on large
blocks of data in a single step, rather than on one byte or character at a time.
The New I/O API libraries are elegant and well designed, but their very nature
represents a trade-off: some simplicity has been sacrificed for potentially enormous
gains in speed. One of the major sources of speed improvement is the introduction
of direct buffers. Where possible, data in these buffers is not copied to and from
intermediate Java buffers; instead, system-level operations are performed on them
directly. Although the implementation necessarily differs from platform to platform,
these direct buffers can potentially permit Java programs to have I/O performance
at or near that of programs written in C or C++.
The New I/O API also offers a platform-independent form of nonblocking I/O.
This simplifies multithreaded I/O programming and can enable programs to effi-
ciently handle a large number of connections to data sources and sinks.
The New I/O API model coexists peacefully with the original I/O libraries from
the java.io package. In fact, to a substantial degree, the original I/O libraries have
been rewritten to take advantage of the New I/O API.
Application programmers will not be forced to rewrite any of their code—exist-
ing applications written against the original APIs will continue to work as before.
However, you might consider using some of the new features of the New I/O API to
speed up any performance bottlenecks you find in your programs. Mixing old- and
new-style I/O code is not trivial, but it is possible to do cleanly and effectively.
This book divides its NIO coverage into two chapters—chapter 1, “Basic NIO,”
and chapter 2, “Advanced NIO.” Chapter 1 covers channels and buffers, as well as
file locking. These should give you a good understanding of the basic classes used
throughout the NIO system. Chapter 2 introduces you to the more advanced fea-
tures, such as multiplexed I/O; these make use of the ideas presented in this chapter.

1.1 Doing I/O with channels and buffers

Channels and buffers represent the two basic abstractions within the New I/O API.
Channels correspond roughly to input and output streams: they are sources and
sinks for sequential data. However, whereas input and output streams deal most
directly with single bytes, channels read and write data in chunks. Additionally, a
channel can be bidirectional, in which case it corresponds to both an input stream
and an output stream.
jdk.book Page 3 Monday, March 11, 2002 3:38 PM

Doing I/O with channels and buffers 3

The chunks of data that are written to and read from channels are contained in
objects called buffers. A buffer is an array of data enclosed in an abstraction that
makes reading from, and writing to, channels easy and convenient. Buffers are often
large, reflecting the fact that the I/O paradigm used in the New I/O API is oriented
toward transferring large amounts of data quickly.
Most of the input and output streams in the original I/O libraries have been re-
implemented to use channels as their underlying mechanism. This means that when
you do old-style I/O programming using these stream classes, you’re using channels
without realizing it. Since programming with streams is conceptually simpler than
programming with channels, you can continue to use streams if you find that your
program is fast enough. However, channels provide the opportunity for great speed
improvements, and some applications are actually easier to write using channels.
In this section, we’ll learn how channels and buffers work, and how they differ
from streams.

1.1.1 Getting a channel from a stream

As mentioned previously, many of the streams in the java.io package have been re-
implemented using channels. It’s easy to get the underlying channel that imple-
ments a stream, using the getChannel() method:
FileInputStream fin = new FileInputStream( infile );

FileChannel inc = fin.getChannel();

If you examine the documentation for the original java.io.* classes, you’ll see that
a number of the classes have been augmented with a getChannel() method:
■ java.io.FileInputStream
■ java.io.FileOutputStream
■ java.io.RandomAccessFile
■ java.net.Socket
■ java.net.ServerSocket
■ java.net.DatagramSocket
■ java.net.MulticastSocket
■ java.net.SocketInputStream (private)
■ java.net.SocketOutputStream (private)

You’ll notice that InputStream and OutputStream do not have getChannel() meth-
ods. This is because streams in general do not have to be implemented in terms of
an underlying channel object. Streams that are directly associated with operating
jdk.book Page 4 Monday, March 11, 2002 3:38 PM

4 CHAPTER 1
Basic NIO

system features like files and sockets generally are implemented as channels, while
pure-Java streams such as ByteArrayOutputStream and FilterInputStream are not.

1.1.2 Creating a buffer revision

Before you can do any kind of I/O on a channel, you need to have a buffer to do it
with. A buffer is an object that contains an array of data, and allows that data to be
used for reading from, and writing to, channels.
Creating a buffer is easy. Here’s how you create a ByteBuffer:
ByteBuffer buffer = ByteBuffer.allocate( 1024 );

This method takes a single argument—the size of the underlying array. This value is
called the buffer’s capacity. Once a buffer is created, the capacity never changes.
The best size for a buffer depends on the application. A larger buffer can allow for
faster throughput, but takes up more memory, while a smaller one may degrade
performance slightly, but uses less memory.
You’ll notice that we didn’t use a traditional constructor here. This is true in gen-
eral: buffers are either allocated using the static allocate() method, or created from
an existing byte array using wrap(). They are never constructed directly by the user.
You’ll also notice that we’ve created a ByteBuffer. The java.nio package also
contains IntBuffer, ShortBuffer, FloatBuffer, and so on. There are, in fact, buffer
types for each of Java’s primitive types. There is a class called Buffer, but it is
abstract—you can’t create one. (Buffer is the abstract superclass of all the buffer
classes.) A buffer is always a buffer of something. In the following sections, we’ll use
this ByteBuffer to illustrate how to do basic channel I/O. In section 1.2.6 we’ll
learn how to use the other types of buffers.

NOTE Since the ByteBuffer is by far the most common, and most important, of the
buffer classes, we will assume that any buffer we are talking about is a Byte-
Buffer unless otherwise specified.

1.1.3 Reading from a channel

Now that we’ve seen how to create a buffer, we’ll see how we can read from a chan-
nel into a buffer. In many ways, reading from a channel into a buffer is like reading
from an InputStream into an array, using one of the bulk-read methods in the old
java.io package.
The old read() method looked like this:
public int read( byte[] b, int off, int len );
jdk.book Page 5 Monday, March 11, 2002 3:38 PM

Doing I/O with channels and buffers 5

This variant on the InputStream.read() method allowed you to read a number of

bytes into an array all at once. In a sense, this approach to using streams is the pre-
cursor to the channel-oriented method of the New I/O API.
Here’s the method we use in the new API:
public int read( ByteBuffer dst );

You’ll note that there’s only a single argument to this method. This is because the
three arguments from the old-style read() call, as well as a number of other things,
are all wrapped up inside the ByteBuffer object.
You’ll also note that this new read() method returns an integer, just like the old
one. The meaning of this value hasn’t changed: it’s the number of bytes that were
successfully read. In both cases, this value is limited, because the read() method
will only read as many bytes as can fit in the available space. In the old method, the
available space was len-off; in the new method, the available space is equal to
buffer.remaining(). (More about this in section 1.2.3.)
Note that if you read from a channel that is only open for writing, a NonRead-
ableChannelException will be thrown.

1.1.4 Writing to a channel

Now that we’ve read some data from a channel into a buffer, we can write that data
out to another channel. This is done—surprise!—via the write() method of a chan-
nel. And, as with reading, writing a buffer is similar to doing a bulk-write from the
old java.io classes. Here is the old write() method:
public void write( byte[] b, int off, int len );

Again, the three arguments to the old-style write are replaced by a single argument,
which is a buffer, in the new write() method:
public int write( ByteBuffer src );

In this new method, you’ll see an important difference that you don’t see with the
read() methods: the new write() method returns an int. The old write() call was
guaranteed to write all the data or throw an exception. There were no valid condi-
tions under which it would write only part of the data and return. This is not the
case with the new write() method. It returns the number of bytes that were written.
And as with reading, if you write to a channel that is only open for reading, a
NonWritableChannelException will be thrown.
jdk.book Page 6 Monday, March 11, 2002 3:38 PM

6 CHAPTER 1
Basic NIO

1.1.5 Reading and writing together

The CopyFile program (see listing 1.1) illustrates the entire process of copying all
the data from an input channel to an output channel.
Watch out for a couple of new methods—flip() and clear(). These methods
are used any time a buffer is both written to and read from—which is almost all of
the time. After reading from a channel into a buffer, you call buffer.flip() to pre-
pare the buffer for being written to another channel. Likewise, once you’ve finished
writing the contents of a buffer to one channel, you call buffer.clear() to prepare
it for being read into again. More about this in section 1.2.4.
Make sure not to confuse reading from a buffer with reading from a channel:
reading from a channel means reading data from the channel, and putting it into the
buffer. Likewise, writing data to a channel means getting data from a buffer, and
writing it to a channel. See section 1.2.2 for more details.

Listing 1.1 CopyFile.java

(see \Chapter1 \CopyFile.java)

import java.io.*;
import java.nio.*;
import java.nio.channels.*;

public class CopyFile

{
static public void main( String args[] ) throws Exception {
String infile = args[0], outfile = args[1];
FileInputStream fin = new FileInputStream( infile );
FileOutputStream fout = new FileOutputStream( outfile );

FileChannel inc = fin.getChannel();

FileChannel outc = fout.getChannel();

ByteBuffer buffer = ByteBuffer.allocate( 1024 );

while (true) {
int ret = inc.read( buffer );
if (ret==-1) // nothing left to read
break;
buffer.flip();
outc.write( buffer );
buffer.clear(); // Make room for the next read
}
}
}
jdk.book Page 7 Monday, March 11, 2002 3:38 PM

Understanding buffers 7

A full understanding of this program—including an understanding of the flip()

and clear() methods—requires that we learn more about buffers. The next section
will describe how buffers work, and how they are used in practice.

1.2 Understanding buffers

Under the original I/O API, the read() and write() methods of the stream classes
took primitive Java types—ints, floats, and so on, as well as arrays of ints, floats,
and so on—as arguments. The management of these variables and buffers was up
to the programmer.
In the New I/O API, these primitive types are never written directly to channels.
Buffers are always used as the intermediaries. Buffers can also handle many of the
tasks that used to have to be done by hand—keeping track of how much data has
been read, making sure there’s enough room in an array for the data to be read
into, and so on. And buffers themselves have an I/O interface, because data must be
put into and taken out of buffers.
This section will go over the details of how buffers store data and how they are
used to transfer data to and from channels.

1.2.1 Creating buffers

As mentioned in section 1.1.2, buffers are never created using constructors. There
are two ways of making a ByteBuffer: via the allocate() methods, and via the
wrap() methods.
allocate() creates a fresh ByteBuffer and allocates the memory required to store
the data. allocateDirect() does the same thing, but it attempts to allocate the
required data area as direct memory. (See section 1.2.8 for more about direct buffers.)
The two wrap() methods create a new buffer by wrapping an existing array—or
a portion of an existing array—in a Buffer object. Note that that this doesn’t make
a copy of the data—the data in the buffer and the data in the array are the same data.
Any modifications to the buffer will show up in the array, and vice versa.

1.2.2 get() and put()

Generally, buffers are used to transfer data from one channel to another. The
read() method of one channel puts data into a buffer, and the write() method of
the other channel takes the data out of the buffer. However, buffers also have meth-
ods that can be used to fill and drain them “by hand.” These are used when you
want to put particular pieces of data into a buffer, or to extract the data and use it
for something. These methods are called get() and put().
jdk.book Page 8 Monday, March 11, 2002 3:38 PM

8 CHAPTER 1
Basic NIO

It can be confusing to consider the buffer get() and put() methods along with
the channel read() and write() methods, because they are backwards: when data is
read from a channel, it is written to a buffer. Likewise, when data is written to a
channel, it is read from a buffer. You read from a buffer using the buffer’s get()
methods, and you write to a buffer using the buffer’s put() methods.
There are two kinds of get() and put() methods: relative and absolute. Absolute
methods take an index parameter, which lets you choose the position in the under-
lying array at which you want to read or write. In contrast, relative methods do not
need an index parameter—they use the next value or values in the array after the
last one that was used. Relative methods are more commonly used, since they can
be used to fill or drain a buffer sequentially.
There are five basic put() methods. The methods listed here are for ByteBuffer,
but each of the Buffer classes has these methods. Of course, the arguments to the
corresponding methods of DoubleBuffer are double-based, rather than byte-based,
but otherwise they are the same.
■ put( byte b )—Put a byte into this buffer
■ put( byte src[] )—Put the bytes from an array into this buffer
■ put( byte src[], int offset, int length )—Put a portion of the bytes from
an array into this buffer
■ put( ByteBuffer src )—Copy the contents of another buffer into this buffer
■ put( int index, byte b )—Put a byte at array offset index (starting from zero)

Of these five methods, the first four are relative, and the last one is absolute.
There are four get() methods:
■ get()—Get a single byte from this buffer
■ get( byte array[] )—Fill an array of bytes with bytes from this buffer
■ get( byte array[], int offset, int length )—Fill a portion of an array of
bytes with bytes from this buffer
■ get( int index )—Get the byte at array offset index (starting from zero)

Of these four methods, the first three are relative, and the last one is absolute. Note
that there is no get( ByteBuffer ) method. You can accomplish the same thing
with put( ByteBuffer ).
In addition to these methods, ByteBuffer also contains a set of methods for
reading and writing other primitive Java types. In each case, a call to one of these
methods can be considered equivalent to calling the single-byte get() and put()
jdk.book Page 9 Monday, March 11, 2002 3:38 PM

Understanding buffers 9

methods one or more times, with the bytes involved making up the value of the
primitive type. More on this in section 1.2.7.

1.2.3 Buffer state values

In the previous sections, we saw how to read from and write to a buffer, but we
never really found out what was going on inside the buffer. If you’ll recall, the inner
loop of the CopyFile program listed in section 1.1.5 was, schematically, something
like this:
inc.read( buffer );
buffer.flip();
outc.write( buffer );
buffer.clear();

What’s noteworthy about this is that our code doesn’t seem to have to keep track of
how many bytes were read and written each time. This is something the buffer does
for us automatically.
Buffers take care of such things using a number of buffer state values. These are
values that reflect the current state of the buffer as it is used for various reading and
writing tasks. They keep track of how many bytes have been read or written, how
many more can be read, how much room there is to read more, and so on. These are
summarized in table 1.1 and are explained in further detail in the following sections.
Table 1.1 The state of each buffer is represented by three values. These values change as the buffer is
read from, or written to, indicating progress through the buffer. In this way, a buffer keeps
track of the reading or writing process.

State value name What it is

position The index into the underlying array of the next read (or write)

limit The index into the underlying array of the first element that should not be read
(or written)

capacity The size of the underlying array

Buffer position
The buffer position specifies the next entry in the array that will be used for reading
or writing:
■ If the buffer is being written to (which means that it is being used for a chan-
nel read), the buffer position points to the location where the next byte will
be stored.
jdk.book Page 10 Monday, March 11, 2002 3:38 PM

10 CHAPTER 1
Basic NIO

■ If the buffer is being read from (which means that it is being used for a chan-
nel write), the buffer position points to the next byte to be read.
In both cases, each time a byte is read or written, the value of the buffer position
increases by the length of the item written. The position cannot become greater
than the value of the buffer limit. If the code tries to execute a read or write that
would make the position greater than the limit, a java.nio.BufferUnderflowEx-
ception or java.nio.BufferOverflowException, respectively, is thrown.

Buffer limit
The buffer limit is the amount of data in the array. It defines the first array slot that
should not be used for reading and writing. It is different from the capacity: the
capacity of an array specifies how much data could be put in it—that is, how much
could potentially fit. The limit specifies how much has actually been put in the array.
If the buffer is being written to, the limit specifies the array element after the last
array element that can accept a value. In this case, the limit is generally set to be
equal to the capacity of the buffer, so that the entirety of the underlying array will
be used.
If the buffer is being read from, the limit specifies the array element after the last
array element that can be read. The buffer limit might be equal to the buffer capac-
ity, which means that the buffer was filled with data before reading started. The
buffer limit might also be less than the capacity, which means the buffer was only
partially filled when reading started.

Buffer capacity
The buffer capacity is equal to the size of the underlying array. Even if the array is
only partially filled with data, the capacity refers to the entire array, including both
the used and unused portions. The capacity of a buffer never changes.

NOTE Each buffer has a method called remaining(), which returns the num-
ber of slots left that can be read or written. This value is equal to limit()
- position().

1.2.4 flip() and clear()

Buffers are commonly used to read data from one channel and then to write that
same data out to another channel. In this case, the buffer alternates between being
written to and being read from. The flip() and clear() methods are called between
these reads and writes, in order to prepare the buffer for each new phase in the
jdk.book Page 11 Monday, March 11, 2002 3:38 PM

Understanding buffers 11

process. The following sequence

describes the process in detail.
At the beginning, the buffer is
brand new. Its limit is set to its
Position Limit
capacity, and its position is set to 0
(as shown in figure 1.1). Capacity

In figure 1.1, the underlying

array has a length of 8. The position
Figure 1.1 When the buffer is initialized, its
is set to 0, while the limit and position is set to 0, and its limit and capacity are
capacity values are set to 8. The set to the length of the array.
limit looks like it is too large, since,
technically, it points past the end of
the usable area of the array. But if
you’ll recall, the definition of the
limit is that it is the first slot that Position Limit
shouldn’t be written to.
T h e r ea d( ) m e t h o d o f t h e Capacity

source channel is then called, and it Figure 1.2 After writing some data, the position
places some data in the buffer. This has advanced, while the limit and capacity are
data may or may not fill the buffer. unchanged.
The limit is still set to the capacity,
while the position has advanced (see
figure 1.2).
Some more data is read from the
channel and placed into the buffer. Position Limit
The buffer position advances fur-
ther (see figure 1.3). Capacity

The writing phase is now over. Figure 1.3 After writing more data, the position
buffer.flip() is called to prepare has advanced further.
the buffer to have its data read (see
figure 1.4). (You can think of the flip() method as flipping a switch between read-
ing and writing modes. Buffers don’t actually have reading and writing modes—
you can mix read() and write() calls freely. However, it is very common to use a
buffer in the way we are using it here—you do some reading, flip the buffer, and do
some writing.)
In order to prepare for reading, the value of limit must be changed. Before the
call to flip(), the buffer was being used as an empty area into which data could be
put; the limit value specified the end of this empty area. Now that flip() has been
called, the buffer is being used as a source of data, and the limit value now specifies
jdk.book Page 12 Monday, March 11, 2002 3:38 PM

12 CHAPTER 1
Basic NIO

the end of this valid data. This limit

value is equal to the value that posi-
tion had before flip() was called.
Next, the buffer is passed to the
Position Limit
write() method of the destination
channel, which in turn reads some Capacity

data from the buf fer (see Figure 1.4 After calling flip(), the limit is set
figure 1.5). to the old value of position, and the position is set
to 0.
The reading process continues
until the position reaches the limit,
at which point there is no more
data in the buffer (see figure 1.6).
The reading phase is now over.
At this point, the clear() method
Position Limit
is called (see figure 1.7).
The position is set to 0, while
Capacity
the limit is set to the capacity, leav-
ing as large a space as possible for Figure 1.5 The reading process begins—as bytes
use in the next writing phase. are read, the position advances.

1.2.5 slice() and subbuffers

The slice() method allows you to
create a subbuffer of a given buffer.
A subbuffer is just another buffer
that happens to share its data with a Limit
portion of the data in the buffer it
Position Capacity
was created from. It is, neverthe-
less, a separate buffer with its own Figure 1.6 All of the data has been read, making
position, limit, and capacity. The position=limit.
subbuffer does not have to start at
the first element of the original
buffer.
When slice() is called, it takes
the current position and limit val-
ues and uses them to define the Position Limit
new subbuffer. The capacity and
limit of the subbuffer are set to be Capacity

the limit of the original buffer, and Figure 1.7 After clear() is called, position is set
the first element of the subbuffer to 0 and limit is set to capacity.
jdk.book Page 13 Monday, March 11, 2002 3:38 PM

Understanding buffers 13

corresponds to the element at value position within the original buffer (see
figure 1.8).
In figure 1.8, the subbuffer corresponds to the second through fifth elements of
the original buffer, inclusive. This corresponds to the following code:
ByteBuffer original = ByteBuffer.allocate( 8 );
original.position( 2 );
original.limit( 6 );
ByteBuffer slice = original.slice();

The individual data elements pointed to by the two buffers are in fact the same
data. Thus, any change to the shared data in one buffer will be immediately
reflected in the other.

1.2.6 Buffers of other types

ByteBuffers are the most basic form of buffer, and it is used throughout the New
I/O API. However, it is possible to have buffers of other types. In fact, there is a type
of buffer for each primitive Java type. Each of these types is a subclass of Buffer.
A buffer of a non-byte type stores values of that type, the way that a ByteBuffer
stores bytes. Each buffer type has five put() methods and four get() methods, just
like a ByteBuffer (see section 1.2.2), except that these methods work with their
particular type rather than on bytes.

Position Limit Capacity

Original
buffer

Slice
buffer

Position Limit

Capacity

Figure 1.8 A slice buffer shares a subsequence of the original buffer. It has its own position, limit,
and capacity values and does not have to start at the same position as the original buffer.
jdk.book Page 14 Monday, March 11, 2002 3:38 PM

14 CHAPTER 1
Basic NIO

Underlying each typed buffer is Viewed as ByteBuffer

a ByteBuffer that contains the raw byte 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
bytes from which the values are
built. The float values and the byte float 0 1 2 3 4
Viewed as FloatBuffer
values are merely different views
onto the same stream of bytes, as Figure 1.9 The same underlying data can be viewed
shown in figure 1.9. as a ByteBuffer and as a FloatBuffer.
Creating a typed buffer is easy.
For example, to create a FloatBuffer, you call the asFloatBuffer() method of
ByteBuffer:
ByteBuffer buffer = ByteBuffer.allocate( size );
FloatBuffer floatBuffer = buffer.asFloatBuffer();

Since you have access to both buffer and floatBuffer, you can access this data
as bytes or as floats. Note that you have two buffers here, each with its own posi-
tion, limit, and capacity values.
Suppose, for example, you wanted to read a series of floating-point values from a
channel: you could read from the channel into the ByteBuffer, and then read the
floats from the FloatBuffer. Since these two buffers point to the same data, the float-
ing-point values in the FloatBuffer are made up of the bytes in the ByteBuffer.
float floatArray[] = new float[floatArraySize];

FileInputStream fin = new FileInputStream( file );

FileChannel fch = fin.getChannel();

ByteBuffer buffer = ByteBuffer.allocate( floatArray.length*4 );

FloatBuffer floatBuffer = buffer.asFloatBuffer();

fch.read( buffer );

for (int i=0; i<floatArray.length; ++i) {

floatArray[i] = floatBuffer.get();
System.out.print( floatArray[i]+" " );
}

It’s important to remember that the position and limit values of the two buffers are
independent of each other. This means, for example, that although the FloatBuffer
might be exhausted by the reading process, the ByteBuffer is still ready to read
from the beginning—its position value is still 0.

1.2.7 Reading and writing other types from a ByteBuffer

There is another way to read floating-point values from a stream of bytes. Byte-
Buffer has a number of convenience methods that allow you to read values of other
jdk.book Page 15 Monday, March 11, 2002 3:38 PM

Understanding buffers 15

types—floats, shorts, and so on—directly from a ByteBuffer. This is particularly

useful if you want to read a set of mixed-type values from a buffer.
Figure 1.10 illustrates a series of mixed-type values packed into a single ByteBuffer.

byte short byte float

Figure 1.10 A series of mixed-type values packed into a single ByteBuffer

The code that reads this series of values is as follows:

FileInputStream fin = new FileInputStream( filename );
FileChannel fch = fin.getChannel();
ByteBuffer bb = ByteBuffer.allocate( 32 );
fch.read( bb );
bb.flip();
byte b0 = bb.get();
short s0 = bb.getShort();
byte b1 = bb.get();
float f0 = bb.getFloat();

The choice of whether to use typed buffers, such as FloatBuffer, or the typed
accessor methods, such as ByteBuffer.getFloat() and ByteBuffer.putFloat(),
depends on the homogeneity of the data involved. A FloatBuffer consists entirely
of floats, and so is good for reading banks of uninterrupted floating-point data. A
ByteBuffer, on the other hand, might be ideal for reading file headers that contain
data of different types.

WARNING The default byte order of a ByteBuffer is big-endian*, but this can be
changed using the ByteBuffer’s order( ByteOrder ) method. The or-
der() method can be used to find out the ByteBuffer’s current byte order.
You can find out the platform’s native byte order with the Byte-
Order.nativeOrder() static method.

*The terms big-endian and little-endian, borrowed from Jonathan Swift, refer to two different
methods for ordering bytes within a multi-byte value. The big-endian methods puts the most
significant byte first and the least significant byte last; thus, the 32-bit hexadecimal value AAB-
BCCDD is stored with the AA byte first and the DD byte last. In contrast, the little-endian
method would store the DD byte first and the AA byte last.
jdk.book Page 16 Monday, March 11, 2002 3:38 PM

16 CHAPTER 1
Basic NIO

1.2.8 Direct buffers

Direct buffers are buffers whose
underlying data arrays are allo- Java Copy System Read/write
Network

cated in such a way that I/O oper- array buffer

ations can be per formed Hard
drive
considerably faster. Typically, data
that crosses the boundar y Java Virtual Machine Operating system
between the Java Vir tual
Machine (JVM) and the underly- Figure 1.11 When writing from an array or nondirect
ing operating system has to be Buffer, data must be copied to an intermediate
buffer before it can be written to disk. Depending on
copied to or from a Java array to the operation, even more copying steps may be
an array within the JVM before it required.
can be passed to the operating
system (see figure 1.11).
Direct buffers, however, allo-
cate their data directly in the run- Direct
Read/write Network

time environment memor y (see buffer

figure 1.12). Hard
drive
Although the actual imple-
mentation of direct buffers differs Java Virtual Machine Operating system
from platform to platform, it is
expected that any reasonable Figure 1.12 Direct buffers use system buffers for their
implementation will take pains to underlying storage. In some operating systems, this
reduce copying of data in direct means that no copying is necessary for reading and
writing data—the data is transferred directly to and
buf fers. These buf fers should from the disk.
reside as close to the operating
system as possible, to reduce the number of copying steps as much as possible.
You might be tempted to allocate all buffers as direct buffers, but this would be
a bad idea. Direct buffers should only be used for buffers that will actually benefit
from the speed increase. Direct buffers generally cost more to allocate, and may
require more system resources during their lifetimes. Again, this depends on the
implementation.

NOTE Direct buffers do not contain faster memory. They simply contain memory
that can be accessed directly by the runtime system and/or the underlying
operating system, so that data that is passed in and out of the JVM will not
have to be copied, thus saving time.
jdk.book Page 17 Monday, March 11, 2002 3:38 PM

Understanding buffers 17

Allocating a direct buffer is trivial. Instead of calling

ByteBuffer buffer = ByteBuffer.allocate( 1024 );

you call
ByteBuffer buffer = ByteBuffer.allocateDirect( 1024 );

This is the only way you can create a direct buffer. Note that you clearly can’t use
the wrap() methods, because they explicitly construct a buffer using an array that is
within the JVM —a Java array. Similarly, the array() method, which returns the
underlying Java array of a Buffer, if any, will not work for a direct buffer, since there
is no underlying Java array.
To demonstrate the speed advantage of direct buffers, let’s try modifying the
CopyFile program from section 1.1.5 (listing 1.1) to use a direct buffer instead of a
regular buffer. The modification is shown in listing 1.2.

Listing 1.2 from FastCopyFile.java

(see \Chapter1 \FastCopyFile.java)

FileChannel inc = fin.getChannel();
FileChannel outc = fout.getChannel();

ByteBuffer buffer = ByteBuffer.allocateDirect( 1024 );

while (true) {
int ret = inc.read( buffer );
if (ret==-1)
break;
buffer.flip();
outc.write( buffer );
buffer.clear();
}

On the system used to test the code, copying a 16-MB file with CopyFile took nine
seconds, while copying it with FastCopyFile took about 4.5 seconds—a 50% savings!

1.2.9 Example: TCP/IP forwarding

Let’s take a look at buffers in action in a program that does TCP/IP forwarding.
This is a perfect application for buffers, because it’s mostly about transferring data,
rather than processing it.
jdk.book Page 18 Monday, March 11, 2002 3:38 PM

18 CHAPTER 1
Basic NIO

TCP/IP forwarding
Forwarder is a simple TCP/IP for- Source Forwarding Destination
warding program. It for wards machine machine machine
TCP/IP connections coming into
Figure 1.13 Packages from the source machine are
the forwarding machine to any of a forwarded to the destination machine by the forwarding
number of destination machines. machine. Response data from the destination machine
Data that is sent from the source is likewise forwarded, sent back to the source
machine.
machine to the for warding
machine is forwarded to the desti-
nation machine. Response data from the destination machine is sent back to the
corresponding source machine (see figure 1.13).
The idea here is to simulate a connection that does direction from the source
machine to the destination machine. The forwarding machine acts as an intermedi-
ary. It forwards the data between
the machines and tries not to inter- Source Forwarding Destination
fere otherwise, much as an Inter- machine machine machine
net router does (see figure 1.14).
Figure 1.14 The forwarding machine seeks to
It’s important to understand simulate a direct connection between the source and
that this is a TCP/IP forwarder, not destination machines. It forwards the data but does
an IP forwarder. That is, the for- not modify it in any way.
warding is happening at the level
of TCP virtual circuits, rather than at the IP packet level. This means that the for-
warder cannot act as transparently as an Internet router. For example, data arriving
at the destination machine is marked as having come from the forwarding machine,
not from the source machine. Some connections will have a problem with being
forwarded in this way, but many will work fine.
One use for a program like this is as a simple firewall. The forwarding machine is
set up as the only machine that is accessible from the Internet. A set of other
machines are connected to the firewall; these are said to be “behind” the firewall
because external machines can only reach them by crossing through the forwarder
firewall (see figure 1.15). The forwarder can completely control which connections
will be accepted and which destination machines they will be forwarded to.

Configuring the forwarder

A configuration file is used to define what ports will accept connections, what desti-
nation machines they will be forwarded to, and which source machines they will be
accepted from. The configuration file looks like this:
jdk.book Page 19 Monday, March 11, 2002 3:38 PM

Understanding buffers 19

100 panix.com 80
110 panix.com 23
5555 www.w3c.org 80

The configuration file is defined more completely in the notes following listing 1.3.
To use this program, you must specify the name of the configuration file on the
command line, as follows:
java Forwarder forwarder.cfg

Forwarding Destination
machine machine

Destination
machine
Internet
Destination
machine

Destination
machine

Figure 1.15 The forwarder can be used as a firewall, protecting machines hidden behind the forwarding
machine from direct Internet access. Connections to the destination machines must be explicitly allowed
by the forwarder.

Source code
Let’s take a look at the source in listing 1.3.

Listing 1.3 Forwarder.java

(See \Chapter1 \Forwarder.java)

import java.io.*;
import java.net.*;
import java.nio.*;
import java.nio.channels.*;
import java.util.*;
import java.util.regex.*;

public class Forwarder

{
static private final int bufferSize = 0x4000; //BUFFER_SIZE

// Defines the format of the config file lines

private static final int LOCAL_PORT_POS = 0;
private static final int HOSTNAME_POS = 1;
private static final int PORT_POS = 2;
private static final int SOURCES_POS = 3;
jdk.book Page 20 Monday, March 11, 2002 3:38 PM

20 CHAPTER 1
Basic NIO

public Forwarder() {
}

public void readConfig( String configFilename ) B

Parse the
throws IOException { configuration file
FileReader fr = new FileReader( configFilename );
LineNumberReader lnr = new LineNumberReader( fr );
while (true) {
String line = lnr.readLine();
if (line==null)
break;
Pattern pattern = Pattern.compile( "\\s+" ); C
Use regular
String strings[] = pattern.split( line ); expressions to parse
if (strings.length < SOURCES_POS) {
System.err.println( "Config file syntax error at "+
configFilename+":"+
lnr.getLineNumber() );
System.exit( 1 ); // Any syntax error and we quit
}

// First, the local forwarding port

int forwardingPort = Integer.parseInt( strings[LOCAL_PORT_POS] );

// Then the destination address

InetAddress destAddress =
InetAddress.getByName( strings[HOSTNAME_POS] );

// Then the destination port

int destPort = Integer.parseInt( strings[PORT_POS] );

// Finally, zero or more permitted sources

InetAddress sources[] = new InetAddress[strings.length-SOURCES_POS];
for (int i=SOURCES_POS; i<strings.length; ++i) {
sources[i-SOURCES_POS] = InetAddress.getByName( strings[i] );
}
AddressSet allowedSources = new AddressSet( sources );

addForward( forwardingPort, destAddress, D Add a forward for

destPort, allowedSources ); each config line
}
}

public void addForward( int forwardingPort, E

Set up a forward
InetAddress destAddress,
int destPort,
AddressSet allowedSources ) {
InetSocketAddress destSocketAddress =
new InetSocketAddress( destAddress, destPort );
ForwarderListenerThread flt =
new ForwarderListenerThread( forwardingPort,
destSocketAddress,
allowedSources );
Another Random Scribd Document
with Unrelated Content
In en rondom Constantinopel bouwde en herbouwde Justinianus ongeveer vijf en twintig
kerken, waarvan vele rijk versierd waren met marmeren beelden en mozaïeken. De
meesten waren waarschijnlijk in den nieuwen Byzantijnschen stijl, die den ouden
basiliek-stijl begon te verdringen en van dezen was de voornaamste de groote kathedraal,
gewijd aan de Heilige Wijsheid (Hagia Sophia) van God en algemeen bekend als de
Sofia-kerk.3) Door Constantijn was een basiliek van denzelfden naam op dezelfde plaats
gebouwd. Die was verbrand bij het tumult, dat door de verbanning van den patriarch
Chrysostomus ontstond, en een tweede gebouw, een basiliek met houten dak, was
eveneens vernield bij het Nika-oproer. De Sofia-kerk van Justinianus bestaat nog, d.w.z.
het gebouw zooals het door hem hersteld is na een aardbeving, waarbij een groot deel
van den ouden koepel was ingestort. Het plan van deze prachtige kerk (thans een
moskee) werd ontworpen door Anthemius van Tralles, éen der vijf broeders, die allen
even beroemd waren, ieder in hun beroep. Haar luister, die door Turksch fanatisme
gedeeltelijk is verborgen of ontsierd, wordt zeer juist beschreven door Justinianus’
uitroep: “Ik heb U overtroffen, o Salomon!” Over den bouwstijl van de Sofia-kerk zullen
wij later nog spreken.

Onder de vele andere kerken door Justinianus in Constantinopel opgericht was een
nieuw gebouw in Byzantijnschen stijl op de plaats van de oude Constantijnsche Kerk
van de Heilige Apostelen. Het is verdwenen, doch naar dit voorbeeld is de St. Marcus’
kathedraal met de vijf koepels te Venetië gebouwd, en dus is de herinnering daaraan
blijven bestaan. Aan Justinianus moet ook worden toegeschreven de Byzantijnsche kerk
van St. Sergius en St. Bacchus, die zooals de S. Vitale te Ravenna, in het midden
achthoekig is, met acht bogen, waarop een groote koepel rust. Deze S. Vitale is ook een
beroemde, nog bestaande kerk, die in nauwe betrekking staat met den naam van
Justinianus. Zij is ouder dan de St. Sophia (waaraan men in 532 begon); het is een
Byzantijnsche kerk, en gelijkt zoozeer op de kerk van St. Sergius en St. Bacchus, dat
zeer waarschijnlijk het ontwerp voor Theoderik’s kerk te Ravenna en misschien zelfs de
werklieden afkomstig waren van Anthemius en een ander oosterschen architect; en
toevallig was de man, die de leiding had van den bouw van de S. Vitale4), Aartsbisschop
Ecclesius, juist een jaar, voordat men aan de kerk begon, te Constantinopel; want Koning
Theoderik zond in 525 gezanten naar het oostersche hof, en onder dezen was, behalve
Paus Johannes, ook Ecclesius. Zijn houding te Constantinopel beviel den Ariaanschen
monarch blijkbaar beter dan die van den ongelukkigen Paus, want kort na zijn terugkeer
en waarschijnlijk vóor Theoderik’s dood begon hij deze prachtige Byzantijnsche kerk,
die, trots vele herstellingen toch nog iets van haar oorspronkelijken luister behouden
heeft. Van bijzondere schoonheid zijn de marmeren zuilen, met de fijnbewerkte
kapiteelen en onbeschrijfelijk rijk zijn de mozaïeken.

Sommige van deze mozaïeken zijn geplaatst tijdens het leven van Ecclesius († 534),
want hij wordt er op voorgesteld zonder nimbus. Dit apsis-mozaïek, zooals de groep
engelen in de S. Apollinare Nuovo, onderscheidt zich sterk van de andere door zijn
eenvoudige en indrukwekkende grootheid, die wij ook in de oudere mozaïeken te
Ravenna en te Rome vinden. De andere kenmerken zich door den pronkerigen opschik
en onartistieke uitvoering, die men gewoonlijk bij Byzantijnsche mozaïeken aantreft.
Deze behooren tot de periode, die volgt op de inneming van Ravenna (540) door
Belisarius, en waren zonder twijfel bekostigd door Justinianus en Theodora, die ruim
hadden ingeschreven voor de versiering van de S. Vitale. Het is dus zeer belangrijk, dat
onder deze latere mozaïeken de portretten van den Keizer en de Keizerin voorkomen en
uit den nimbus, waarmede beiden zijn versierd mogen wij misschien afleiden, dat de
mozaïeken voltooid zijn na 548, toen Theodora stierf, of zelfs na Justinianus’ dood in
565. Justinianus wordt afgebeeld met een gouden bakje vol juweelen of geld, dat hij de
kerk aanbiedt; hij is vergezeld van den Aartsbisschop Maximianus, die het gebouw in
547 heeft gewijd. Theodora5, omgeven door haar hofdames, brengt als haar offer een
grooten beker en is op het punt de kerkdeur binnen te gaan, waarbij de doopvont staat.

Nog éen kerk, S. Apollinare in Classe moet hier in verband met Justinianus vermeld
worden, want het is zeer waarschijnlijk dat hij persoonlijk belang had bij de voltooiing
van die kerk, daar zij tusschen 535 en 538 gebouwd is door den opvolger van Ecclesius
en, evenals de S. Vitale, door Maximianus gewijd is. De stad en de haven van Classe
zijn, zooals wij reeds verteld hebben, geheel verdwenen en deze groote basiliek van S.
Apollinare staat nu, evenals de oude Grieksche tempels te Paestum, bijna geheel
verlaten; misschien is er geen indrukwekkender gebouw in de wereld. Uitwendig bezit
het geen schoonheid die met een Griekschen tempel of noordelijke kathedraal kan
vergeleken worden, ofschoon men den ouden klokketoren, die in zwijgende waardigheid
tusschen de met waterlelies bedekte poelen en de drassige velden van het eenzame
moerasland zich verheft, niet licht zal vergeten; maar inwendig is deze basiliek een van
de heerlijkste en prachtigste, die bestaan.
 Het Rijk van de Longobarden

c. 568–c.700

1 In de Middeleeuwen nam men algemeen aan, dat het Romeinsche Keizerrijk nog steeds bestond.
2 Men leze het levendig verslag van de 4 partijen of race-clubs van den Romeinschen Circus (wit, rood,
groen, blauw) en de onlusten ontstaan door de moorddadige veeten tusschen die partijen, bij Gibbon XL,
2, en de commentatoren op Juvenal. Sat. XI. 193 sq., verzen die, mutatis mutandis, nog heden van
toepassing zijn. De uitroep “Nika” beteekent “Overwin!”
3 Het Parthenon te Athene was reeds als kerk aan de Hagia Sophia gewijd.
4 Op een van de groote mozaïeken wordt hij voorgesteld met een model van de kerk in zijn hand.
5 Haar diadeem is rijk bezet met groote parels en edelgesteenten, zooals de latere Keizerskroon (zie fig.
19). Het haar met de lange oorhangers en den breeden kraag, maniakon, alles rijk voorzien van juweelen,
vervangen volgens de nieuwe mode den breeden en zwaren gouden halsketting.
Derde Deel.
Historisch Overzicht.
568–800.

O
ns verhaal is afgebroken bij den dood van Narses, die waarschijnlijk in 567
plaats vond, een paar maanden voor den inval van de Longobarden; nu volgt,
gedurende twee eeuwen ongeveer, de heerschappij van de Longobarden, een
tamelijk donkere en droevige periode, waarin vele zaden, die later bloemen en vruchten
voortbrachten, zich in den grond ontwikkelden, maar die voor ons niet veel
aantrekkelijks heeft, behalve eenige belangrijke persoonlijkheden, voorboden van de
komende lente van de Italiaansche kunst.

De bronnen van onze kennis zijn verscheidene; van groot belang zijn de geschriften van
Paus Gregorius den Groote, het Edict van Koning Rotharis (Roterik) met een voorrede,
waarin vele feiten vermeld worden, die een duisteren tijd eenigermate belichten (tot 640
ongeveer); tegelijk met de handschriften van die voorrede is een belangwekkenden
Origo Langobardorum van omstreeks 607 gevonden, die de eenigszins legendarische
oudste geschiedenis van de Longobarden geeft; ten slotte hebben de Historia
Langobardorum van Paul Warnefrid, algemeen bekend als Paulus Diaconus, een
Longobard, die een tijdlang leefde aan het hof van Karel den Groote en zich ten slotte
terugtrok in het Benedictijner klooster van Monte Cassino, waar hij waarschijnlijk
omstreeks 800 stierf. Zijn Historia geeft een zeer duidelijke beschrijving van den
ellentoestand van Italië tijdens den Longobarden-inval en een reeks van levendige
portretten van de Longobardische koningen tot de regeering van Liutprand, met vele
invoegsels, in den trant van Herodotus. Het werk is onvoltooid, misschien, omdat hijzelf
een Longobard was en toch veel aan den Frankischen koning te danken had, zoodat hij
het lastig vond de verovering van Italië door de Franken te beschrijven.
 24. Mozaïek in S. Pudenziana en S. Prassede, Rome.

Volgens Paulus Diaconus kwamen de Langobardi of Longobardi (“Langbaarden”),

evenals de Goten, van Scandinavië, waarheen hun voorouders waarschijnlijk uit de
binnenlanden van Azië getrokken waren. Zij worden vermeld door een Latijnschen
schrijver, Velleius Paterculus, die ten tijde van Augustus in Germanië onder Tiberius
gediend had. Hij noemt hun woestheid erger dan die der Germanen en vertelt dat zij aan
de Beneden-Elbe wonen. Ongeveer 178 namen zij deel aan de zuidwaartsche beweging
van verschillende stammen, die door Marcus Aurelius gestuit werd. Dan hooren wij drie
eeuwen niets van hen, maar zij zullen wel onder de bondgenooten van Attila geweest
zijn en blijkbaar trokken zij ongeveer 508 zuidwaarts van de Elbe en vestigden zich aan
den noordelijken oever van den Donau, na de Herulen te hebben overwonnen. Vier en
veertig jaar later (552) gedroegen zich de Longobardische hulptroepen van Narses zoo
woest, dat hij hen moest omkoopen om naar hun land terug te gaan. De koning van deze
hulptroepen was Audoin, wiens zoon Alboin thans onze aandacht vraagt.

Tegenover de Longobarden in het land der Rugiërs (de streek langs den noordelijken
oever van den Donau, tusschen Regensburg en Weenen) woonden de Gepiden, die uit het
Westen, uit Dacië schijnen, gekomen te zijn en het land, dat Theoderik en zijn Oost-
Goten hadden verlaten, Pannonië enz. hadden bezet. Deze Gepiden waren in 554 zoo
lastig voor het Romeinsche Rijk, dat door Justinianus, volgens de gewone politiek van
het Byzantijnsche hof, de Longobarden werden omgekocht om hen aan te vallen. Op den
eersten veldtocht doodde de jonge Alboin den zoon van den koning der Gepiden,
Torismund, maar de oorlog werd voortgezet en eerst toen de Longobarden voor een deel
van hun vee en veel land en buit een verbond met de Avaren, dien woesten stam van
Turksche afkomst, waardoor Justinianus zoo verschrikt was, hadden gekocht,
verpletterden zij hun vijand in een grooten slag. De Gepiden schijnen ongeveer
uitgeroeid te zijn, want men hoort niet meer van hen en hun koning Cunimund onderging
hetzelfde lot als zijn broeder Torismund door de hand van Alboin, die nu koning van de
Longobarden was. Zijn hoofd werd afgeslagen en Alboin liet van den schedel een
drinkbeker maken. Zijn dochter Rosamund werd gevangen genomen en gedwongen
Alboin te trouwen, die vroeger naar haar hand had gedongen, maar met minachting door
haar vader was afgewezen.

De inval van de Longobarden in Italië had verschillende oorzaken. Een van deze was
zonder twijfel de druk op hen uitgeoefend door de woeste Avaren, die zelf waarschijnlijk
westwaarts werden gedrongen door andere stammen uit het oosten; een andere oorzaak
was misschien de uitnoodiging van Narses; nog een andere, dat Italië door zijn bekenden
rijkdom en vruchtbaarheid de indringers tot zich trok, vooral daar het in dezen tijd bijna
weerloos was. De Byzantijnen hadden hun macht niet voldoende bevestigd. Het was
hun, evenmin als de Oost-Goten, gelukt de gunst of berusting van het Italiaansche volk
te winnen. Narses had de geestelijkheid en den adel zoo verbitterd door zijn militair
despotisme, en het volk door zijn uitpersingen dat, zooals de Romeinsche gezanten aan
Justinus hadden verklaard, Italië verwoest door de lange oorlogen, ontvolkt door
hongersnood en pest, volkomen onmachtig zich te verdedigen, bereid was zich onder
Gotische of elke andere heerschappij te stellen, daar die waarschijnlijk dragelijker zou
zijn dan die van Narses en het Oostelijke Keizerrijk. Narses had toen zijn ontslag
gekregen, maar ofschoon zijn opvolger Longinus getracht had eenige verbetering te
brengen, was hem dat mislukt. Hij maakte geen plan voor een systematische
verdediging, maar sloot zich op in Ravenna. De verstrooide overblijfselen van het
Gotische leger sloten zich zonder twijfel bij den nieuwen barbaarschen indringer aan en
in ongeveer achttien maanden werden vele van de voornaamste steden van Noord-Italië
overgegeven aan of veroverd door de horden1 van Longobarden, Gepiden, Sueven,
Saksen, Bulgaren en Beieren, die met hun vrouwen, kinderen, vee en al hun roerende
bezittingen Alboin waren gevolgd over den welbekenden pas van de Julische Alpen, die
zoo dikwijls door binnendringende benden was gebruikt.

Pavia bood hardnekkigen weerstand en werd drie jaren lang belegerd. Het was in dien
tijd sterker en belangrijker dan Milaan, dat nog niet hersteld was na den inval van de
Franken, en het werd nu hoofdstad van het Longobardische Koninkrijk. Dit rijk omvatte
in Noord-Italië de twee provincies Neustria en Austria, hetgeen ongeveer hetzelfde was
als het tegenwoordige Lombardije, Piemont, Emilia en Noord-Venetia, met de volgende
steden: Verona, Vicenza, Mantua, Trento, Bergamo, Brescia, Milaan, Pavia, Turijn,
Parma, Modena, Aquileia, Treviso. In het noorden, westen en oosten werd dit gebied
begrensd door de Alpen, maar naar het zuiden breidde Alboin zijn veroveringen uit over
de Apennijnen en tot de streek van Urbino en den Furlo-pas (de bekende Petra
intercisa), welk strategisch punt hij bezette. En zoo weinig weerstand werd er in
Midden-Italië geboden, dat benden van barbaren verder zuidwaarts marcheerden, het
geheele binnenland en een belangrijk deel van de kust veroverden, behalve de versterkte
havens, die toegankelijk waren voor de Byzantijnsche vloot. Twee van hun aanvoerders
wierpen zich als hertogen (duces) van dit veroverde gebied op; de een koos Spoleto en
de ander Benevento tot residentie. Deze twee Longobardische hertogdommen, die later
veel moeilijkheden veroorzaakten, schijnen eerst in naam aan Alboin onderworpen
geweest te zijn, maar weldra werden zij feitelijk onafhankelijk.

De steden en landstreken van Italië, die de Byzantijnsche heerschappij nog erkenden en

in naam het Exarchaat2 vormden, waren de volgende: Ravenna en het omliggende
gebied met de steden Padua, Bologna etc; het hertogdom Venetia, d.w.z. Venetië en
eenige aangrenzende eilanden en gebied op het vasteland; een deel van Istrië; de
“Pentapolis” met de steden Rimini, Ancona etc; Genua en de Ligurische Riviera; Rome
en zijn “hertogdom”; Napels en zijn gebied, waartoe Cumae en Amalfi behoorden; de
“hak en teen” van Italië; Sicilië en Sardinië.

De verovering door de Longobarden was dus allerminst volledig. Gedurende een eeuw
was de heerschappij over Italië verdeeld tusschen twee volkeren van geheel verschillend
karakter, een feit dat op zich zelf reeds een scheuring veróorzaakte; en deze scheuring in
de nationaliteit werd verergerd, totdat zij onherstelbaar werd door de inwendige
oneenigheden en de zwakheid van hen, die aanspraak maakten op de heerschappij; want,
aangezien oproer en anarchie voortdurend het Longobarden-rijk teisterden, en de
Byzantijnen steeds wanhopig worstelden om hun gezag te handhaven tegen de snel
toenemende macht van de Pausen en de begeerte naar vrijheid, die in Italië wakker werd,
maakten in alle deelen van het land de steden zich langzamerhand min of meer
onafhankelijk of begonnen zich tot kleine staten te vereenigen, waardoor ontelbare
staatkundige verwikkelingen ontstonden.
Kort na de inneming van Pavia (572) werd Alboin vermoord. De geschiedenis van zijn
dood lijkt op het Gyges-verhaal van Herodotus en schijnt een echo gevonden te hebben
in de legende van de “Schoone Rosamonde.” Men zegt, dat hij zijn vrouw bij een
feestmaal uitgenoodigd of gedwongen heeft te drinken uit den beker, die gemaakt was
van den schedel van haar vader Cunimund. Rosamund wreekte zich door haar minnaar,
een edelman, Helmechis geheeten, den wapendrager van den koning, over te halen hem
te vermoorden, of volgens anderen, een moordenaar voor die daad te huren. Alboin, in
zijn slaap overvallen, trachtte tevergeefs zijn zwaard te trekken, dat door zijn vrouw aan
de scheede was vastgebonden, en nadat hij zich eenigen tijd met een stoel had verdedigd
werd hij overweldigd en gedood.3 Helmechis en Rosamund trachtten met den steun van
het Gepidische leger de koninklijke heerschappij te bemachtigen, maar moesten wijken
voor de verontwaardigde Longobarden en de hulp inroepen van den Byzantijnschen
stadhouder van Ravenna, Longinus. Deze stuurde schepen de Po en de Adige op en aldus
ontvluchtten zij te zamen met Alboin’s dochter Albsuinda. Te Ravenna werden zij eervol
ontvangen. Toen besloot Rosamund, bemerkend dat Longinus verrukt was van haar
schoonheid, zich vrij te maken van Helmechis; maar nadat hij iets van den wijn
gedronken had, dien zij hem in zijn badkamer had gebracht, ontdekte hij, dat er vergift in
was en dwong haar het overige van den doodelijken drank zelf te drinken. Misschien zijn
de bijzonderheden van dit dramatisch verhaal verzinsels, ontstaan door een poging van
de Koningin om Byzantijnschen invloed te laten gelden of zelfs door een samenzwering
om de Byzantijnsche suprematie te herstellen. Maar de waarheid is soms even vreemd
als de verdichting en de toestanden bij de Longobarden waren in dien tijd, ondanks hun
Christelijken godsdienst (of beter Arianisme) zoodanig, dat men het verhaal wel kan
gelooven.

Hoe het ook zij, twisten en samenzweringen kwamen blijkbaar herhaaldelijk voor, want
de volgende koning, Clefi of Kleph, werd na een regeering van achttien maanden
vermoord en daar de hertogen het niet eens konden worden, werd er niemand in zijn
plaats gekozen, maar de volgende tien jaren bestuurden de hertogen, die waarschijnlijk
zes en dertig in aantal4 waren, ieder hun eigen hertogdom zonder een leenheer te
erkennen; als wij Paulus Diaconus mogen gelooven, regeerden de meesten zeer wreed,
daar zij de rijke grondbezitters verdreven en soms zelfs doodden, een derde van de
inkomsten eischten, de Katholieke kerken plunderden en de geestelijkheid vervolgden.

In het noorden waren de Longobarden reeds meermalen aangevallen en verslagen door

de Franken, die de grenslanden bij de Alpen (Savoye, Zwitserland, Provence enz.) bezet
hielden, vanwaar zij gemakkelijk op Milaan en in de Po-vlakte konden neerstrijken,
zooals zij ten tijde van de Goten hadden gedaan. Deze Franken waren de eenige hoop
voor Italië, want de Byzantijnsche macht was snel5 aan het afnemen en een beroep van
de Romeinen op den Keizer in het Oosten (Tiberius) had slechts den raad ten gevolge
gehad te trachten de Longobarden om te koopen of de Franken over te halen om hen aan
te vallen. Zonder twijfel was dit plan vroeger besproken, voordat Tiberius dezen
wanhopigen raad gaf en het verrast ons niet, dat ongeveer een jaar later (581) Paus
Pelagius II aan den bisschop van Auxerre schrijft, de Franken er toch op te wijzen, dat
zij als orthodoxen Katholieken verplicht waren, Rome en geheel Italië te bevrijden van
dat goddelooze Longobardische volk. Nog meer werkten waarschijnlijk vijftig duizend
goudstukken uit, die naar de Franken gestuurd werden door Keizer Mauricius, die bij
den dood van Tiberius door het gepeupel gekozen was, maar de keizerlijke macht toch
wel waardig bleek te zijn. De Franken schijnen op deze uitnoodigingen gereageerd te
hebben, maar zij werden zoo in beslag genomen door burgertwisten, dat zij na een of
twee woedende aanvallen zich lieten omkoopen, ditmaal door de Longobarden. Zoo
werd de Frankische verovering van Italië, die reeds mogelijk en dreigend scheen,
voorloopig uitgesteld.

Maar het verbond met de Franken had de hoop en den moed van de Byzantijnen in Italië
hernieuwd en het dringend verzoek om hulp, dat Paus Pelagius weder deed door middel
van zijn gezant of Nuntius (apocrisarius) Gregorius (den Groote), bewerkte de
verkiezing van een nieuwen en ondernemenden Exarch, Smaragdus (Smaraldo), die
weldra kwam met een aanzienlijke strijdmacht. De Longobarden daarentegen, die geen
Koning hadden, waren tot flinke samenwerking niet in staat, totdat ten slotte de
hertogen, die de oorzaak van hun eigen zwakte inzagen, een vergadering te Pavia (585)
hielden en Autharis (Autherik), den zoon van Clefi, als hun souverein aannamen, terwijl
zij gedeelten van hun inkomsten afstonden om de monarchie te begiftigen. De worsteling
tusschen de Longobarden en Byzantijnen werd nu heviger, vooral in het noorden en
oosten, waar twee belangrijke gebeurtenissen plaats grepen: de Isola Comacina, een
klein rotsachtig eiland in het meer van Como, dat zeer interessant is met het oog op den
oorsprong van de Longobardische architectuur en dat toen een sterke voorpost van de
Byzantijnen was, werd door de Longobarden genomen; Smaragdus daarentegen
heroverde in 588 de stad en de haven van Classe, waarover wij ons nauwelijks behoeven
te verbazen, daar de Byzantijnen meesters van de zee waren. Inderdaad moet men er zich
veeleer over verwonderen, dat de Longobarden die plaats negen jaren lang behouden
hebben, terwijl zij toch ingesloten waren tusschen de zee en de bolwerken van Ravenna.

Deze oorlog werd een tijdlang onderbroken door een groote overwinning van Autharis
op de Franken, die, weder door de Byzantijnen omgekocht, door den Splügen-pas de
landstreek rondom het Como-meer binnendrongen; volgens Paulus Diaconus had er
nooit zulk een slachting onder de Franken plaats gehad. In de tamelijk rustige pauze, die
op dezen slag (589) volgde, dong de Longobardische koning naar de hand van een
Beiersche prinses, Theudelinde, daar hij zich gaarne een bondgenoot wilde verwerven.
De geschiedenis van dit aanzoek en nog veel meer over Koningin Theudelinde of
Theodelinda, zooals de Romeinen zeiden, zal later verhaald worden.6 Dat huwelijk
verbitterde den Frankischen koning, Childebert zoozeer, dat hij wederom Italië
binnenrukte. Doch opnieuw werden de Franken gedwongen terug te trekken wegens
burgertwisten in hun land en de terugtocht werd verhaast door een geweldige
overstrooming van de Italiaansche laaglanden en vooral ook door de pest, die met groote
kwaadaardigheid uitbrak.

Paus Pelagius was een van de duizenden slachtoffers van die pest in 590. Hij werd
opgevolgd door Gregorius. Wij hebben reeds van hem gehoord als gezant van den Paus
te Constantinopel. In dit jaar 590 stierf ook Koning Autharis. Hij was waarschijnlijk een
van de beste Longobardische vorsten, ofschoon sommige onduidelijke uitdrukkingen
van Paulus Diaconus er op schijnen te wijzen, dat onder zijn regeering de Italianen nog
meer werden verdrukt dan onder de hertogen, zelfs tot slaaf werden gemaakt en onder de
Longobarden werden verdeeld. Maar dit is in strijd met andere plaatsen, waar hij spreekt
over den toestand van het land in dien tijd. “Men hoorde van geen gewelddaden,” zegt
hij “noch van eenige revolutionaire samenzwering; niemand onderdrukte een ander op
onrechtvaardige wijze, niemand plunderde; er waren geen dieven, geen roovers; ieder
ging zijn weg, waarheen hij wilde, zonder vrees of angst.”

Dat de Longobarden barbaren waren, die niet zoo artistiek waren aangelegd als de
Goten, is duidelijk; zij schijnen niet dat gevoel voor de zuidelijke kunst en litteratuur
gehad te hebben, dat zoo merkwaardig is bij Theoderik, Amalasuntha. en ook bij
Theodahad; maar zij waren blijkbaar niet zoo wreed. Geen der Longobardische vorsten,
zelfs Alboin niet, kan beschuldigd worden van de woeste wreedheid, die Theoderik en
Theodahad aan den dag hebben gelegd. Het wilde uiterlijk van de oorspronkelijke
Longobarden, hun linnen kleederen met bonte strepen, hun aan de achterzijde geschoren
hoofden, de ruige haren, die over hun gezicht hingen en hun lange baarden werden met
nieuwsgierigheid en schrik door hun naaste afstammelingen aanschouwd. In het
zomerpaleis van Theoderik, te Monza, dat Koningin Theodelinda liet herstellen en met
fresco’s versieren, waren deze barbaarsche stamvaders van het ras afgebeeld; zonder
twijfel wekten zij groote verwondering en afschuw, reeds lang voor de dagen van Paulus
Diaconus, die met eenige ontsteltenis de portretten van zijn voorvaderen zag en
beschreef. Maar ondanks dit ruwe uiterlijk en hun woestheid in den oorlog, waardoor
zelfs Narses gedwongen werd zich van hen, als bondgenooten, te ontdoen, was er in hen
een zachtheid, edelmoedigheid en ridderlijkheid verborgen, die dikwijls hun gevangenen
en onderdanen verraste. Deze eigenschappen komen duidelijk uit in de Longobardische
wetten van Rotharis en worden juist aangegeven in het grafschrift van een
Longobardischen krijger, dat Faulus Diaconus aanhaalt:

Terribilis visu facies; sed mente benignus

Longaque robusto pectore barba fuit.

De meer humane, ridderlijke en gevoelige trekken in het Longobardische karakter

maakten ongetwijfeld die samen-smelting met de overwonnen Italianen mogelijk, die
onmogelijk was gebleken in het geval met de Goten. De geleidelijke fusie van het
Longobardische met het Italiaansche ras bracht in den loop der tijden de nieuw-
Italiaansche kunst voort, die zich het eerst openbaarde in de Longobardisch-Romaansche
architectuur en later in de Toskaansche beeldhouw- en schilderkunst—ofschoon alle drie
uitwendig andere invloeden hebben ondergaan. Daarentegen verdween door de
gedeeltelijke verovering en het gebrekkig georganiseerde bestuur der Longobarden zeer
zeker de eenheid in het Italiaansche volkskarakter. Of die verdeeling gunstig was voor de
kunst, is een vraag, die gemakkelijker is te stellen dan te beantwoorden, maar dat het den
risorgimento van Italië voor vele eeuwen uitstelde, is onbetwistbaar.

25. S. Pietro, Toscanella.

Men zal zich herinneren, dat Alarik’s opvolger, Athaulf, zijn plan om een Gotisch Rijk te
stichten opgaf, omdat hij overtuigd was geworden, dat de Goten niet in staat waren
zichzelf te besturen en dat de eenige mogelijkheid om de orde te verzekeren lag in hun
eerbied voor de oude Romeinsche staatsinstellingen. Ook Theoderik en zijn dochter
Amalasuntha, moesten, niettegenstaande hun hevig verlangen om een Vereenigd Italië te
stichten, toegeven, dat Gotische invloeden hun te sterk waren. De Longobarden brachten
het evenmin tot stand, doch tengevolge van andere oorzaken. Zij waren Italië niet
binnengedrongen op verzoek van den Oost-Romeinschen Keizer, zooals Theoderik, en
evenmin koesterden zij zulk een eerbied voor het Keizerrijk. In hoeverre zij Romeinsche
wetten en Romeinsche ambtenaren afgeschaft hebben, kan men niet gemakkelijk
aantoonen; maar het is zeker dat zij in vele opzichten hun eigen regeeringsstelsel hebben
ingevoerd. Nu berustte dit stelsel alleen op mondeling overgeleverde wetten en paste
beter bij hun vroeger nomaden-leven dan bij de omstandigheden, waarin zij nu
verkeerden als heerschers in een land, dat gedurende vele eeuwen het centrum van
Europeesche beschaving was geweest, terwijl zij vergelijkenderwijze de minderen in
aantal waren. Bovendien was de contrôle, die de Longobardische koning over zijn
krijgslieden uitoefende zeer verslapt, daar zijn onderdanen over bijna geheel Italië
verspreid waren en er een groot aantal hertogdommen waren ontstaan, van welke
sommige weldra onafhankelijk werden onder het bestuur van vorsten, die erfelijke
dynastiën stichtten. Ook had de koning, ofschoon hij in geval van oorlog de hoogste
macht bezat, toch geen erfelijke rechten—een feit dat veel bloedvergieten en verwarring
veroorzaakte—en ofschoon zijn gezag aan de hertogelijke hoven vertegenwoordigd werd
door ambtenaren (gastaldi) die de financiën moesten controleeren, oorlogsbelasting
innen en toezicht houden op militaire zaken, werden deze meer en meer tegengewerkt
door de particuliere raadslieden en gouverneurs van hertogen (gasiadi en sculdasci).
Deze decentralisatie was de oorzaak, dat het Longobardische koninkrijk geen stevig
aaneengesloten staat werd. Maar juist deze onmacht om te heerschen leidde tot de fusie
met de verschillende Italiaansche volkeren en ofschoon het de vorming van een
Italiaansche natie uitstelde, is het toch zonder twijfel een zegen geweest.

Na den dood van Autharis in 590 verzochten de hertogen Theodelinda, wier karakter en
intellect indruk hadden gemaakt, een echtgenoot uit hun midden te kiezen. Nadat zij
consilium cum prudentibus had gehouden, zooals Paulus Diaconus zegt, koos zij Agilulf,
hertog van Turijn, die in de kerk van S. Ambrogio te Milaan gekroond werd. Zij
regeerden vijf en twintig jaar. Deze regeering is om verschillende redenen
belangwekkend. Agilulf wordt door sommige schrijvers beschouwd als de eerste
Longobardische koning, die, zeer zeker onder invloed van zijn verstandige koningin,
getracht heeft een stevigen en gecentraliseerden regeeringsvorm in te voeren. Bovendien
is deze periode voor dengene, die de Italiaansche kunst bestudeert, van bijzonder belang;
Gregorius de Groote is een indrukwekkende persoonlijkheid en zijn verhouding tot den
Longobardischen koning en koningin maakt het onderwerp nog belangrijker. Wij zullen
deze periode dus later uitvoeriger behandelen.

Agilulf vond drie geduchte vijanden tegenover zich, de Franken, Byzantijnen en

Romeinen, die hem gemakkelijk hadden kunnen overweldigen, indien zij eensgezind
waren geweest. Doch de Franken waren oneenig, want hun koninkrijk, Neustrië en
Austrasië, werd bewoond door de zeer verschillende Salische en Ripuarische Franken en
was bij den dood van Clothar (558) en nog eens bij den dood van Childebert (596) onder
eenige erfgenamen verdeeld. De Byzantijnsche macht was gehaat bij het Italiaansche
volk en werd bovendien belemmerd door de moeilijkheden in het Verre Oosten, waar de
machtige dynastie van de Perzische Sassaniden reeds ongeveer vier eeuwen het
Keizerrijk trotseerde en bleef trotseeren, totdat Perzië in 651 door de Mohammedanen
werd veroverd. De derde tegenstander van de Longobarden was het “hertogdom” Rome,
dat in naam nog onder den Byzantijnschen stadhouder stond7, maar inderdaad vrijwel
onafhankelijk was en zich vrijwillig gesteld had onder het gezag van den Paus, die zoo
krachtig mogelijk zijn burger-lijken en geestelijken invloed tegen de Longobarden, die
vreemdelingen en Arianen, aanwendde. Maar Agilulf, geleid door de raadgevingen van
zijn gemalin, slaagde er in de Franken tevreden te stellen, die het hem een tijdlang niet
meer lastig maakten, en zich staande te houden tegen de Byzantijnen, terwijl
Theodelinda zelf ten slotte de warme vriendschap won van den krachtigsten tegenstander
van haar gemaal, Paus Gregorius, die bekoord werd door het vooruitzicht de kettersche
Longobarden door haar invloed tot het Katholicisme te bekeeren.

Maar, voordat dit alles gebeurde, had Agilulf eenige jaren van zwaren strijd. Eerst moest
hij de ongehoorzame hertogen van Orta, Treviso en Bergamo tuchtigen. De laatste van
dezen, Gaidulf, had zich versterkt op de Isola Comacina, een vesting in het meer van
Como, die een paar jaren te voren door Autharis op de Byzantijnen was veroverd.
Agilulf bemachtigde het eiland, waar hij aanzienlijke schatten vond, joeg Gaidulf naar
Bergamo en nam hem gevangen, maar spaarde zijn leven en won aldus zijn vriendschap.
Daarna maakte hij zich gereed den al te onafhankelijken hertog van Benevento te
onderwerpen. De Longobardische hertogen van Benevento en Spoleto waren niet alleen
tegen hun Koning opgestaan, maar traden zoo dreigend tegen Rome op, dat Gregorius,
die, zooals hijzelf zegt, niet meer wist of hij een geestelijke herder was of een
wereldlijke vorst, na een vruchteloos beroep op Ravenna, een verdrag teekende met de
gens nefandissima Longobardorum, zooals hij hen gewoonlijk noemde.

Hierop besloot Agilulf Rome aan te vallen en marcheerde in het voorjaar naar het
zuiden. Te Rome ontstond zulk een ontsteltenis, dat Gregorius zijn preeken over
Ezechiel afbrak en het zwaard aangordde. Maar, hetzij de Romeinen, aangevuurd door
hun krijgshaftigen Paus te hevigen tegenstand boden, hetzij de malaria van de Campagna
te veel offers vroeg, Agilulf trok terug naar het noorden, na het land verwoest te hebben;
een paar jaren lang werd Italië noch door de Longobarden, noch door de Byzantijnen
meer geteisterd, want in het oosten ontstonden ernstige onlusten, door de dreigende
Avaren en door den dood van den Keizer Mauricius die door den usurpator Phocas was
vermoord.

In de latere jaren van Paus Gregorius’ leven werd de verhouding tusschen hem en den
Longobardischen koning zeer hartelijk, vooral door toedoen van Theodelinda, die als
Beiersche prinses in de Katholieke leer was opgevoed en een sterken invloed had op
haar gemaal. Of Agilulf werkelijk het Arianisme heeft afgezworen, is onzeker, maar hij
stond toe, dat zijn zoon Adelwald gedoopt werd (603) als Katholiek, zooals wij
vernemen uit Gregorius’ briefwisseling met de Koningin over zijn klein petekind. Dit
begunstigde de uitbreiding van het Katholicisme onder de Longobarden ten zeerste.
Doch het duurde nog eenigen tijd, voordat zij geheel en al afstand deden van hun
ketterschen vorm van Christelijken godsdienst.
Sinds 600 werd Gregorius hevig door jicht geplaagd en in 604 is hij daaraan gestorven.

Het schijnt dat de populariteit, die Agilulf en Theodelinda door hun krachtige en
verstandige regeering en het aanmoedigen van kunst en ontwikkeling gewonnen hadden,
hun het voorrecht van erfelijke souvereiniteit verschaft heeft, want in datzelfde jaar 604
werd hun zoon, die nauwelijks twee jaar oud was, tot troonopvolger uitgeroepen. Dit
gebeurde te Milaan, in de tegenwoordigheid van den gezant van Theudebert II, den
Koning der Franken, wiens minderjarige dochter tevens plechtig met den kleinen
Adelwald verloofd werd. Na deze gebeurtenis hooren wij weinig van Agilulf’s regeering
en behalve, dat het noord-westelijk Longobardisch gebied een tijdlang geteisterd werd
door groote horden van Avaren, een Tartaarschen stam8, schijnen de laatste tien jaren
van zijn leven rustig voorbij te zijn gegaan, daar er officieel vrede bestond tusschen de
Longobarden en het Exarchaat; en gedurende deze periode en nog meer in de volgende
tien jaren was Theodelinda bezig eenige van hare vele kerken te bouwen, haar paleis te
versieren, en kunstenaars, Katholieke prelaten en andere beroemde mannen aan haar hof
te verbinden.

Na Agilulf’s dood volgde Adelwald, nu twaalf jaar oud, een vurig Katholiek, hem op
onder het regentschap van zijn moeder. Van de gebeurtenissen tijdens zijn regeering
(615–25) weten wij zeer weinig. Door toedoen van Ariaansche edelen brak een oproer
uit, dat hem dwong te vluchten naar Ravenna, en Ariwald, een Ariaan, werd op den troon
geplaatst. Theodelinda bleef misschien een tijdlang bij haar zoon, maar het schijnt dat zij
teruggekeerd is en als gast aan het Longobardische hof heeft geleefd; want de nieuwe
koning trad in het huwelijk met haar dochter Gundeberga. Zij stierf in 628, Ariwald in
636, en Gundeberga moest, evenals haar moeder, een anderen gemaal kiezen. Zij koos
Rotharis (Rotherik of Roderik), den hertog van Brescia—een keuze, die voor het
algemeen welzijn gunstiger bleek dan voor haar persoonlijk geluk, want haar gemaal
was, evenals haar eerste echtgenoot, Ariaan en zoo weinig verdraagzaam jegens haar
Katholieke neigingen, dat hij haar gedurende vijf jaren streng gevangen hield in zijn
paleis te Pavia, waaruit zij werd bevrijd door tusschenkomst van Clovis (Chlodwig II),
den Frankischen koning. Zij wijdde het overige van haar leven aan goede werken en
volgde Theodelinda’s voorbeeld door de basiliek van S. Giovanni9 te Pavia te
herbouwen, waar zij haar beide echtgenooten liet begraven.

Rotharis regeerde zestien jaren (636–52). Hij is voornamelijk beroemd als de groote
Longobardische wetgever, maar in de eerste zes jaren van zijn regeering onderscheidde
hij zich door het Longobardische gebied uit te breiden over Ligurië tot de Frankische
grens bij Marseille, terwijl hij Genua en kleinere steden, Levanto en Sestri, op de
Byzantijnen veroverde. In 642 bracht hij, volgens Paulus Diaconus, den Romeinen en
Ravennaten een zware nederlaag toe bij de rivier Panaro met een verlies van 8000 man.
Zonder twijfel moet men zijn stoutmoedigheid en geluk toeschrijven aan de volgende
gebeurtenissen, waardoor de Keizer van het Oosten, Heraclius, verhinderd werd zich
veel met Italië te bemoeien.

In de eerste jaren van zijn regeering was Heraclius opgeschrikt door het optreden van de
Perzen, die in 615 Jeruzalem hadden genomen, vanwaar zij het Kruis (of wat er van over
was) meenamen, en die zelfs een verbond met de Avaren van Hongarije hadden gesloten
en Constantinopel bedreigden, zoodat hij er over dacht de regeering van het Keizerrijk
naar Carthago te verplaatsen. Maar hij schijnt plotseling een merkwaardige kracht en
moed te hebben ontwikkeld en het gelukte hem eindelijk de Avaren en ook de Perzen te
verslaan en hij ontnam hun niet alleen alle gevangenen, maar ook het buitgemaakte
Kruis, dat hij in triomf naar Constantinopel bracht en daarna weder naar Jeruzalem.

Dit gebeurde in 628–629, juist toen een nieuwe geduchte macht in het oosten begon op
te komen; want in 629, zeven jaren na de Hegira (vlucht) werd Mekka genomen en de
Heilige Oorlog door den grooten Arabischen profeet afgekondigd. Mohammed zelf stond
slechts vier jaar aan het hoofd van zijn legers. Hij stierf in 632; maar zijn Kaliefen
breidden hun veroveringen zoo snel uit, dat tusschen 634 en 640 Damascus, Antiochië,
Jeruzalem, Mesopotamië en Egypte gevallen waren en de Saracenen, zooals de
muzelmannen door de Grieken en Romeinen genoemd werden, weldra Europa
bedreigden.

Het nieuwe gevaar, dat zoo plotseling niet alleen in het oosten maar ook in het zuiden
was opgekomen, dwong Heraclius aan middelen ter verdediging te denken, want het was
niet meer mogelijk den zetel van de regeering naar Afrika over te brengen. Een nauwere
staatkundige band tusschen alle deelen van het Rijk was zijn eenige hoop en hij begreep,
zooals ook andere Keizers reeds begrepen hadden, dat de eenige kans om staatkundige
eenheid te bereiken berustte op godsdienstige overeenstemming; en misschien heeft de
gelukkige hierarchie van de kaliefen zijn vertrouwen in den βασιλεὺς καὶ ἱερεὺς (koning
en priester), de leer van de oostelijke Keizers, versterkt.10 Hij trachtte derhalve de
katholieke en kettersche sekten in het oosten te verzoenen (de laatste waren meer
geneigd gemeene zaak te maken met den Islam, dan de Drieëenheid en de “dubbele
natuur” van Christus aan te nemen), maar zijn Ecthesis of Verklaring van het Geloof
werd in Italië met verontwaardiging verworpen en, zooals Zeno en Justinianus en vele
anderen, ondervond hij, dat elke poging om sekten met elkaar te verzoenen en
godsdienstige overeenstemming te brengen den toestand eer slechter dan beter maakte.
Daarop schijnt hij door een nerveuze moedeloosheid te zijn aangetast en stierf in 641.
Ondertusschen had de Longobardische koning zijn macht in Italië uitgebreid en zijn
beroemden Code opgesteld.

Rotharis’ Code of Edict werd bekrachtigd in een groote vergadering gehouden te Pavia
in 643. Autharis had geregeerd door mondeling overgeleverde wetten, maar dit is de
eerste barbaarsche code, die in Italië is geschreven. Het is een soort barbaarsch Latijn en
bestaat uit 388 paragrafen.11 In den Proloog, die historisch de meeste waarde heeft, daar
hij de namen en betrekkingen van de Longobardische koningen tot 640 ongeveer geeft,
vertelt Rotharis ons, dat het zijn plan was al de oude wetten van zijn volk te verzamelen
en te verbeteren, en het overtollige er van te schrappen (d’entro delle leggi trasse il
troppo e vano, zooals Dante’s Justinianus van zichzelf zegt). Ofschoon men hier en daar
den invloed van het Romeinsche recht kan herkennen, is het over het algemeen
Longobardisch van inhoud en vorm; maar het geeft een paar doorslaande bewijzen van
verlichting. Zoo zijn de oude faida of vendetta en het duel afgeschaft en ook het
verbranden van heksen. Doodstraf wordt zelden opgelegd en geldboeten komen in plaats
van persoonlijke wraak—een bepaling, die zelfs in de Romeinsche wet onbekend is. De
algemeene strekking van de wetten is gericht tegen de grootgrondbezitters evenals onder
de Gotische heerschappij en ten gunste van de arme en arbeidende klasse. In dit opzicht
steekt Rotharis’ wetgeving zeer gunstig af bij den gelijktijdigen Byzantijnschen Code,
die de latifundia en ambtelijke afpersingen toeliet.

Na den dood van Rotharis in 652 volgde een donkere en onbelangrijke periode van
zestig jaren. Zijn zoon en opvolger Rodwald wordt na een korte regeering gedood.
Daarna is Aribert, een neef van Theodelinda, gedurende acht jaar koning, en verdeelt het
koninkrijk onder zijn beide zonen, Bertharis en Godebert, die Milaan en Pavia tot hun
residenties kiezen. De broeders krijgen twist en de jongste roept de hulp in van den
machtigen hertog van Benevento, Grimwald, die te Pavia komt, doch Godebert doodt, in
plaats van hem te helpen. Bertharis vlucht naar de Avaren en Grimwald wordt te Pavia
gekroond (662), terwijl hij aldus voor den eersten en laatsten keer het noordelijk gebied
met het tot dusverre onafhankelijke hertogdom in het verre zuiden vereenigt onder een
Longobardischen koning12.

Maar dit hertogdom van Benevento, dat hij aan de zorg van zijn zoon Romwald had
overgelaten, werd juist op dat oogenblik gevaarlijk bedreigd door de Byzantijnen; en om
de oorzaak hiervan te begrijpen moeten wij weder naar Rome terug. Hier hadden de
voortdurende twisten over leerstellige spitsvondigheden zulk een hoogte bereikt, dat de
Keizer, Constans II (642–68), ten slotte den Exarch beval Paus Martinus naar
Constantinopel te sturen, daar hij weigerde te berusten in een keizerlijk edict, dat alle
verdere discussie over de “dubbele natuur” van Christus verbood, en zelfs een Concilie
had bijeengeroepen, dat het edict als sceleratissimum veroordeelde. Paus Martinus werd
door Constans smadelijk behandeld en eindelijk gedeporteerd naar de Krim, waar hij,
naar men zegt, van honger is gestorven. Zijn opvolgers evenwel kwamen tot een
schikking met den Keizer, die zeer verontrust werd door de veroveringen der Saracenen.
Deze ongeloovigen hadden zijn vloot bij de kust van Klein-Azië verslagen en
verwoestten nu Sicilië. Er werd dus een leger verzameld om dat eiland te verdedigen en
in 662 vertrok Constans aan het hoofd van zijn strijdkrachten van Constantinopel en
landde bij Otranto, in de meening dat het een gunstige gelegenheid was om de
Longobarden van Zuid-Italië te overvallen; daarop belegerde hij Grimwald’s zoon in
Benevento. Maar Grimwald kwam hem snel ontzetten en versloeg de 20.000
Byzantijnen en Romeinen. Aldus redde hij zijn zuidelijke bezittingen13.

Grimwald sterft kort daarna en Bertharis komt terug en wordt tot koning uitgeroepen.
Van zijn regeering (671–88) weten wij zeer weinig. Zijn zoon Cunibert wordt door een
usurpator van den troon gestooten, maar later verslaat hij dien in een grooten slag bij de
Adda en regeert twaalf jaar (688–700). Wanneer Cunibert sterft, volgt zijn zoon hem op,
want het erfrecht schijnt nu erkend te zijn, maar hij wordt, omdat hij minderjarig is,
onder het regentschap van een edelman, Ansprand, gesteld. Weldra daagt er een andere
pretendent op, Ragimbert, die zijn eigen zoon, Aribert II op den troon plaatst. Nu moet
Ansprand vluchten naar Beieren, het vaderland van Theodelinda. Toen de usurpator
Aribert hoorde, dat hij plannen maakte om terug te keeren, nam hij zijn vrouw en
kinderen (behalve Liutprand, die ontsnapte en bij zijn vader kwam) gevangen, en
verminkte hen op afschuwelijke manier, door hun de oogen en de tong te laten uitrukken.
Maar de dag der wrake brak aan. Ansprand daalde van de Alpen af met een Beiersch
leger en velen, die den bloeddorstigen en vromen14 tyran haatten, voegden zich bij hem.
Aribert trachtte te vluchten, maar verdronk, toen hij met een zware tasch met geld de
Ticino wilde overzwemmen.
 26. S. Maria Maggiore, Toscanella.

Daarop wordt Ansprand tot koning geproclameerd, maar hij sterft in hetzelfde jaar (712)
en laat zijn zoon Liutprand als opvolger achter. De lange regeering van Liutprand (712–
744) is misschien merkwaardiger dan die van eenig ander Longobardisch koning,
gedeeltelijk wegens gebeurtenissen, die niet rechtstreeks in verband stonden met het
Longobardische hof, maar van gewicht waren voor Italië.

Deze gebeurtenissen, die van grooten invloed waren op de verhouding van het oostelijk
keizerrijk tot het Byzantijnsche Italië (als men dat zoo noemen mag), hingen ten nauwste
samen met godsdienstige, of liever kerkelijke vraagstukken. Wij moeten daar een
oogenblik aandacht voor vragen.
Reeds hebben wij gezien, dat de eene Keizer na den andere zich opwierp als een soort
van tegen-paus, die Concilies bijeenriep, die niet alleen verzoenende Henotica en
Ectheses afkondigde, maar ook uitdagende definities van de Drieëenheid en de Natuur
van Christus; wij hebben gezien, hoe zij de hoogepriesters van Rome afzetten, gevangen
namen, smadelijk en wreed behandelden. Doch nu werd de vijandigheid zoo hevig, dat
zij moest eindigen in een volslagen breuk tusschen het Oosten en het Westen. De pausen,
met geestdrift ondersteund door de Italianen, begonnen zich steeds minder te
bekommeren om de eischen van de Keizers en dit verergerde de verhouding tusschen het
Byzantijnsche hof en zijn Italiaansche provincies. In 691 deed Keizer Justinianus II een
Concilie in zijn paleis bijeenkomen. Paus Sergius weigerde de besluiten van dit Concilie
te onderteekenen. De Keizer zond toen Zacharias, zijn Protospatharius (hoofdman van
zijn lijfwacht) naar Rome om den Paus gevangen te nemen; maar de troepen te Ravenna
sloegen aan het muiten en marcheerden naar Rome; de Romeinen stonden op om hun
Paus te verdedigen en de Protospatharius moest zijn leven redden door zich in de
slaapkamer van den Paus, onder diens bed, te verbergen, totdat de woede van het volk in
zoo verre was bedaard, dat hij de stad kon verlaten. Justinianus wreekte zich later over
deze beleediging door een woesten aanval op Ravenna. De stad werd geplunderd, de
aartsbisschop blind gemaakt15 en naar de Krim verbannen.

Maar de opstand breidde zich uit en niettegenstaande een tijdelijke verzoening tusschen
den Keizer en den Paus (Constantinus I) en een feestelijke ontmoeting van deze twee in
Klein-Azië, hadden er toch ernstige onlusten te Rome plaats, waar de Exarch zelf
gedood werd; en de meeste steden van het Exarchaat maakten gemeene zaak met
Ravenna in een opstand tegen het oostenlijke Keizerrijk; dit was de eerste confederatie
van steden in de geschiedenis van middeleeuwsch Italië. Justinianus was reeds voor
eenige jaren (695–705) van zijn troon verjaagd en zijn wreedheden verwekten nu een
tweeden opstand. Hij werd vermoord door den usurpator Bardanes, of Philippicus, die
Ravenna en de Romeinen voor zich trachtte te winnen door den blinden aartsbisschop
terug te sturen en het hoofd van Justinianus over te zenden, waar allen zooals men vertelt
“met gretige verbazing naar keken.” Doch de gunst, die hij hiermede verwierf, was van
korten duur. Zijn kettersche neigingen en het zich aanmatigen van priesterlijke functies
veroorzaakten wederom de heftigste vijandelijkheden in Rome. De beeltenis van
Philippicus werd uit de St. Pieter en uit andere kerken verbannen; zijn naam werd niet
meer bij de mis gehoord; munten met zijn beeldenaar en onderschrift werden geweigerd.
Tot zulk een hevige uitbarsting kwam het, dat Philippicus werd onttroond en blind
gemaakt, en ook zijn twee opvolgers werden afgezet en gedwongen de tonsuur aan te
nemen. Daarna, in 717, beklom Leo III den troon, een dapper soldaat van oostersche
afkomst, daardoor bekend als Leo de Isauriër en nog beter bekend als Leo de Iconoclast.

Het volgende bedrijf van ons drama wordt voornamelijk gespeeld door Liutprand,
Keizer Leo en (tot 731) Paus Gregorius den Tweede, den krachtigen tegenstander van
den iconoclastischen keizer. De belangrijkste gebeurtenissen zijn de staatkundige en
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