Developing Mainframe Java Applications 1st

Edition Lou Marco download

https://ebookbell.com/product/developing-mainframe-java-
applications-1st-edition-lou-marco-979422

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.

Developing Expert Learners A Roadmap For Growing Confident And

Competent Students 1st Edition Michael Mcdowell

https://ebookbell.com/product/developing-expert-learners-a-roadmap-
for-growing-confident-and-competent-students-1st-edition-michael-
mcdowell-46192228

Developing Crosscultural Competence For Leaders A Guide Joseph J

Thomas

https://ebookbell.com/product/developing-crosscultural-competence-for-
leaders-a-guide-joseph-j-thomas-46223886

Developing The Heart Em Forster And India Nigel Collett

https://ebookbell.com/product/developing-the-heart-em-forster-and-
india-nigel-collett-46469960

Developing Language And Literacy Studies In Honor Of Dorit Diskin

Ravid Ronit Levie

https://ebookbell.com/product/developing-language-and-literacy-
studies-in-honor-of-dorit-diskin-ravid-ronit-levie-46518356
Developing Minority Language Resources The Case Of Spanish In
California Guadalupe Valds

https://ebookbell.com/product/developing-minority-language-resources-
the-case-of-spanish-in-california-guadalupe-valds-46562142

Developing Solutions For Microsoft Azure Az204 Exam Guide Discover The
Essentials For Success Paul Ivey

https://ebookbell.com/product/developing-solutions-for-microsoft-
azure-az204-exam-guide-discover-the-essentials-for-success-paul-
ivey-46664858

Developing Advanced English Language Competence A Researchinformed

Approach At Tertiary Level Armin Berger

https://ebookbell.com/product/developing-advanced-english-language-
competence-a-researchinformed-approach-at-tertiary-level-armin-
berger-46668028

Developing Expertise For Teaching In Higher Education Practical Ideas

For Professional Learning And Development Helen King

https://ebookbell.com/product/developing-expertise-for-teaching-in-
higher-education-practical-ideas-for-professional-learning-and-
development-helen-king-46715900

Developing An Iso 13485certified Quality Management System An

Implementation Guide For The Medicaldevice Industry Ilkka Juuso

https://ebookbell.com/product/developing-an-iso-13485certified-
quality-management-system-an-implementation-guide-for-the-
medicaldevice-industry-ilkka-juuso-46753882
 Cover

Y
FL
AM
TE

Team-Fly®
 Page i

Developing Mainframe Java™ Applications

 Page ii

This page intentionally left blank.

 Page iii

Developing Mainframe Java™ Applications

Lou Marco
 Page iv

Publisher: Robert Ipsen

Editor: Margaret Eldridge
Assistant Editor: Adaobi Obi
Managing Editor: John Atkins
Text Design & Composition: MacAllister Publishing Services, LLC

Designations used by companies to distinguish their products are often claimed as trademarks. In all
instances where John Wiley & Sons, Inc., is aware of a claim, the product names appear in initial
capital or ALL CAPITAL LETTERS. Readers, however, should contact the appropriate companies
for more complete information regarding trademarks and registration.

Copyright © 2001 by Lou Marco. All rights reserved.

Published by John Wiley & Sons, Inc.

No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form
or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as
permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the
prior written permission of the Publisher, or authorization through payment of the appropriate per-
copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-
8400, fax (978) 750-4744. Requests to the Publisher for permission should be addressed to the
Permissions Department, John Wiley & Sons, Inc., 605 Third Avenue, New York, NY 10158-0012,
(212) 850-6011, fax (212) 850-6008, E-Mail: PERMREQ@WILEY.COM.

This publication is designed to provide accurate and authoritative information in regard to the subject
matter covered. It is sold with the understanding that the publisher is not engaged in professional
services. If professional advice or other expert assistance is required, the services of a competent
professional person should be sought.

This title is also available in print as ISBN 0-471-41528-6

For more information about Wiley products, visit our web site at www.Wiley.com
 Page v

Contents

Preface xiii
Acknowledgments xvii
Part 1 Java Fundamentals 1
Chapter 1 Introduction 3
Java Trek 3
A New World of Objects 3
Reusability 4
Inheritance 4
Encapsulation 4
Stack Class 5
Polymorphism 6
Java and C++ 6
C++ 7
Java 8
A PL/I Version of the Bubble Sort 17
In Summary 20
Chapter 2 What Is Java? 23
A Brief History of Java 23
The World of Java Today 25
Java: The Programming Language 25
Java: The Object-Oriented Programming Language 25
Java: The Portable Programming Language 26
 Page vi

Java: The "Pointer-Less" Programming Language 27

Java: The MultiThreaded Language 28
IBM's Java Efforts 29
Java versus COBOL and PL/I: A Brief Look 29
In Summary 34
Chapter 3 Creating Your First Java Program 35
Installing the JDK 35
Is the JDK Installed Properly? 36
Compiling and Running the Program 37
Compiling and Running Java Programs: A Second Look 38
Watch out for Those Class Names 42
What Does a Compile Error Look Like? 43
Let's Look at the HelloWorld Program 43
Back to Our Program 46
In Summary 47

Chapter 4 The Sun Java 2 Basic JDK Tools 49

Basic JDK Tools 49
Appletviewer 50
jar 51
extcheck 53
java 54
javac 58
Javadoc 62
javah 66
javap 66
jdb
 68
In Summary 76

Chapter 5 Declaring and Defining Data 77

Java Primitive Types 77
A Few Words on Variable Typing 78
Variable Type Casting 80
Java Variable Typing 81
The boolean Primitive Type 82
The char Primitive Type 83
Integer Primitive Types 84
Floating Point Primitive Types 85
Character Strings in Java 86
Java Reference Data Types 86
 Page vii

Java Naming Conventions 88

In Summary 89
Chapter 6 Java Language Syntax 91
Miscellaneous Java Syntax Items 92
Java Source Code Is Case Sensitive 92
Java Statements Terminated by a Semicolon 92
Java Supports Multiple Comment Styles 92
Java Has No COPY or Include Statement 93
Java Has No Pointers 93
Java Has No Preprocessor 93
Reserved Words Exist in Java 93
Java Is a Free-Form Programming Language 95
Java Assignment Statements 96
Java Operators 97
Java Operators not Found in Mainframe Programming Languages 100
Java Arithmetic Anomalies 106
Mixing Primitive Types in Arithmetic Expressions 107
Loss of Precision when Dividing Integers 108
Shoddy Floating Point Arithmetic Results 109
Overflow and Keep Going 110
Java Program Control Statements 111
Loop Constructs 111
Interrupting the Normal Processing of Loops 117
Java Decision Constructs 119
In Summary 123
Chapter 7 Class and Object Representation 125
Anatomy of a Java Method 125
Visibility Modifiers 125
Other Modifiers 127
Returned Types Coded in Method Headers 128
Method Names and Argument Lists 128
The throws Exception-Name Option in Method Headers 128
A Word or Two about Java Packages 129
The package Statement 131
Anatomy of a Java class 132
Constructor Methods and Instance Variables 132
In Summary 147
 Page viii

Chapter 8 Encapsulating and Hiding Data and Methods 149

Encapsulation 149
Why Encapsulate and Hide Your Data and Methods? 150
How Do You Encapsulate Your Classes in Java? 153
A PL/I Example: Is This Object-Oriented Programming? 158
Using Accessor (Get and Set) Methods 161
In Summary 164

Chapter 9 Inheritance 165

Inheritance Defined 165
Same Classes, Different Inheritance Trees 166
Single Versus Multiple Inheritance 168
Y
FL
Example of an Inheritance Tree From the Java Libraries 169
AM

An Example: Implementing Bank Accounts 170

Code for Checking and Savings Account Classes 171
TE

Taking Advantage of Inheritance 174

Effects of Casting to and from Superclasses and Subclasses 181
In Summary 183
Chapter 10 Interfaces 185
What Are Interfaces? 185
Why Are Interfaces Useful? 186
What About Abstract Superclasses? 187
Creating Interfaces 188
Example: Implementing the Vehicle Types 188
In Summary 193
Chapter 11 Java Event-Handling Basics 195
Event Processing
Team-Fly®
 196
Java Graphical Interface Components 197
Java Events 199
The Java Event Processing Model 200
Variations on a Theme 1: Using Adapter Classes 205
Variations on a Theme 2: Using Top-Level Classes 206
Variations on a Theme 3: Using Inner Classes 207
In Summary 208
 Page ix

Chapter 12 Exception Handling and Thread Basics 209

What Are Exceptions? 209
The Java Exception Hierarchy 210
The Java Exception Class 211
Mainframe Programming Language Exception Handling 212
Mechanisms
The Java Exception Handling Mechanism 214
Throwing Exceptions 214
Throwing Exceptions - Continued 215
Declaring Potentially Thrown Exceptions 216
Catching Exceptions with try/catch/finally 218
Java Exceptions Summary 220
Thread Basics 220
Why Code Multithreaded Programs? 220
What Are Java Threads? 221
Executing Your Threads 222
Sample MultiThreaded Program 222
In Summary 227
Chapter 13 The Training Department Class Scheduler 229
System
The Application Defined 229
Application Options for the Students 230
Application Options for the Instructors 230
The User Interface 230
The OS/390 Mainframe User Interface 231
The Java User Interface 234
The Data Stores 237
 The Course Information File 238
The Class Information File 238
The Instructor Information File 238
The Employee Information File 238
Application Outputs 238
OS/390 IBM Mainframe Outputs 239
Java Outputs 242
Putting Together the Application 243
A Procedural Language Solution 244
A Java Language Solution 249
In Summary 254
 Page x

Part 2 Java In the OS/300 Mainframe Environment 255

Chapter 14 Overview of OS/390 Java 257
Infrastructure/Architecture
Software Requirements 257
Java Application Architectures 258
Java Software Components Versus Standalone Programs 259
Accessing OS/390 System Software 259
IBM Java Development Tools 262
In Summary 262
Chapter 15 Overview of OS/390 UNIX System Services 265
The Command Shell 265
The HFS File System 267
Working with HFS Files 268
Comparing MVS, UNIX, and OS/390 Concepts 270
In Summary 278

Chapter 16 Java and MVS Batch 279

Executing Java in Batch 279
Running Java Programs with BPXBATCH 280
Running Compiled and Linked Java Programs 284
Running Java Programs as Started Tasks 285
In Summary 286
Chapter 17 Java Record I/O Using the JRIO Package 287
What Is JRIO? 287
Contents of the JRIO Package 288
JRIO Interfaces 288
JRIO Constants 290
 JRIO Exceptions 292
Using JRIO 294
Directory and Dataset Naming Conventions 294
import Statements Needed for JRIO 295
Representing Record Structures 295
JRIO Coding Examples 298
Fetching Encoded Data from and Setting Data to Fields 311
In Summary 313
Chapter 18 Java, CICS, and IMS 315
Java and CICS 315
The CICS Transaction Gateway 315
Writing a JCICS program using COMMAREA 320
 Page xi

Java and IMS 321

What Is IMS Connect for Java? 322
In Summary 326

Chapter 19 Java and DB2 327

Overview of Java and DB2 for OS/390 327
Java Database Connectivity (JDBC) 329
Using JDBC 329
Java and SQLJ 334
Using SQLJ 334
Comparing JDBC to SQLJ 337
In Summary 337

Chapter 20 The Training Department Class Scheduler 339

System Revisited
The Application Feature Defined 339
The SQL Used in the Example 339
A Procedural Language Solution for "Display Class List Later Than 340
Entered Date" Option
Comments on the COBOL Solution 340
A Java Language Solution for "Display Class List Later Than 344
Entered Date" Option
The Code for a Single Class Retrieved from the Database 344
In Summary 347
Part 3 Java: Above and Beyond Other Programming 349
Languages
Chapter 21 Applets 351
A Bit of Background 351
Applications versus Applets 351
Coding the Web Page that Uses the Applet 352
 How an Applet Executes 352
In Summary 357

Chapter 22 Java User Interface Basics 359

Java GUI Component Libraries 359
Standard GUI Components 360
Java Containers 360
Another Example 366
In Summary 371
 Page xii

Chapter 23 Java File I/O 373

The File 374
Files (Datasets) in COBOL, PL/I 374
Files in Java 375
The Concept of a Stream 378
Streams in COBOL and PL/I 378
Streams in Java 380
In Summary 383
Chapter 24 The Java 2 Enterprise Edition Libraries 387
What Is J2EE? 387
Java on the Server 388
J2EE APIs 389
In Summary 394
Chapter 25 Remote Method Invocation 395
What Is Java RMI? 395
Java RMI Mechanics 396
Time for an Example 398
Step 1: Create the RMI Interface 398
Step 2: Code the Client Class 400
Step 3: Code the Server Class 401
Step 4: Compile the Interface, then the Server, and Then the Client 403
Classes
Step 5: Generate the Stub with the rmic Program 403
Step 6: Place the Stub Class File where the Client and the Server 403
Classes can Find Them
Step 7: Start the rmi Registry 404
Step 8: Create a Policy File 404
 Step 9: Execute the Server Class 405
Step 10: Execute the Client Class (Invoke the Remote Method) 405
Summary of RMI Steps 405
In Summary 407
Glossary 409
Bibliography 417
Index 419
 Page xiii

Preface
Developing Mainframe Java Applications provides big iron data processors with a reference and
learning tool they can use to write Java programs that run under OS/390. The thrust of the book is to
describe Java in the language of the mainframe professional and to show how such professionals
would develop Java applications for the IBM mainframe.

This is a "how-to" book, meant to impart rules and general techniques by drawing analogies between
the familiar and the new. Scant mention is made of the technical intricacies of the Java Virtual
Machine, garbage collection algorithms, "the taming of the threads," or other topics that deal with
Java internals.

Who Should Read This Book?

The main audience for this book is the mainframe programmer. These programmers have years of
experience on the mainframe and, although the likelihood is high that they have a wintel desktop (for
email, office productivity, and mainframe terminal emulation), they may not be adept at
Y
programming on anything but a mainframe.
FL

The book helps programmers learn Java programming, but the book has a wider audience than
AM

mainframe programmers. Systems analysts need to understand what Java is all about as well as
programmers. Management, especially first and second line managers, needs an understanding of
Java and a way of relating Java to their technical background.
TE

As an aside, the book assumes that the reader has no C or C++ programming experience, which
means that Java syntax, down to using curly braces, may be unfamiliar to the reader.

Team-Fly®
 Page xiv

The Book's Organization

Part 1, "Java Fundamentals," describes Java by comparing its language features with those of third-
generation procedural languages, such as COBOL and PL/I. The book describes Java as an object-
oriented programming language. Part 1 concludes by showing some Java code for an application and
comparing this Java code to COBOL and PL/I code that performs similar functions.

Part 1 contains chapters that discuss loops, decision constructs, declaring data, and
subroutine/function (methods, really) invocation–the language of procedural programming
languages. Other chapters discuss Class/Object representation, Inheritance, and Encapsulation–the
language of object-oriented programming languages. After the reader completes Part 1, he or she will
have a good grasp of how to use Java and how Java stacks up against familiar mainframe
programming languages.

The goals of Part 1 are as follows:

To describe Java by comparing and contrasting Java to familiar programming languages

To introduce the Sun Java JDK so the reader can create and execute simple Java programs on
his or her PC

To explain how Java implements the object-oriented programming language metaphor,

thereby showing how Java is different from PL/I, COBOL, and other languages used by the
mainframe programmer

Part 2, "Java in the Mainframe Environment," describes IBM's "Java Everywhere" strategy by
examining Java in the OS/390 environment. Each chapter covers how Java works with a particular
brand of IBM technology, such as CICS, DB2, or VSAM. Java code exploiting IBM-specific
technologies is included. The section concludes with Java code that accesses DB2 tables.

Part 2 explains shows how IBM has provided the Java programmer access to tried and true
technologies. After the reader completes this section, he or she will have a good grasp of how to
exploit Java in the OS/390 environment. The reader will be quite comfortable with Java; he or she
knows the syntax, how Java implements the object-oriented world view (from Part 1), and how to
use Java with familiar IBM technologies (Part 1).

The goals of Part 2 are as follows:

To explain how IBM has implemented Java on its mainframe environment

To explain how to use Java with the following IBM technologies:

CICS

IMS

Batch

VSAM
 DB2

To compare and contrast Java code with COBOL and PL/I code when using the previous list
of technologies
 Page xv

To describe IBM's JRIO classes and how the Java programmer on OS/390 uses these classes to
perform record I/O

To show application code using JDBC to access DB2 data

In the first two parts, the book shows COBOL and PL/I code that functions like the Java code in the
snippets and applications. However, this approach can only take the reader so far into the world of
Java. Simply put, Java is far more capable than COBOL and PL/I put together. Hence, the last
section of the book describes several key features of Java that are found only in Java.

Part 3, "Java: Above and Beyond Other Programming Languages," lightly touches on several Java
features and capabilities, such as applet creation, the Swing user interface classes, Java 2, Enterprise
Edition (J2EE), and Remote Method Invocation (RMI).

The goals of Part 3 are to describe some of Java's unique features, including

Applet coding

Java Native File I/O

Java GUI classes

The libraries constituting the Java 2, Enterprise Edition

The Remote Method Invocation (RMI) classes, which enable a Java programmer to execute
Java programs on other machines over a network

Conventions Used in This Book.

Code listings and outputs appear in a monospaced font, such as

public static void main( String[] args )

The first time a term is used in a chapter, the term is printed in italics.

Throughout the book, you'll find sidebar information that contains relevant information that doesn't
fit into the current context. Here's what a sidebar may look like:

You'll also encounter notes that augment the material preceding the note. Here's

THIS IS HOW A SIDEBAR TITLE MAY LOOK

And here is some text explaining the sidebar title . . .

what a note may look like:

This text may explain the material immediately preceding the note.

You'll also encounter tips that offer a shortcut or a solution to a common problem that relates to the
material you've just read.
This text may provide a shortcut or solution to a common problem.
 Page xvi

This page intentionally left blank.

 Page xvii

Acknowledgments
This work would not have been possible without the nearly infinite patience of the hard-working folk
at John Wiley & Sons. Of course, kudos go to my wife who had to witness and endure some strange
behaviors on my part during the completion of this work.
 Page xviii

This page intentionally left blank.

 Page 1

PART One
Java Fundamentals
 Page 2

This page intentionally left blank.

 Page 3

CHAPTER 1
Introduction

Java Trek
You are a mainframe programmer neck deep in COBOL programming. You cannot escape the siren
song of object-oriented programming (OOP). Every trade publication you peruse has articles from
industry pundits chanting the object mantra. In an evangelical manner, these new disciples of the
object faith quote chapter and verse from the missiles of Saint Booch and Saint Jacobsen. The
message is clear— you must adopt the Object Tao and righteously cast out the old demons of
procedural programming and structured design.

Okay, you got the calling. As a highly evolved mammal, your survival instinct kicks in. You sense
that you'd better find out what this object stuff is all about. If these harbingers of the object path are
correct, you could become obsolete before you become vested in your pension plan. Duly motivated,
you begin your quest for the truth about object technology.
Y
A New World of Objects
FL

The oceans of literature and the galaxy of Web pages contain many new terms and concepts. On your
AM

own, the brave new world of object technology can be quite daunting. In this exploration, you will
have an experienced guide to help you sort through the differences between mainframe programming
concepts and object technology— specifically Java programming.
TE

Team-Fly®
 Page 4

Object applications are not related sets of procedures acting on external data sources, but sets of
communicating objects. These objects contain all their needed data and procedures. The object view
of modeling software systems is based on the properties and behaviors of actual application entities.
Comparatively, the old software design model of creating separate data models and structure charts
seems archaic.

Reusability .
The object prophets make strong claims about software reusability. On the reusability issue, the
prophets speak with a single voice. They say that only by using object technology can you, the
programmer, create truly reusable code.

We all know that software reusability is not a new issue. Actually, software reusability has always
been the platonic ideal of programming. You've probably been very close to this ideal at times. It is
possible to write reusable code with a procedural language, but the reusability is achieved in spite of,
rather than because of, your programming tools and environment.

Is there really a programming environment out there somewhere that enables you to create reusable
code as a rule, not as an exception? Any culture advanced enough to produce cholesterol-free eggs
and breastfeeding devices for males must be advanced enough to produce this programming
environment. But do object environments truly assist the programmer in writing reusable code?

Inheritance
You may have read about that wonderful property of objects called inheritance. With inheritance,
you write code that implements some behavior for a group of similar objects, or a class. You create
subclasses based on some relationship— subclass A ISA superclass of B, for example. Once done,
the code that implements behaviors for the superclass is automatically known to the subclass. Yes, I
said automatically known to the subclass.

Well, this certainly sounds like a feature that would help me write reusable code. Think of a bank
account superclass with checking and savings account subclasses. You write code to implement the
withdrawal behavior for the bank account class. This code automatically becomes known to the
checking and savings account superclass. One routine, three classes. This beats the pants out of
reusability in the COBOL world-copying code in a separate member of your PDS and changing a
few lines. Do you see the real value in this inheritance stuff?

Encapsulation
You are likely to encounter the term encapsulation in any exploration of object technology. With
encapsulation, the data and code that implement behaviors in application objects are hidden from
other objects. The big idea is that, because other objects do not know about an object's internal data
and behavior representations, these other objects cannot change these representations. In short,
encapsulation provides a safety mechanism that prevents unwanted changes in an object's data.
 Page 5

How does this encapsulation stuff really help prevent unwanted changes? Think about the last set of
COBOL modules you wrote. Let's say you coded a list of parameters in the CALL/USING statement
of the calling module. Remember the unexpected behavior of the calling program? Remember trying
to debug the calling program? Remember how the called program changed one of the parameters
supplied in the LINKAGE section? Remember how difficult this problem was to locate? Suddenly,
like the light bulb flashing over the coyote's head in those silly roadrunner cartoons, you see the
beauty, majesty, and practicality of encapsulation.

The problem with the COBOL modules is that both the calling and called modules needed to know
the data representation of the parameters. Because the called module knew the data representation,
the module contained code that changed the parameter. At times, you count on the ability of the
called COBOL module to change the parameter's value and write code to make wanted changes.
Sadly, you can slip and write code that inadvertently changes passed parameters. The calling module
has no knowledge of these changes and does not execute correctly.

Owing to encapsulation, an object application can never suffer this fate. What an object doesn't
know, an object cannot change. Data contained on objects is safe from unwanted tampering from
other objects.

Stack Class
Let's say Joe Programmer wrote a PL/I program a while back. Being a wise guy, he implemented a
stack as a controlled data structure (a controlled data structure in PL/I— declared with the storage
class CONTROLLED— means the PL/I program can dynamically allocate memory for the structure
with the ALLOCATE statement). All routines that used the stack had this controlled structure
declaration. Joe's code worked; he was immensely pleased with himself. When the team lead
scheduled the code walk-through, he couldn't wait to demonstrate his superior knowledge of the PL/I
language.

Well, it turns out that Joe should have known that the project lead is not nearly as well versed in PL/I
as he is. When she saw the stack and its controlled allocation, she barked, "What is this?" With pride,
Joe described the intricacies of PL/I's controlled storage class. A scowl slowly spread over the
project lead's face. She was clearly not impressed with Joe's code and asked him to rewrite the stack
code, using a more conventional data structure. When Joe meekly asked for a suggestion, she
whipped out an array representation on a white board. Joe slinked back to his cube to make the
required changes.

Joe hunted down every module that accessed the stack because he had to change every one. He had
to change the POP, PUSH, and ISEMPTY routines, too. What a pain. Maybe Joe should have
conferred with Hagatha, the team lead, before he embarked on his coding journey.

If this application were done in an object language, Joe would need to change only the stack class.
All objects communicating with the stack, being ignorant of the stack's data representation, would
not have to be changed.

Another bonus— because of inheritance, all subclasses of a changed class automatically know of the
change. Joe need do nothing to implement a new data representation or a behavior in the subclasses.
 Page 6

By now, you should be firmly convinced that this object stuff is definitely worth the admission price.
This class/object representation, combined with inheritance and encapsulation, makes for powerful
code. Many more object technology wonders are there to unearth— let's keep digging.

Polymorphism
What if you could send the same message to different objects and each object would invoke the
appropriate behavior in response to the message? Remember that object applications are
communicating objects, not separate function/module calls acting on external data sources. The term
message makes sense in object-speak. Objects communicate by issuing messages to each other. The
message invokes some behavior that you have implemented in code. The thrust of polymorphism is
that each object responds to a message according to its understanding of that message.

There is practical, everyday truth in this. How do people respond to messages? Do we not respond in
our own way? Don't different people (and dogs, for that matter) respond differently to the same
message? When you become accustomed and attuned to this concept, the object world-view of
polymorphism seems as natural and proper as wearing underwear.

You may think that object technology is recent, say 1990s, technology. However, object technology
has been around since the 1970s. It may be strange to realize that object technology is older than
your dog. It may be older than your significant other. It is certainly older than some of the big iron
technology like DB2 and REXX that you've been using for the past 15 years.

Java and C++

By now, you have absorbed the essentials of an object system: class/object representation,
encapsulation, inheritance, and polymorphism. That's good. But, as a programmer, you may be
naturally curious about programming languages that implement these essentials. It seems that every
programming language has an object flavor (even COBOL.) However, the most common are the
C++ and Java programming languages. Let's investigate these two languages.

Your first impulse may be to rush off to a bookstore and purchase some of the uncounted number of
books about these languages. Because most programming books are 40-plus dollars, a few books
equate to big bucks. After all, you're a programmer, not a drug dealer or a dentist. Three books are
the equivalent of food for two weeks. By now, the at-home crowd must be weary of eating beanie-
weenies. Maybe you can make do without the books for now.

Internet searches reveal a wealth of links on C++ and Java. There are lots of C++ and Java source
code, lots of terminology and acronyms, and lots of talk about UNIX on the net. There's little on how
object technology is used by companies in certain industries— notably yours. To find out how this
object–C++–Java technology is used by your industry and your company will take more research.
 Page 7

Perhaps a direct approach is in order. Why not talk to folks in your organization to learn if anyone in
the same building is using object technology? You may meet a few object converts under your
corporate roof. Perhaps some of these object practitioners can shed some interesting light on C++
and Java usage within the company.

C++
Joe, the first object practitioner you meet, uses the C++ programming language. This programmer
swears with the fervor of a recent ex-smoker that any object programmer worth his salt uses C++. He
gleefully takes the time to explain his ardor for C++.

Joe tells you in a pompous and annoying manner that C++ supports all the features of object
programming: class/object representation, encapsulation, inheritance, and polymorphism. He
explains that C++ is a hybrid object language— a language built upon an existing procedural
programming language (C, in this case). He boasts that his C experience and knowledge of object
concepts enabled him to start coding almost immediately.

He continues by explaining that C++ supports multiple inheritance. Multiple inheritance enables a
subclass to inherit data attributes or behaviors from more than one superclass. Of course, he grins,
multiple inheritance is more flexible than, and superior to, single inheritance.

Because of your hard work and research, you understand what Joe is talking about. You wax with
glee as you realize that you can talk the object talk. You can't wait to walk the object walk.
Impatiently, you ask him to show you some C++ code.

As your eyes scan the C++ code, your shiny, gleeful face quickly sours to a dull, woeful puss. You
can't understand any of this stuff. This code could be Babylonian cuneiform writing as far as you're
concerned. You can't believe that under this mess is essentially code in a procedural language.

You recall the first time you saw PL/I. You didn't understand the nuts and bolts, but you had a good
understanding of what the code did. Your COBOL background was good preparation for
understanding PL/I. Unfortunately, this C++ stuff looks pretty cryptic.

The C++ programmer senses your state of overall confusion and asks you how much C experience
you have under your belt. There may be lots under your belt these days, but none of it is C
programming experience. You're a COBOL and PL/I programmer. Remember when you had to learn
pointer use in PL/I? You finally grasped that a pointer is merely a four-byte address. Joe shows you
pointers to character strings, pointers to integers, and (gasp!) pointers to pointers, explaining that,
although these pointers are addresses, they are all different data types. You thank the Joe for his time
and mosey on to your cubie. Alone with your thoughts, the horror of learning C++ seeps in. You
thought object programming would be easier than conventional procedural programming. This C++
stuff seems to be procedural programming at its worst.

At lunch, you mention to a chum that you're looking into C++ programming. This chum happens to
know a thing or two about C++. He has some C++ information obtained from a vendor of Macintosh
software development tools. He believes that this information is Mac-specific. But the C++
information from the Mac vendor made the
 Page 8

stuff you gleaned from the pointer-happy programmer earlier today read like a nursery rhyme. Here's
what you read:

When you call the function "MYSTREAM.read()", it normally returns a reference to the stream object
itself, that is, . MYSTREAM. This is so you can chain these functions together, like this:

MyStream.read (MyVar1).read(MyVar2).read(MyVar3)

But when you call "MYSTREAM.read()" from a function that expects an integer, the compiler performs
some "sleight-of-hand" and actually returns MYSTREAM.good()" as the function result.

So this is what the world of programming has evolved to?

Desperately, you rifle through your notes. You recall hearing through the mill that your corporate
training department may be developing courses on Internet technologies. You recall the instructor of
the last class you took, oh so many moons ago. Why not give her a call?

Java
Jane, a corporate instructor, is developing a course on the Java programming language. Java, she
excitedly explains, is part of a suite of technologies that enable a programmer to write a program
once and run it on any platform— even on the Internet. Great— you have to deal with a suite of
technologies to learn and use Java. This is just what you need, right? Before you get all steamed up
over technology suites and the like, your Java guide says that Java has use and value as a
programming language aside and apart from Internet; Java is much more than the "Applet language
of the Internet." Upon hearing this, you regain your composure.

Jane starts to talk about Java's inheritance mechanism. When you comment on C++ and its support
for multiple inheritance, she audibly snickers. Jane mentions that with multiple inheritance, you have
no straightforward way of knowing the origin of some inherited behavior. Her point is that an
application developed with multiple inheritance may ease initial class creation and application
development but could make application maintenance a nightmare. By now, you assume that Java
supports single inheritance only.

However, when you point out the textbook advantages of multiple inheritance, she audibly snickers
again. Your Java guide points out that she never got to explain Java's inheritance mechanism to you.
She tells you that Java supports single inheritance inas-much as every object is created from a class
that has one and only one superclass. However, the Java designers were well aware of the limitations
of single inheritance as well as the pitfalls of multiple inheritance. She explains that Java's
inheritance mechanism is unique; a Java class has the ability to inherit behaviors from several classes
but only one of these classes is the superclass. The inherited behaviors that do not belong to the
superclass are defined to the class by an interface.

You are puzzled because this sounds like multiple inheritance. Jane explains that Java supports two
separate hierarchies: a Class hierarchy, which defines the
 Page 9

class/superclass relationship, and an Interface hierarchy, which enables a class to implement

behaviors from classes not contained in the class hierarchy. In JavaSpeak, a class extends its
superclass and (optionally) implements one or more interfaces.

Well, this still sounds like multiple inheritance but you get her gist: A Java class has one bonafide
superclass but can implement behaviors from other classes. When you comment that a Java class can
inherit method implementations from only the superclass, and the class must provide
implementations for all methods used by an interface, your guide approvingly nods. She suggests
that you not get hung up on the differences between a superclass and an interface yet.

Jane explains that the lazy C++ programmer could write code that doesn't do the cool object stuff,
like encapsulation or inheritance. The lazy C++ programmer could write C++ code to be completely
procedural. At first, you might be tempted to believe that this ability of C++ to wear two hats, so to
speak, is a good thing. Yeah, but you saw C++ code, remember? C++ is not your idea of procedural
programming.

Actually, she says, a common view of C++ is that C++ is a better version of C; C++ was developed
to overcome the deficiencies of the C programming language (of which many exist). Now, you don't
know C, and don't care to learn, but you see the wisdom of her words. You get the drift that C++ was
developed from C as opposed to being developed from the ground up. C++ is a better C, not a
language necessarily engineered to support object orientation.

The Java guru continues. She states that you could do procedural programming in Java, but anything
of substance, like file or database I/O, requires classes and objects and inheritance— the stuff of
objects. Although you could force a Java program to be procedural and not use object-oriented
features, your program probably could not do anything useful.

Java is a modern language, she says. Java designers at Sun Microsystems had definite ideas in mind
when Java went to the drawing board. Considering that Java was released in late 1995, you can tell
that this technology is hot.

Some Java Code

Perhaps you should look at some Java code before she waxes into a Java frenzy. Jane presents an
implementation of the bubble sort in Java as shown in Listing 1.1.

Looks like that C++ stuff you saw before. You see those ++, --and the braces {}. At least there's a
use for those braces now. For the moment, you're not impressed with the syntax of this "modern"
language.

My friendly Java instructor explains that syntax is syntax; after all, isn't it all a matter of what you're
used to? Of course, as a programmer, you take the time to explain that programming language syntax
parallels written language inasmuch as both need to be read, written, and understandable. You take
the time to explain that language replete with punctuation is more difficult to digest than language
without excess punctuation. However, you are a gracious and classy person and you readily yield to
your Java Guide's point about syntax.

Life, and programming, is too intense to sweat the small stuff. Jane says her time is short and she'd
rather not go over too many syntax details right now; she'd rather stick to explaining Java concepts
that may be daunting to a Java wannabe like you.
 Page 10

class BubSort { //1

public static void main( String args[]) { //2
int anarray[] = {3,10,6,1,2,9} ; //3
sort( anarray ) ; //4
for (int idx = 0; idx < anarray.length; idx++ )
System.out.print1n( anarray[ idx ] ) ;

} //5

static void sort(int a[]) { //6

for (int idx1 = a.length; --idx1>=0; ) {
boolean swapped = false;
for (int idx2 = 0; idx2<idx1; idx2++) {

if (a[idx2] > a[idx2+1]) {

int temp = a[idx2];
a[idx2] = a[idx2+1];
a[idx2+1] = temp;
swapped = true;

}
if (!swapped)
return ;
}

} //7

} //8
Listing 1.1 The infamous bubble sort.

She first explains that the double slashes denote a single line comment; the slash-asterisk
combination denote a multi-line comment. She mentions that Java is case sensitive. That is, the
variable names myPay and MYPAY are different variables. Like a chanteuse breaking into song, she
starts to explain pieces of the program by the numbers. She says that even this small example
contains many Java features; she has time to cover only a few points. You express your gratitude and
ask her to proceed.

She explains the big picture by stating that the program has a main method that declares and
initializes an array of numbers, calls a sort method, and prints out the sorted array. The sort() method
implements our friend, old Mr. Bubble. Both the main()
 Page 11

and sort() methods are part of a class called BubSort. You may understand her reasoning; it is the
way you might code an example to illustrate a sort or features of a programming language.

The Java Program-By the Numbers

She starts to discuss the numbered lines.

Line //1 is the class declaration:

class BubSort {

Every Java file containing Java source code has a class declaration. The class declaration should
match the name of the dataset. In this case, the dataset name would be BubSort.java.

Line //2 is the declaration for the main() method:

public static void main( String args[]) {

Every Java application has a main() method. Now, she continues, this doesn't mean that every dataset
with Java source code has a main() method. Some Java source files have support datasets. And, she
adds, Java applets do not have a main() method.

Yes, applets. You recall reading about Java applets— small programs that execute within a Web
page. But you withhold your questions because you're in the middle of dissecting this bubble sort.

Speaking of which, Jane returns to the explanation of line //(2). Well, those words public static void
have meaning. She says it has to do with the visibility of the method (that's the public keyword)— the
method does not belong to any particular object (that's the static keyword) and what the method
does, or does not return (that's the void keyword).

Yes, she says— Java has keywords, or reserved words, like most programming languages.

Line //3 is a Java array declaration:

int anarray[] = {3,10,6,1,2,9} ;

The first keyword, int, is the data type of the elements of the array. You gather that the keyword int
is short for integer. She tells you that you may be right, you may be wrong— it depends on what you
think an integer is.

You say that the definition of an integer is operating-system dependent. On some platforms an
integer is four bytes, type binary, unsigned. On other platforms, an integer is four bytes, type packed,
signed. You say the int declaration depends on the platform you are writing Java on.

Java and Platform Independence

Well, your long-suffering and humble Java instructor certainly has a thing or two to say now. She
asks you if you've read anything about Java. If so, she claims, you'd know
 Page 12

that Java doesn't care for operating system particulars such as primitive data type byte sizes and
formats. The beauty of Java is that Java was designed to be source code compatible across multiple
platforms. The same Java that executes on a Wintel box will run without modification on a
Macintosh, an IBM RS6000 running AIX, or on an IBM mainframe running OS/390.

You chortle under your breath. Seems you've heard this one before. You recall how C was the
ultimate cross platform software development tool. C was the "be all, end all" of programming
languages. Now, you never became proficient in C, but you work in data processing, right? If C lived
up to one-tenth of its promise, you would have heard about it, right? Well, you still spent your time
coding EVALUATE statements and looking at Abend-Aid dumps, right?

Apparently sensing your disbelief over her words, she explains that Java achieves this cross platform
execution boast by compiling into a platform-neutral format called bytecodes. A platform-specific
piece of software called a Java Virtual Machine translates the bytecodes into platform-specific
machine code. Hence, the Java compiler does not have to care about operating system details; the
Java Virtual Machine takes care of that. And the Java Virtual Machine is platform-specific.

You see the beauty in this approach. The Java programmer really does not have to know how big
integers are or how booleans are represented on a particular platform. All the Java programmer needs
to know is how big Java integers are or how Java represents booleans. The Java Virtual Machine
takes care of the mundane platform-specific details.

Oh, back to the question, how large are int data types? She says that Java uses four byte signed
binary integers.

Java Objects and Primitive Types.

A typical Java declaration is the data type or class name followed by the variable or object name. In
line // 3, the identifier anarray is the name of the declared array. My guide says that Java variables or
objects can have other attributes attached to them, but for now let's keep things straightforward.

You are a bit puzzled over this "variable or object" thing. Isn't Java object-oriented? Isn't everything
you use in Java an object instantiated from a class? Isn't that how this object-oriented stuff works?

She reminds you that Java is a new language. Over the years, computer scientists have learned a
thing or two about programming languages. For example, a "pure object" language like Smalltalk
would never, never, ever, ever permit you to use anything but objects. In Smalltalk, even the number
2 is considered an object. Some computer scientist types have concluded that this "everything is an
object" approach doesn't work for some applications. A programming language runtime must keep
track of memory allocated for objects (among other things). Most object languages need custom
routines to compare objects for equality and to read and write objects. In short, using objects is a lot
of work for a computer.

An example of an application type that is not well suited to object technology is the "number
crunching" type of applications used in science labs. Remember those old Fortran programs with five
nested loops? To use an object-oriented system to perform
 Page 13

numeric calculations seems a bit wasteful of computing resources considering what the system may
require to keep track of all the objects used. Of course, this is not to say that you couldn't code
application of this type in object languages.

Java enables a programmer to use primitive data types instead of objects. For example, this example
uses few objects. The array elements, the array indices, and the boolean flag are not objects; these
program elements are variables. The array declared on line //3 is what she calls a reference data type.

As an aside, Java arrays are very object-like. Arrays may be assigned to variables of type Object
(Object is the root class in Java, the class at the top of the hierarchy). But, she continues, Java
practitioners do not consider an array an object.

You mull this over. You sort of understand that the array declaration does not declare an object.
Objects use methods and there's been no talk of methods attached to this array. This array is pretty
much like an array used in COBOL or PL/I.

You believe that some of this object stuff looks really good "on paper" but often fails the real world
test. You've read that this object stuff is decades old. Let's face it— if this technology were so great, it
would be more widespread. A mixture of old-fashioned, procedural programming and this object
stuff could be just what we need in data processing, perhaps.

Possibly, says your Java guide. She continues to discuss the sort example.
Y
FL
Back to the Java Bubble Sort
AM

Back to line //3. Note that this statement initializes the array. In Java, arrays start with index 0, not 1
like some programming languages. Just something to keep in mind, she quips.
TE

Jane comments that she has to wrap this up soon; she has meetings to attend and memos to write. She
starts to discuss line //4:

sort( anarray ) ;

Here's where you invoke the sort() method and pass the array argument. This is not tough, new, or
strange. This is programming!

Where are the objects? Where are the classes? Java is object-oriented, right? Of course, Jane says,
but we don't need object stuff to do a bubble sort. Java lets you do some things procedurally.

Take a look at line //6:

static void sort(int a[])

The sort method has a special keyword, static, which means that you need not attach this method to
an object. Sometimes you just need a piece of code that does not depend on any particular object's
data. The bubble sort is like that; the sort is entirely parameter driven. What we need is a way of
telling Java that we want this method but don't want to create objects and attach the method to the
object. The static keyword does just that.

She explains that if she (or anyone) needed a bubble sort, she could use the sort method in the
BubSort class. First, the programmer would remove the main() method from BubSort.java; Listing

Team-Fly®
1.2 shows the new BubSort.java.
 Page 14

class BubSort {

static void sort(int a[]) {

for (int idx1 = a.length; --idx1>=0; ) {

boolean swapped = false;
for (int idx2 = 0; idx2<idx1; idx2++) {

if (a[idx2] > a[idx2+1]) {

int T = a[idx2];
a[idx2] = a[idx2+1];
a[idx2+1] = T;
swapped = true;
}

}
if (!swapped) return ;

}
Listing 1.2 Bubble sort in its own class.

As you can see, the sort() method is unchanged but the class does not have a main() method.
Presumably, the class that will use the sort() method has a main() method, and only one main()
method per Java application is allowed.

Assuming the BubSort class is on the same directory as the UseBub class or in what Java mavens
call the classpath, when you execute UseBub, the Java runtime will pull what UseBub needs from
BubSort. In particular, UseBub needs the sort() routine. Check out the lines marked with //*** in
Listing 1.3.

BubSort.sort( anarray ) ;
BubSort.sort( anarray2 ) ;

The sort() method is qualified with the class that contains the method.

You ask about the other statements in the original bubble sort program— the one from Listing 1.1. In
particular, you ask about these curly braces. The rest of the numbered statements are braces that
close off blocks. She explains that Java uses the curly braces as block constructs. The block construct
helps to define variable visibility. Also, the block construct is required when more than one
statement follows an if statement or a loop construct. Even a small Java program can contain
numerous braces, she says.

The visibility of these variables may be defined by curly braces; variables declared within a pair of
braces are known within those braces. Some cases exist where a variable is declared within a
statement. In this case, that variable is visible only in that statement. She directs you to the following
statement:
 Page 15

class UseBub {

static void printResults (int sorted[]) {

for (int idx = 0; idx < sorted.length; idx++ )

System.out.println( sorted[ idx ] ) ;

public static void main( String args[]) {

int anarray[] = {3,10,6,1,2,9} ;

BubSort.sort( anarray ) ; //***

int anarray2[] = {12, 4, 35, 1, 55, 76, 3 } ;

BubSort.sort(anarray2) ; //***

printResults( anarray ) ;

printResults( anarray2 ) ;

}
Listing 1.3 Invoking the bubble sort from a class.

for (int idx = 0; idx < anarray.length; idx++ )

System.out.println( anarray[ idx ] ) ;

This is a single statement. The variable idx is visible in this statement only.

She catches you staring at this statement. She catches you in mid-thought and explains that this is a
looping construct that prints an array value to the default output stream. She also says that she is
quickly running out of time and has to pick up the pace.

After a pregnant pause, you meekly ask her where the pointer references are. You figure that
"modern" languages like C++ and Java are replete with pointers. You cite your discussion with the
C++ programmer and what he told you about pointers in C++. What about pointer use in Java, you
ask?

With an impish grin, she tells me that Java does not use pointers. No pointers? None, she answers.
Java is able to do what every programming language does, and more, without the use of explicitly
declared and manipulated pointers. A Java programmer cannot declare a pointer or access the
starting address of a data structure in any way.

Well, well— no pointers in Java! That one statement alone is music to your codeweary ears. You start
to believe that these Java engineers at Sun really know their stuff.
 Page 16

Meet the Sun JDK

You ask her how she compiles and links this program. She reminds you that Java compiles into a
platform-neutral data format called bytecodes. You knowingly nod in agreement. She is using a
WinTel box to compile her Java source. She tells you that the marketplace is rife with Java tools and
serious Java folk have an arsenal of tools to help with Java development. For now, she explains,
she'll use the standard tool suite, or Java Development Kit, available from Sun Microsystems (the
developers of Java). She opens up a DOS window and compiles the program. Next, she executes the
program. Figure 1.1 shows the DOS window after compiling and running the bubble sort.

The javac command invokes the Java compiler. In truly sparse computer geek fashion, a successful
compile provides no diagnostics. A successful Java compile produces a class file— in this case,
BubSort.class. Next, the java command executes the program. The java command passes the
previously created class file, in Bytecode format, to the Java Virtual Machine for execution. The
result of the execution is seen in the DOS window previously.

Well, well, you think. This certainly beats the pants off of submitting batch compiles and links. You
enter source code in an appropriately named dataset, switch to a DOS window where you do your
compiles, and repeat until you get a clean compile. Next, you execute your program in the very same
window.

You note that you need a program to execute your Java program. You ask her where the executable
file is produced by the linker. Actually, you ask her where and how she did the link. Your Java guide
tells you that she did not link the Java code; she did not produce an executable. The java compiler,
javac, produced a class file composed of bytecodes. The bytecodes are interpreted by the java
command.

You ask her how much these Java tools cost— the compiler (javac), the program that executes the
bytecodes (java), and the Java Virtual Machine. You would like to get a copy on your machine.
When she replies that these tools are free, you slip off your chair. Free? How can this be? Our shop is
used to paying a fortune for any software tool.

Figure 1.1 DOS window after compiling and running the sort.
 Page 17

My guide explains that Sun provides a base set of tools, which includes the compiler. Other vendors
committed to Java provide Java Virtual Machines, or JVM's, bytecode interpreters, and applet
viewers. She tells you that the standard Java Development Kit, or JDK, includes a documentation
generator (javadoc), a java debugger (jdb), other tools dealing with system security (javakey), and a
way of disassembling Java classes/bytecode into Java source (javap). She adds that serious Java
developers have visual tools like the rest of the world and these visual tools cost money but anyone
can compile and execute Java programs with the freebies included in the JDK.

You are a bit stunned over this, and, rightfully so. Now you get a glimpse into the hype, the
excitement that Java has caused in the computing community. This Java stuff is the closest thing to a
standard you've heard of. To top it all off, the development tools are free. Of course, you're still
reeling over the phrase, "No pointers in Java."

Your very patient Java guide, and teacher, pauses once again to catch your feedback. A grin slowly
washes over your face as you realize that you understand nearly everything she has said. The
program you've examined makes sense in a macro sort of way. However, you're battle-hardened
enough to realize that every programming language has its quirks and oddities and that the language
syntax just have to be learned. In the middle of your reflections, something odd catches your eye.

You can't help notice your humble Java guide leafing through some IBM language reference
manuals. When you ask her what she needs to know, she replies that she would like to know a bit
more about programming language constructs in COBOL, PL/I, and REXX. She wants to compare
and contrast some Java constructs with constructs from more familiar languages.

What a great idea. She likes that you find merit in her idea. She glances at the wall clock, quickly
stands up, grabs a binder, and tells you she has to go. You want to show your appreciation for taking
the time and energy to show you stuff. As she shrugs off your offers to buy her coffee or lunch
someday, you hit upon a good idea: You tell her that you could write the sort program previously in a
commonly used IBM language. She agrees that your idea has merit. You ask for a reference for Java
syntax, which she gladly provides. You strut off to your designated work environment to fulfill your
promise.

A PL/I Version of the Bubble Sort

You decide to have lunch at the cubie (not all that unusual, right?) and pound out some code. You
wisely spend some time perusing the Java reference material. You see that the Java JDK comes with
packages. These packages are collections of related classes that perform varied tasks from database
and file I/O to mathematical computations to network data movement to graphical user interface
development. You get the idea that a big part of Java software development is knowing what classes
are already available for your use. The over 1,000 classes, constants, interface definitions, and
exceptions available seems daunting. You put that part of the reference down for now and decide to
stick with scrutinizing the syntax to create a compatible version in a procedural language.

You want to code a version of the bubble sort that does what the Java implementation previously
does but in the style and flavor of a procedural language. It takes a while to dope out some of these
Java constructs; the looping construct takes a bit of reading. Fortunately, you are familiar with the
bubble sort— a great help when you
 Page 18

BubSort: Proc ( arg ) Options( Main ) ;

Dcl arg Char( 40 ) Varying ;
Dcl anarray ( 6 ) Fixed bin( 15 ) Init
( 3, 10, 6, 1, 2, 9 ) ;
Dcl idx Fixed bin( 15 ) Init( 0b ) ;
Dcl arrayLength Fixed bin( 15 ) Init( Length
( anarray ) )
;
Dcl Length Builtin ;

Call sort( anarray ) ;

Do idx = 1 to arrayLength ;
Put Skip List( anarray( idx ) ) ;
End ;

Sort: Proc( a ) ;
Dcl a (*) Fixed bin( 15 ) ;
Dcl arraylength Fixed bin( 15 ) Init( Length( a ) ) ;
Dcl idx1 Fixed bin( 15 ) Init( 0b ) ;
Dcl idx2 Fixed Bin( 15 ) Init( 0b ) ;
Dcl temp Fixed Bin( 15 ) Init( 0b ) ;
Dcl swapped Bit( 1 ) Init( '1'B ) ; /* TRUE */

Do idx1 = arraylength to 1 by -1 ;
swapped = '0'B ; /* FALSE */
Do idx2 = 1 to idx1 ;
If a( idx2 ) > a ( idx2+1 ) Then
Do ;
temp = a ( idx2 ) ;
a( idx2 ) = a ( idx2 + 1 ) ;
a ( idx2 + 1 )= temp ;
swapped = '1'B ;
End ; End ;
if ( ˆswapped )Then return ;
End ;

End Sort ;

End BubSort ;
Listing 1.4 PL/I implementation of a bubble sort.

want to code an implementation. Listing 1.4 is a PL/I implementation you've written during a greasy
Tuesday taco lunch.

There is no significant difference between the Java and PL/I implementations. Both pieces of code
sort the declared and initialized array and list the sorted array elements
 Page 19

at the terminal. The PL/I code could have Begin/End block delimiters to mimic the functionality of
Java's curly braces. For example, you could have coded:

If a( idx2 ) > a ( idx2+1 ) Then

Begin;

Dcl temp Fixed Bin( 15 ) Init( 0B ) ;

temp = a ( idx2 ) ;
a( idx2 ) = a ( idx2 + 1 ) ;
a ( idx2 + 1 )= temp ;
swapped = '1'B ;
End ;

But you know that PL/I programmers hardly ever code in this style.

As you look at this PL/I code, you can't help but see the remarkable similarities with the Java code.
You realize that, all the hype about Java aside, at the heart of this Java stuff is Java, the
programming language. This programming language is very similar to programming languages you
already know. You think about how much you've learned about Java in a few short hours; it gives
you a warm feeling of satisfaction.

Meanwhile–Back at the Desk . . .

Sadly, your reality as a mainframe programmer creeps back and you check out your ever-growing,
never-diminishing queue of change requests. Here's a change request to modify a report created by a
COBOL application so old you can carbon-date it. As you flip through the mostly worthless
documentation for this application, you can't get Java and the object worldview out of your mind. As
you search the source code and compiler listings looking for variable references, you wax woefully
that this application does not exploit object technology. None of this data is encapsulated or hidden
in any way; every routine that accesses this data has the possibility of changing it. You need to find
and analyze all references to this data across several separately compiled modules.

Oh well, someday you may get to use Java instead of coding PERFORM statements and looking at
JCL job streams. In the midst of your reverie, your boss strolls by and summons you into the
conference room for an impromptu staff meeting. You grab your day-timer and march quickly into
the conference room; you don't want to be left standing.

Your boss announces a new strategic initiative pushed down from the rare air of executive row. The
big boys approved the new customer information system. The twist is that the big boys want this
system developed with object technology. Your boss asks the assemblage if anyone present knows
anything about this stuff.

No sooner than the echo from your boss' mouth fades, the department loudmouth booms in
obnoxiously. The loudmouth knows all about this stuff, he says. He says he's read much about C++
and that is the direction this project, nay, the whole company, should move toward. The meeting
attendees seem impressed. You, of course, know better.
 Page 20

Opportunity Knocks

"If you want to do real object-oriented stuff, Java is the way to go," you say. You explain that Java is
source code compatible across platforms. You continue by citing that Java development tools are
free, including documentation generators (that seems to get everyone's attention). Also, you don't
have to mess around with all those pointers because Java has no pointers.

The loudmouth barks that Java is supposed to be cool and all that but it is interpretive. "Can we take
the performance hit?" The Database Administrator adds to the discussion by saying that the
application will likely be I/O bound and that application execution speed may not be a bottleneck.

Attention now shifts back to you. You can't believe that everyone, including the loudmouth, is
hanging on your every word. You confidently lean forward. With eyebrows triumphantly arched, you
continue.

Java comes with packages, which are collections of related routines, that enable the programmer to
create interface screens, read databases, and talk over the network. In addition, you cite, the industry
is behind Java with the major players offering development tool suites. Java is far, far more than the
"Language of the Internet." Also, Training and Development is developing an in-house course on
Java programming.

You sense that your boss needs some action items for the meeting. You suggest that your boss call
the manager of Training and Development to get the take on this Java versus C++ business. Your
boss adjourns the meeting.

After the obligatory post-meeting chitchat with fellow wage slaves, you hunker down in your bunker,
seeking variable references to this COBOL application to implement this change request. Your mind
wanders. You can't help but wonder if this is the last change request for an ancient COBOL
application you'll do. You understand the excitement and fervor of the object disciples in general,
and the Java evangelists in particular. Can the disciples and evangelists be right? Is procedural
programming a thing of the past?

The only constant in this world is change. You cannot escape the Internet and the impact Internet
technologies have in business and society. Dot-coms advertise on the Super Bowl and place highway
billboard ads. Business pundits talk about downsizing, outsourcing, reengineering, and the new shape
of Information Systems. You hear the latest buzzwords and clichés. You hear your management
buzzing with these clichés. It's pretty scary.

However, you're off to a good start. You have some understanding of the hype, the hoopla, even
some of the buzzwords and clichés! Now, the time has come for you to learn how a data processor
skilled in writing COBOL and PL/I programs can master Java.

In Summary
The world of Java covers every facet in data processing from client, single-user programs to large,
enterprise-wide distributed systems. As you learn more and more about the brave new world, you'll
encounter numerous references to odd-sounding
 Page 21

technologies, including directory and naming services, remote method invocations, and Enterprise
JavaBeans. Any understanding of these and other Java technologies start with understanding the Java
programming language.

Here you are, with book in hand. You've taken a big step— but you knew that already— into a
different realm. Good luck on your Java trek. If you persevere, you'll be coding Java in no time flat,
and this book will help.
Exploring the Variety of Random
Documents with Different Content
some have approached it nearer than others; but in no case can one be
singled out as the only correct course, to the condemnation of all others.
The true artist will combine the best features of all achievements, and so
win a place nearer the goal than his predecessors. If we find one artist
excelling in form, and another in color, he who combines excellence of
form with beauty of color will surpass both. The narrowness of schools and
the vagaries of fashion have been a burden upon art; and the less we allow
ourselves to be enthralled by either, the greater will be our enjoyment of
artistic work. The more rigid our rule, the more precarious is its existence.
The standard of yesterday is to-day looked upon with a feeling akin to
contempt. Methods, models, ideals change; and the wise man is he who can
see the merits and shortcomings, the beauties and defects, of all.
We have said that different nations have shown in different ways their
sense of the aims and possibilities of ceramic art. The works of the Greeks
indicate an absorbing admiration of elegance of form{36} and figure-
drawing. Their vases mark the second step in the progress of decoration.
Firstly came linear ornamentation, and then light and line, of which all the
Greek vases are examples. If, then, the Greeks in their best days had only
reached the second step in decoration, to what must we ascribe the
wonderful influence of their art? Certainly it is not in the subjects they
chose to illustrate that its charm consists.
Taking our stand in ancient Greece, we may glance along the whole line
by which the art has progressed toward an approximate perfection, and at
the same time see in what the Greeks were pre-eminent, and in what they
were deficient. “To Greece,” says one writer, “was intrusted the cultivation
of the reason and the taste. Her gift to mankind has been science and art.”
Her highest idea was beauty. She left behind her canons of taste, beyond
which, in their special application, we have not advanced, and have little
hope of advancing. We are not, therefore, surprised when a writer on pottery
reminds us that “to every eye familiar with works of art of the higher order,
the cleverest imitations of nature, and the most elegant conceits of floral
ornaments, whether exhibited in the efforts of Oriental or European potters,
appear coarse and vulgar when contrasted with the chaste simplicity of the
Greek forms.” If we would appreciate the full truth of this, we have only to
make comparisons in any sufficiently extensive collection. The Greeks took
the articles of daily use, and made them representatives of their ideas of
beauty in both form and ornamentation. In this they followed the examples
set them ages before. In accomplishment only they were alone. While,
therefore, we study some as mere examples of skill, or curiosities of design,
we study the Greek forms as embodying our highest ideal of beauty.
Let us now examine that in which they were deficient, and see how
others have tried to remedy it.
There are branches of the art which the Greeks either did not study, or
studied without success. They give little evidence of having been able to
appreciate color or to understand its uses. They, as Ruskin says, painted
anything anyhow—gods black, horses red, lips and cheeks white. They
attained to a certain unsurpassable elegance of shape, and the beautiful
outlines of their human-figure ornamentation{37} can at times hardly be
sufficiently admired; but their coloring was purely conventional, and its
application but little understood. Its changes may be noticed with some
curiosity. At first the favorite ground was a pale cream-color, which, later,
turned to a redder tint, and human took the place of animal forms. The vases
in what is called the “old style,” show black figures and ornamentation in
monochrome, with the exception of female faces, which are white, and eyes
red. The effects of perspective are only occasionally tried. White was used
for the hair and beard of old men. Coming down next to the highest art of
Greece, the ground is black, the figures red, and the ornamentation white.
Specimens belonging to this period show advance chiefly in the drawing
and expression. We remark further, that, besides the use of conventional
colors, the Greeks did not care to copy nature too closely, and thus in two
distinct ways showed their indifference or inability to introduce into their
art the element of likeness. When Jacquemart says that “no natural object,
be it plant, bird, or animal, is rendered in its real form, or in its intimate
details,” he gives expression to a fact which shows the distinction between
Greek ceramic art and that in which a nearer approach is made to similitude
by the use of correct drawing and color.
The Orientals went to the opposite extreme. They delighted in bright and
gorgeous decoration to an extent that, but for their many intensely realistic
works, would lead to the belief that the production of certain effects in color
was the highest object of their artists. Their strength lies in their coloring.
Nowhere else can the same skill be found in the harmonizing of shades
usually deemed discordant, and nowhere else have colors the same
brilliancy and depth (Fig. 12). The Japanese and Chinese, in particular,
appear to have thoroughly grasped the true place of color in the{38}
 decoration of curving surfaces,
from which the brilliant glaze
reflects the light. The artists of
Sèvres, anticipating in a
manner Ruskin’s idea,
embellished their vases with
compositions similar to those
on canvas. They made the
mistake of thinking that the
artist’s work is independent of
the surface on which it appears,
whereas perspective is altered
Fig. 13.—Persian Tile. and sometimes destroyed by
Arabesque Decoration. the curvature of a vase and the
brilliancy of the enamel. The Fig. 12.—Japanese
artists of the Orient, on the other hand, either restrict Hexagonal Vase.
themselves to subjects which can be treated upon a Deep blue ground.
judiciously limited part of the surface, or throw aside Figures in dark
compositions entirely, and trust to floral designs, brown, three shades
isolated figures, repetitious decoration without unity of of green, and yellow.
design, or to beauty of colors alone. Everything Height, 16½ in. (R.
contributed to exalt their estimation of color for its H. Pruyn Coll.)
own sake, and to it we accordingly find that they
devote the regard entertained by the Greeks for form.
Any ulterior use of color, as for picture-painting on the flat surface of
porcelain plaques, does not appear to have occupied their attention to any
very great extent. It is in isolated figures and flowers that we can best study
the marvellous delicacy of the Chinese or Japanese brush, and the fidelity
with which the suggestions of nature are followed. There is little absolute
imitation. Color is paramount, and its beauty obscures the incongruities of
Oriental art.
The Persians, like the Greeks, mingled the natural with the conventional.
Their vases and tiles (Fig. 13) are ornamented with floral designs, in which,
while some of the flowers can be distinguished, others are altered beyond
recognition. Among the Mussulman Persians the enamels reached the
highest point of gorgeous brilliancy: glowing red as a ground-color, dishes
with bottoms covered with rich arabesques—everything set in tints of the
most pronounced and striking kind. Their decorations are many-hued as the
rainbow; and if at times they lack its softly melting shades, they appear at
others as if{39} suspended in the clear and liquid glaze, as soft as the tints of
early spring. White figures on a blue or yellow ground, or vice versa, are
distinctive of much of the ornamentation of Persia. The mosque at
Sultaneah (Fig. 14) is described as having its walls entirely “cased with
enamelled tiles of deep blue, with yellow and white scrolls and devices.”
The patterns are arabesque, occasionally mingled with animal and floral
forms. The finest specimens of Persian tiling at the Museum at Sèvres are in
blue and white, the latter forming the ground.

Fig. 14.—Mosque at Sultaneah. Cased, inside and out, with enamelled tiles.

These technical secrets, known centuries ago in Persia and the far East,
have been coveted by ceramists down to the present day. They have been
and are the most jealously guarded possessions of artists and factories, and
history records many instances of the extreme precautions adopted to
prevent their spread. The Japanese, for example, although indebted to China
and Corea for the foundation of the knowledge upon which the magnificent
structure of their subsequent art was built, guard with the utmost care the
borrowed secrets in their{40} possession. In a native work on porcelain it is
said: “The painting and decoration of vases is a secret that it is not
permitted to reveal.” Similar instances present themselves on every hand.
 The production of any unusually beautiful color,
although really only one-half of the difficulty with
which the ceramic artist has to contend, is universally
regarded as a triumph. Such were the efforts upon which
the potters of China expended their skill, and upon
which the emperors of the Flowery Kingdom bestowed
rewards. There are dynastic colors, but no dynastic style
of ornamentation with design. The ability to apply color
to an artistic creation was a secondary matter, and went
without recognition. The position of the artist and the
workman were thus in a measure inverted, if we insist
that the production of color is mechanical, and its
application artistic. If the decoration be examined, its
Fig. 15.—Japanese execution in detail will be found to be almost perfect—
Porcelain. Cloudy birds of brilliant plumage, flowers of richest hue, men
gray, flecked with and women draped in Oriental splendor (Fig. 15). In
gold; dress, rose every case the colors used are those which produce the
and gold. (Sutton subtlest harmony. They gleam through the glaze like
Coll.) gems, or lie upon its surface like drops of pearl, ruby, or
emerald. The drawing is precise and minute. A
cylindrical Japanese vase, in Mr. J. T. Sutton’s collection, is decorated with
a flock of cranes. They cover the upper part of its surface, flying, turning,
diving, in every conceivable attitude—a perfect whirlwind of birds. The
decorator has, with astonishing skill, seized upon the varied attitudes most
suggestive of motion, and has produced what might be called “a study of
cranes,” as far beyond the apprehension of a European artist as the minutiæ
are beyond his skill. Elsewhere we may see a masterpiece of manual
dexterity. It is reticulated, or articulated; or has its paste perforated, and then
covered with glaze; or it may be a grotesque expression of Oriental humor.
Others are decorated with designs in color, and their aspects have no
monotony.{41} Should one side weary, the vase may be partially turned, and
an entirely new effect is secured. In it, as in that described above, there is no
repetition.
In Oriental work, as a whole, we therefore find skill in manipulation,
similitude in drawing, and beauty in color; and the greatest of these is color.
We have seen how it was regarded by the Chinese themselves, and our
collectors follow their lead. They value one piece for the rarity of its
prevailing green, another for the depth of its turquoise, a third for the
clearness of its blue and the transparency of its white, a fourth for the
harmony of its many tints, a fifth for the skill displayed in its quaint form
and decoration.
We thus reach an interesting point where some instruction may be
gained. On the one hand, are the Greeks pursuing beauty of form with
assiduity and marked success; on the other, are the Orientals occupying
themselves with mechanical skill and the beauty resulting from color. Both
were right so far as they went. Men will admire Greek pottery so long as
they have any sense of elegant proportion; they will admire Oriental pottery
so long as they find any beauty in the changing colors of a kaleidoscope or
in a gem. The aims and ideals of the two peoples were different, and the
world has not yet seen the combination of a gracefulness of form equal to
the Greek with the coloring of the Orient.
In other directions, especially in Europe, it is more
difficult to unravel the lines of art, or to specify, without
numberless exceptions and modifications, the distinctive
aims of artists or schools. The example of the Orientals
has led some manufacturers to choose the production of
color as their great aim. They have no intelligent
comprehension of its higher uses, as these might be
studied in Chinese decoration. They form an exaggerated
estimate of Oriental processes, and {42}seek to equal the
wonderful coloring of the faience of Persia or Rhodes. If
they fail, as is generally the case, they are in no way
deterred from using their inferior colors as the Orientals
used the riches of their palette. Instead of turning toward
a new object within the compass of their lower skill, they
appeal to the eye with works which, by suggesting Fig. 16.—Nankin
comparison with the models that inspired them, are at Porcelain. Brown
once condemned. If a vase of Nankin porcelain should be bands; base,
placed side by side with a Delft copy, the force of this white; body, pale
will at once be seen. green; neck, light
It is comparatively easy to assign a place to Palissy. brown.
His career deserves study as an illustration of the Decoration
movement of art between the conventional and the chiefly pink,
natural. As we look back upon his works, we find that green, and blue;
truth to nature, in both form and color, was the guiding neck and body
motive in the production of his most remarkable pieces. crackled. (Sutton
We owe the romance of his life to his earnestness in Coll.)
attempting to solve the mysteries of enamel. “I thought,”
he says, “that if I could discover the invention of making enamel, I should
be able to make vessels of earth, and other things of beautiful arrangements,
because Heaven had given me to understand something of painting; and
thenceforth, without considering that I had no knowledge of argillaceous
earth, I set about seeking enamel like a man who gropes in the dark.” The
story of his trials, his failures and successes, his poverty, honors and
persecutions, compose the great romance in the history of ceramics. What
he attained was, first, a white enamel; then, jasper glaze of warm tints of
blue, brown, and white; lastly, his Rustiques figulines (Fig. 17). The last
was his crowning effort. We regard him both as the leading representative
of French art in the sixteenth century, and as a great originator. He had
made, after long struggle and endeavor, a great discovery in enamelling; but
what we admire more than that is the ideal he had formed. He developed
skill, and aimed at both beauty and likeness. Palissy was great because,
having chosen a certain line of art, he adopted the only ideal by which he
could possibly reach perfection, viz., absolute truth to nature, alike in form
and color. He neither spared himself nor overlooked any detail. His moulds
were formed from living specimens. We recognize every ornament—shells
of the district round Paris, reptiles and plants from the same places, and fish
from the Seine. He did not dare to improve or conventionalize. He preferred
nature as he found her; and his wisdom was genius. What we wish chiefly
to note is, that here was an artist{43} who used the beauties of enamel for the
reproduction of the natural. He not only moulded the clay into the forms of
living things, but reproduced the colors of his models. No better examples
can be given of Similitude. It hardly seems possible that his was a branch of
the same art that we have seen in the East and in Greece. The fact of its
being so merely shows the wide scope of ceramic art, and the infinity of the
forms it may assume.
 Fig. 17.—Palissy Dish. (Soltykoff Coll.)

Having chosen representatives of three different components of what we

have assumed to be the highest form of art, we may now glance at the end
in view, and see to what extent the lower forms may be worthily followed.
Let us suppose that a piece of pottery or porcelain has been painted, and
that the action of the fire has made the coloring perennial, so that we find
on it a portrait or a landscape everlasting as the ware itself. Let us suppose,
further, that the tints are natural, that, in short, the portrait is all that we now
understand by the word, and that in the landscape nature is displayed as on
canvas—then we should have a specimen of the perfect union of the
potter’s and painter’s art.
The lessening obstructions in the way of such a consummation may be
referred to in brief. The colors are mineral, and change by submission to
fire, different temperatures producing different tints,{44} even when the
same pigment is used. The painter, therefore, in applying the colors, must
take into account the change to be effected by the fire in endeavoring to
produce a certain result. He has not merely, it will be observed, to lay on
given colors, and have them made perpetual by glazing and firing. He must
estimate and make allowance for the transformations effected in the
process. We are now in a position to realize the difficulty attending the
exercise of the combined skill of potter and painter. As a consequence,
although many great painters have turned their genius to the decoration of
earthen-ware, others have been deterred from doing so by the very facts
here mentioned. They are unwilling to submit their work to processes
unattended with certainty, and to have their artistic individuality obliterated
by the fire. It is clear, therefore, that if by any means doubt can be changed
to certainty, and the finish characteristic of the individual artist be
preserved, artists of every grade will gladly avail themselves of the
opportunity to place their works above the reach of the defacing fingers of
Time. The ceramic art would be revolutionized. Artists, being at present less
able to follow nature, make a virtue of necessity, and lose themselves
among fantasies of tint and form. We find elaborately decorated pieces, the
great virtue of the floral ornamentation of which is, that it is—not true, but
—new. A new leaf or a novelty in flowers is a valuable discovery; and the
répertoire of the potter is filled with designs in which nature has no part. If
nature be brought within the artist’s reach, it will be followed more closely;
and the result might be the realization of Ruskin’s idea—the rendition of
absolute similitude in outline, color, and perspective.
The next question arising is, in view of the restraints upon artists, what
styles of decoration are the best? The subject is worth considering at length.
There may be a beauty of a certain kind in the ware itself. As a rule,
porcelain should never be overloaded with gold or any kind of decoration or
color less beautiful than its own enamel. It demands lightness of
ornamentation and gracefulness of design, rather than brilliancy of
decoration. We can, when these canons are observed, find something to
admire in capricious floral designs, even although they may not be floral to
the naturalist. The best rule is to adapt the decoration to the object upon
which it is{45} laid. It would be a violation of good taste to demand pictures
upon plates, or that a soup-tureen should resemble a sarcophagus. If an
object be for use, let its usefulness be the primary consideration; if for
ornament, let its beauty be its first; if it be meant to combine them, let the
ornamentation be that best suited to the useful purpose.
When we come to consider color alone, a distinction must again be
drawn between articles for different purposes. Ornamentation may address
either the eye alone or the sensibilities through the eye. Restricting
ourselves to the former, the article will be the most ornamental which, apart
from shape, seems most brilliant, and reflects the most light. To illustrate
this, we might reproduce an object in different materials—diamond, ruby,
topaz, gold, iron, lead, sand, and plaster. Show it, in all these materials, to a
savage, an ignoramus, an artist, a woman, and each will select the copy in
precious stone as the most agreeable to the eye. The plaster would be the
least likely to attract, and the person choosing it would be at once put down
as devoid of taste. Suppose, now, that a vase is presented to us duplicated in
different materials, we should find the turquoise of Japan or the red of
China more pleasing to the eye than stanniferous enamel. It would, again,
be like choosing between ruby and plaster. In this way a rule could be
drawn up capable of universal application, one which would surmount all
the advancing and receding waves of changing fashion.
In the shape which an object intended for ornament should assume, or in
the style of its decoration, there is, as we have seen, no absolute rule.
Individual taste is paramount, since ornaments are intended mainly to
administer to the pleasure of the possessor, but one rule may be considered
universal in regard to the decoration. If the object be a vase intended to
brighten a house, then its ornamentation should never be of such an order
that its greatest and best effect is perceived when it stands alone. What
ought to be kept in view, is the extent to which it will increase the
attractiveness of the room in which it stands. It is a very curious fact that
the most perfect decoration demands isolation for the appreciation of its full
effect, and that decoration of comparative mediocrity will frequently add
more to an apartment. We are thus led to observe that decoration is not an
end, but a way, a means to the beautifying of a home.{46} Every such object
in a house should be a note, and from combination of all the notes comes
harmony. Were each a tune complete, however perfect, the result would be a
jarring discord. For that reason, a vase of one perfectly simple color may
harmonize with its surroundings as well as, or even better than, another
showing a masterpiece of painting. Such a color must, however, be as near
perfection as possible, like that of a precious stone. A vase of turquoise-blue
may produce in a room the effect of diamonds in the ears of a woman. Taste
is not likely to lead her to carry pictures in her ears, nor to exclude all but
picture-painted porcelain from her rooms.
Having thus seen how ceramic productions illustrate the art ideas of all
nations, having touched upon the influence of pottery upon art in general,
and having glanced at its present aims and possible accomplishments, it will
not be forgotten, after what has just been said, that the combination of the
useful and the beautiful is the great charm of the ceramic art, making
between them a new beauty which finds its best place in the household. Let
us look at the usual appurtenances of the table. They both reflect taste and
form it. A wide range is before us from which to choose—from the
vulgarity of overloaded glaring colors and gilt, to the most exquisite
 simplicity of
design and
perfection of
workmanship.
Every house-
keeper ought to
visit an
extensive
collection, and,
by comparing
and contrasting
one style with
Fig. 18.—Limoges Porcelain
another, learn Fig. 19.—Limoges Porcelain
Plate. Painted by M.
in what the true Plate. Painted by Pallaudre.
Bracquemond. (Mrs. Charles
beauty of (Thomas Scott Coll.)
Crocker Coll.)
ceramic
decoration consists. The painting and
moulding of pottery and porcelain are quite as important as oil-painting and
sculpture. As we look at the pictures and statues in a gallery, we read the
stories they tell, feel the sentiment they express, study the grace they
embody, or linger lovingly over the evidences they present of artistic skill.
A plate may appear{47} an humble thing to which to turn from them. But let
us consider the intimate relations into which we are brought with its
unobtrusive beauty. It is the daily contact that lends so comparatively lowly
a matter its real importance, and daily contact with delicately painted and
gracefully moulded cups, platters, and dishes cannot be without its
influence upon taste. Or suppose the ceramic treasure be an earthen-ware
jar. It presents us with green, its depth suggestive of a forest glade, shading
off into blue like that of the sky. As we turn it slowly round, a leaf appears
attached to a tiny stem, and still farther lies a flower, colored with the very
hue of nature, and suggesting the perfume of a garden in summer. Art such
as that is never out of place, and never thrown away. Or let our attention
rest upon more purely ornamental representatives of the art. There are vases
which, while offering for our admiration a beauty which is eternal, are yet
invested with a chameleon-like power of change. They never allow
monotony to break their charm. It may consist of a mere color. Take the old
turquoise-blue of China. The eye can scarcely catch the fleeting shades, to
determine whether the vase is blue or green. While daylight lasts, the blue is
dominant, but when the lamps are lit in the evening, the blue gives place to
a green of greatly increased brilliancy. The same thing may be observed in
many flower-painted vases. They may be examined once without revealing
a tithe of their beauty. The sky is overcast and the outside world gloomy,
and the flowers, as sympathetic as though growing in the garden, look
sombre and drooping. But let a ray of sunshine fall across the vase, and
mark how the flowers are glorified. Their hues change and brighten, and, as
if endowed with life, they smile, and lift up their heads in the face of the
sun.{48}
 BOOK I.—NOMENCLATURE AND METHODS.

CHAPTER I.

TECHNOLOGY.

Confusion in Use of Terms.—Porcelain as an Instance.—Derivation of Ceramic.—Pottery.

—Faience.—Majolica.—Mezza-Majolica.—Composition of Porcelain.—Origin of Word.
—Where first made.—When introduced into Europe.—Hard and Soft Paste.—Soft
Porcelain of Venice, Florence, England, France.—Hard Porcelain invented at Meissen by
Böttcher.—Vienna.—Discovery of Kaolin in France.—Biscuit.

IT will be necessary as we proceed to make use of

certain terms, the meaning of which should be defined
with as much exactness as possible. It may be
premised that considerable confusion exists in the
nomenclature of the art. This has arisen partly from
the want of precision in the language employed by
writers, and partly from diversity of usage. As an
illustration, the word “porcelain” may be adduced.
The material to which the Egyptians applied a glaze,
and which was very largely used in making ornaments
and small images, has been called, and is constantly Fig. 20.—Blue-glazed
spoken of, as Egyptian porcelain (Fig. 20). In reality Pottery. Egyptian.
the substance is not porcelain, having neither the
transparency nor the hardness of that ware, but a compound between
porcelain and earthen-ware. The word was also used by the Italians in the
sixteenth century, to designate their finer qualities of majolica. An equally
incongruous application of it is made in the case of Lambeth faience, which
is described by the manufacturers as a “kind of porcelain.” Such words as
faience, hard and{49} soft porcelain, majolica, stone-ware, etc., are in
continual use by writers upon ceramic art, and a few of the more important
will now be defined.
 Allusion has already been made to the derivation of the word “ceramic.”
Viewing the subject more prosaically, the name κεραμος was applied by the
Greeks to pottery in general, and also to a large jar; and several derivatives
were used for the designation of different vessels. The potter himself was
called κεραμευς, and the pot-market κεραμεικος. Although the matter has
been differently viewed, it appears probable that the root of all the above
words is κερας, a horn. The horn was used at a very early period as a
drinking-cup, and a more decided air of probability is thus given to the
above assumption, since Bacchus was the reputed parent of [Greek:
keramos κεραμος], or Ceramus. However philologists may ultimately settle
this matter, the word “ceramic” is now employed to designate the potter’s
art and its productions.
The word “pottery” is variously used. Its root is the Latin potum, a
drinking-vessel. It is applied, according to general English usage, to all
wares distinguished by their opacity from translucent porcelain. The French
word poterie, on the other hand, is applied to all vessels, including those
made of porcelain. The latter fact has led to a slight confusion in the use of
the English word. One writer makes the assertion in one place, that the
words “earthen-ware” and “pottery” have limited and distinctive meanings,
the former applying only to vessels of the coarser qualities, the latter to the
finest products of the fictile art, “including even porcelain.” In another
place, he draws a distinction between pottery and porcelain, and in the latter
course he is followed by the present writer.
Faience, fayence, or fayance, is a French word applied to every kind of
glazed earthen-ware. According to the earlier French usage, the term
included porcelain, but more lately it has been applied only to pottery.
The word “majolica,” as now employed, has almost the same meaning as
faience. A more limited signification is attached to it by some. The writer of
the article on pottery in “Appleton’s Cyclopædia” says it is used “to signify
all faience of Italian manufacture. Lately the word has been used as almost,
if not quite, synonymous with faience.” A more recent writer has said, “In
its now common acceptation, the word is applied to all kinds of decorated
pottery made{50} in Italy, or made in colors and styles imitating the old
Italian work. But when you read a book on pottery written during the
present century by an expert, you will do well to remember that the word in
that book means exclusively Italian decorated pottery of the fifteenth,
sixteenth, seventeenth, and eighteenth centuries, in the old Italian styles. It
does not include Italian vases made in imitation of German, French, Dutch,
or English wares.”
The changing meaning of this word is a good illustration of the careless
use of the terms employed in treating of ceramic art. Originally, majolica, or
maiolica, had a meaning different from any of those given above. The name
is derived from Majorca, the largest of the Balearic Islands, between which
and Italy intercourse is known to have taken place in the twelfth century;
and two hundred years later, the commercial transactions of Majorca were
of a very extensive kind. The evidence in favor of the above derivation of
the word is conclusive. Scaliger says distinctly that the Italian pottery
derived its name of majolica from Majorca, where the pottery was most
excellent. Ferrari believes that “the use of majolica, as well as the name,
came from Majorca, which the ancient writers called Majolica.” The
“Dictionary della Crusca” adds weight to these authorities. Such being the
case, it seems probable that the Italians derived part of their knowledge of
making majolica from the place which gives it its name. Even admitting
that the Saracens who settled in Sicily, and the Moors expelled from Spain
who settled in Italy, initiated the Italians in the art, nothing is thereby
detracted from the importance of Majorca. The fact is left unaffected that
the intercourse with the Balearic group enabled the Italians to find a name
for the ware they admired so much. On trying to imitate it, the ware called
“mezza-majolica” was produced. The red clay was first thinly coated with
white earth, upon which the colors were laid. After a partial firing, lead
glaze was applied, and lustre pigments gave the ware the iridescence
characteristic of real majolica. It was after this that tin enamel was used in
place of a white slip; and the lustre pigments being applied as before, fine
majolica was produced. It will thus be seen that the words “mezza-
majolica” and “majolica” were originally applied only to wares showing the
reflet métallique, or lustre. This limited use of the word was observed down
to the middle of the sixteenth century. Piccolpasso,{51} writing in 1548, in
no case applies the name to the painted and glazed wares of his own
production. All the glazed earthen-ware of Italy was thereafter called
majolica; and the application of the word has been growing wider ever
since. Mr. Fortnum says, “We think, with M. Jacquemart, M. Darcel, Mr. J.
C. Robinson, and others, that the word ‘maiolica’ should be again restricted
to lustred wares.” Any such attempt must necessarily end in failure. The
popular employment of a word is not to be controlled by its scientific
application. The tendency is in the opposite direction—toward the
establishment of a universal usage by which faience and majolica will
become convertible terms.
The different kinds of ware, such as Lucca della Robbia, Palissy,
Doulton, and Limoges, will be found described under the countries to which
they belong.
Porcelain is composed of two ingredients, one of which—kaolin—is
infusible, and the other—petuntse—vitrifies, and envelops the kaolin. It is
translucid, and therein differs from pottery, which is opaque. As to the
origin of the word, we have already seen that it was, in its Italian form,
applied to majolica in the sixteenth century; and the word “pourcelaine”
occurs two centuries earlier. It was used to designate Oriental china in the
fifteenth century. Mr. J. F. Davis, in his work on the Chinese (1840), quotes
Marsden to the effect that the word “porcelain,” or porcellana, was applied
by Europeans to the ware of China, from the resemblance of its fine
polished surface to that of the univalve-shell so named; while the shell itself
derived its appellation from the curved or gibbous shape of its upper
surface, which was thought to resemble the raised back of a porcella, or
little hog. When porcelain was first invented in China is not exactly known.
The combination was discovered in the province of Honan about eighteen
hundred years ago; but the date cannot be more specifically fixed. From
China it was introduced into Persia, Egypt, and Barbary, at a very early
period, and was thence imported into Europe, where, however, it was not
generally known until 1518. The first specimens of Oriental porcelain
known to have reached England were given by Philip of Austria to Sir
Thomas Trenchard, of Wolverton, in 1506.
To continue its history in Europe, it is necessary to observe that there are
two kinds of porcelain—the natural, or pate dure, and the{52} artificial, or
pate tendre. The latter cannot stand so high a temperature as the former, and
can be scratched with a knife, which the hard porcelain resists. The soft-
paste was the first to be discovered in Europe. Chemists, struck with the
beauty of the Chinese porcelain, and impelled by a desire to imitate, began
to experiment in the sixteenth century; and the first success, of which
substantial evidences now exist, was gained at Florence in 1580. It is said
that a Venetian potter made porcelain sixty or seventy years earlier; but no
specimen known to be his is now in existence. After that of Florence, the
next discovery was made by Dr. Dwight, of Fulham, England, in 1671; and
in 1695 the secret was penetrated by M. Chicanneau, at St. Cloud, France.
By that time the Florentine porcelain and process had been forgotten, and
the English and French ceramists pursued perfectly independent
investigations.
The problem of making a hard-paste porcelain resembling that of the
Orient still remained unsolved. No chemistry could avail the experimenters
so long as the materials were wanting. To the accidental discovery of a bed
of kaolin, Europe owed its first hard porcelain. This important event took
place about the year 1709, and the circumstances leading to it are full of
interest.
John Frederic Böttger, or Böttcher, was a chemist’s assistant in Berlin,
and having fallen under suspicion as an alchemist, he took refuge in
Saxony, which was then under the electorate of Augustus II. The elector,
having questioned him as to his researches in the forbidden science, placed
him in the laboratory of a chemist who was in search of the philosopher’s
stone. While working to that end, Böttcher surprised himself by producing
something akin to Chinese porcelain. The course of his experiments was
turned at once from the channel in which it had run. The king gave him
every facility for continuing his experiments and working out his secret. He
was first established at Meissen, then at Königstein, and last at Dresden.
The first results were comparatively rude; then came a reddish stone-ware,
and afterward a dull white porcelain. How long his experiments might have
been continued, or what might have been their ultimate result, cannot be
estimated, had not an accidental discovery brought the object at which he
was aiming suddenly within his reach. John Schnorr, a wealthy iron-
founder, riding one day in the vicinity{53} of Aue, near Schneeberg, Saxony,
noticed that his horse lifted his feet with difficulty. On examination he
found that the clay was very white and peculiarly adhesive. Schnorr,
although rich, would gladly be richer, and avarice made him ingenious.
Why not use this white earth in the making of hair-powder? was the
question which occurred to him. The commodity was dear, and clay was a
cheap substitute. He took a quantity with him, made the new hair-powder,
and was successful in his venture. In due course, the new powder reached
Böttcher, and he, in turn, found an original use for the white earth. Inquiring
into the nature of the powder, he found it was earthy, and at once tried it in
his laboratory. The powder was kaolin, and hard porcelain was discovered.
A manufactory was established at Meissen, of which Böttcher was director
until his death, in 1719.
In 1720, the manufacture was begun at Vienna, whither the secret was
carried by an escaped foreman from Böttcher’s works at Meissen.
It is very curious to note that the first manufacture of hard porcelain in
France was due to a chance discovery almost identical with that made in
Germany. Kaolin had been found at Alençon, but the porcelain made from it
was not pure in color. In 1765, the wife of a surgeon found near St. Yrieix a
peculiarly soft earth of great whiteness. Being poor, Madame Darnet was
also economical. Unlike Schnorr, her thoughts turned in the direction rather
of keeping down household expenses than of adding to her income. The
earth had a soft, oily touch, and the good lady thought that it might answer
all the purposes of soap. Her husband sent a sample to a chemist, and it was
soon afterward decided to be kaolin. The manufacture of hard porcelain was
begun at Sèvres in 1769, the quarries of St. Yrieix supplying both the kaolin
and petuntse. As illustrating the ingratitude of the world, it may be
mentioned that the humble instrument by whose aid France reached its lofty
eminence in the manufacture of porcelain was, for about sixty years, left
unrewarded. In 1825, Madame Darnet, spending her old age in poverty,
received a pension from Louis XVIII.
Biscuit is the technical term applied to both pottery and porcelain before
they are enamelled or glazed. In this condition, porcelain is of a dead white,
and is not very well suited to receive decoration in colors which require a
glaze to bring out their full beauty.{54}

CHAPTER II.

CLASSIFICATION.

Tabulated View.—Brongniart’s Division: Its Objections.—Classification adopted.—

Leading Features and Advantages.—Distinctions between Different Bodies and Different
Glazes.

IN order to avoid repetitions and explanations, and for the sake of

lucidity, tabulated views of the different branches of ceramics are here
presented. The first is least detailed, but gives the salient points of a
systematic arrangement.
 Unglazed Common brick. Earthen-ware.
Lustrous Greek pottery.
Soft
Glazed Some ancient and most modern faience.
POTTERY
Enamelled Robbia ware.
Stone-ware.
Hard
Fire-brick.

Naturally soft English porcelain.

Soft
Artificially soft French porcelain, pate tendre, such as old Sèvres.
PORCELAIN China.
Hard Dresden.
Sèvres.

The following is more full, and is to be ascribed to M. Brongniart:

FIRST CLASS, SOFT-PASTE.
1st Order. Baked clay without glaze.
2d Order. Lustred wares with silico-alkaline glaze.
3d Order. Glazed pottery with plumbiferous glaze.
4th Order. Enamelled pottery, in the enamel of which tin is used.
SECOND CLASS, HARD-PASTE (OPAQUE).
5th Order. Fine faience, uncolored paste with plumbiferous glaze.
6th Order. Stone-ware without glaze, or with salt or plumbiferous glaze.
THIRD CLASS, HARD-PASTE (TRANSLUCENT).
7th Order. Hard porcelain, paste and glaze both felspathic.
8th Order. English natural soft-paste porcelain—paste, argillaceous kaolin, pegmatite,
phosphate of lime, etc.; glaze, boracic.
9th Order. French artificial soft-paste porcelain—paste, a frit, marly alkaline; glaze,
alkaline containing lead, alkali, and silica.

{55}
If these tables be studied carefully, it will be found that in arranging the
nine orders, a gradual ascent is made from the humblest ware—baked clay
left unglazed—to the finest of artificial compounds. Its only objection—and
it is one very likely to confuse an inexperienced student of the art—is, that,
under the head of hard-paste pottery, are classed the soft-paste porcelains of
England and France. The question is, also, very likely to suggest itself, why
the distinction should be drawn between the soft-pastes of England and
France, and the one called natural, the other artificial. The reason is that the
paste of England is naturally soft, while that of France is made soft by the
chemical action of certain of its ingredients. The classification has, on the
other hand, the advantage of being in general use. Terms are employed in its
construction which have a peculiar but well understood significance; and
even in its errors there is a modicum of truth. Thus, although the artificial
porcelain of France is invariably called pate tendre, or soft porcelain, it is
not improperly classed under translucent hard-pastes. The error is in the
distinctive name rather than in the classification. There is, in reality, very
little difference in hardness between the hard-paste and the soft-paste; and
although the glaze of the latter is not so hard as the body, the appellation
soft-paste has been adjudged a misnomer. The question then came to be
whether it might not be better to retain the old terms, with an explanation of
their technical meaning, than to supplant them with something new. The
latter course has been adopted, upon the ground of obviating meaningless
and misleading distinctions. Both simplicity and a clear understanding of
one of the most important practical divisions of our subject point toward a
revision of the old system of grouping. Pottery and porcelain differ in one
essential respect, and their varieties can also be classed according to the
leading features of their composition, manufacture, or appearance. These
differences have been taken as the basis of the following classification,
against which, at least, none of the objections to that of M. Brongniart can
be brought. It has been prepared by a distinguished French artist of the
present time, and is offered in the hope that it may be intelligible, although
it is not claimed to be either perfectly exact or altogether complete.
All wares are divisible into two great classes, viz., transparent porcelain
and opaque earthen-ware.{56}

Porcelain may be natural or artificial

I. Natural porcelain is made from kaolinic clay. It may have—
1. A pure felspathic glaze, such as porcelain of China, Japan,
Limoges, Sèvres, Dresden, Berlin; or,
2. No glaze, such as the biscuit porcelain of China or France.
II. Artificial porcelain may be made from alkaline clay, calcareous
clay, or felspathic clay.
1. Alkaline clay may have an alkaline glaze, either colorless or
colored, or may be biscuit.
a. Alkaline glaze, colorless—Persia, China, St. Cloud,
Limoges, Sèvres, Tournay.
 b. Alkaline glaze, colored—Persia, China, Limoges, Deck.
c. Biscuit—Old Sèvres statuettes.
2. Calcareous clay has a colorless boracic glaze, as in the case
of the English china of Minton, Copeland, and Worcester.
3. Felspathic clay is exemplified in the parian of Copeland,
Minton, and Worcester.
Earthen-ware is of two kinds—that showing a non-vitrified fracture, and
that showing a vitrified fracture.
I. Earthen-ware with non-vitrified fracture may have either a
transparent glaze or an opaque enamel.
1. Transparent glaze may be plumbiferous or alkaline, and in
either case colorless or colored.
a. Plumbiferous.
Glaze, colorless—Faience d’Oiron or Henri Deux ware,
Wedgwood, Meakin, Creil, Montereau.
Glaze, colored—Palissy, Nuremberg, Minton’s
majolica.
b. Alkaline.
Glaze, colorless—Persian faience, Chinese and
Japanese faience; Deck, of Paris.
Glaze, colored—Haviland or Limoges faience.
2. Opaque enamel is stanniferous, and may be either colorless
or colored.
Stanniferous, colorless—Della Robbia, Rouen, Moustiers,
Delft, Nevers.
Stanniferous, colored—Colinot, Parville, Longwy.{57}
II. Earthen-ware with vitrified fracture may be either glazed or in
biscuit. Of the former, the Grès of Germany, Beauvais, and
Doulton may be taken as examples.

For convenience of reference, the same classification may be given in

tabulated form:
CLASSIFICATION OF ALL KINDS OF WARE.
Translucent Natural Kaolinic Glaze of China, Japan, Dresden,
Porcelain. paste felspath, pure Berlin, Sèvres, Limoges.
 Biscuit porcelain of
Biscuit
Limoges and China.
Glaze Persia, China, St. Cloud,
alkaline, Tournay Sèvres,
colorless Haviland.
Alkaline
Glaze
paste Persia, China, Deck,
alkaline,
Haviland.
Artificial colored
Biscuit Old Sèvres statuettes.
Glaze boracic, English china, Minton,
Calcareous
color Worcester, Copeland.
Felspathic Copeland, Worcester,
Parian
paste Minton.

Opaque Faience Henri II.,

Earthen Glaze,
Wedgwood, Meakin,
Body. Plumbiferous colorless Creil, Montereau.
glaze
Terres. Glaze, Palissy, Nuremberg,
colored Minton’s majolica.
Transparent Faience of Persia,
glaze. Glaze,
China, and Japan;
colorless
Earthen Deck.
Alkaline
body Limoges faience of
Glaze
with a Glaze, Haviland,
non- colored Bracquemond, and
vitrified Chaplet.
break Delia Robbia,
Rovigo, Fontana,
Rouen, Moustiers,
Colorless
Stanniferous Nevers, Delft,
Opaque Ulysses de Blois, St.
enamel
Clement.
Colinot, Parville,
Colored
Longwy.
Earthen Biscuit Boccaro, Bizen.
body
 with a
vitrified Glaze Grès from Germany.
break
Under the above arrangement, it will be observed that the distinction{58}
between hard and soft porcelain and pottery is done away with. The first is
divided into natural and artificial, the kaolinic paste being the only one
coming under the former head, and the “soft-pastes” of both England and
France coming under the latter. The subdivisions are made according to the
glaze employed. The division of pottery into two classes, according to the
nature of the body as revealed by fracture, is the most lucid and
comprehensive. The subdivisions, as in the case of porcelain, are made
according to the enamel or glaze applied to the ware. It is presumed that any
one can distinguish between transparent and opaque wares, and thus tell
porcelain from pottery, and similarly, tell whether the fracture of a broken
specimen is vitrified or otherwise, and thus distinguish stone-ware, or grès,
from ordinary earthen-ware.
In the matter of glazes, it requires a great deal of skill and long practice
to tell one from another. All are transparent, with the exception of tin or
stanniferous enamel. Felspathic glaze is that most readily recognized; but in
the case of the others—the alkaline, plumbiferous, and boracic—they are
very often only to be distinguished by their different effects upon the colors
used in decoration.{59}

CHAPTER III.

COMPOSITION OF WARES AND GLAZES.

Hard and Soft Pottery and Porcelain.—Composition of Porcelain: Kaolin—Its Derivation and
Ingredients—Petuntse—How prepared in China.—The European Process.—Differences
between Chinese and European Porcelains.—Chemical Analysis.—English Porcelain and
its Peculiarities: Its Average Composition.—How English Clay is prepared.—French
Artificial Porcelain.—Parian.—Common Earthen-ware.: Table of Ingredients of different
kinds.—General Table.—Glazes: Classes.—Brongniart’s Classification.—Difference
between Enamel and Glaze.—Silicious Glaze.—History.—Use of Oxides.—Egyptian
Processes.—Metallic Lustre.—Stanniferous Enamel: Its History.
 THE division of pottery and porcelain into two great classes, hard and
soft, is based upon the difference of their composition, their hardness of
surface, and their power of resisting the action of fire. The simplest test is
scratching with a knife or other instrument. Hard porcelain and pottery
resist the metal, while the soft is marked. The former will also stand a
temperature in the kiln at which the latter would crumble or fuse.
To understand the composition of porcelain, it is necessary to bear in
mind that it is a compound of kaolin and petuntse, the former of which is
infusible, and the latter fusible at a high temperature. The former constitutes
the body of the piece, the latter gives it its translucency. The word “kaolin”
is derived from Kaoling, the name of a mountain near King-teh-chin, one of
the great centres of the manufacture in China. Kaolin is simply the result of
the decomposition of granitic rock, and silica and alumina are its chief
ingredients. Petuntse is pure felspar. The conditions in which these
materials are found in China may be briefly stated. They are either in the
form of stone or sand, from which the unsuitable parts are removed by the
action of water. When they are thrown into the water, the fine particles
which do not sink are collected and dried. The paste, before being used, is
again put into water and strained through a sieve, so that only the finest is
preserved, and used in making porcelain. The{60} materials are obtained
from different parts of the country, and blended according to their
respective qualities, as ascertained by the most systematic investigation and
experiment. The European process is similar, the kaolin being first washed
clear of all argillaceous impurity, and then mixed with felspar and silicious
sand. Of the further similarity between the two, MM. Ebelman and Salvetat
say:
1st. The kaolin and petuntse used in making paste for Chinese porcelain
are chemically identical with the materials used in Europe. The Chinese
kaolin is evidently disintegrated granite. Chemically, petuntse resembles the
pegmatite of Limoges; mineralogically, it is to be classed with petrosilicious
felspar.
2d. The mechanical preparation of the pastes of China and Europe is
based upon similar methods.
3d. The Chinese paste is the more fusible of the two.
4th. The Chinese glaze is also the more fusible, on account of the
addition of lime to the petuntse, which the French use pure.
 It may be added that the Dresden, Sèvres, and Limoges porcelains are
baked at a higher temperature, and are harder than the Chinese.
The basis of the natural pastes of Germany and France is 46.66 parts of
silex, 40 of aluminous earth, and 13.33 alkaline earth, although the
proportions vary, and the following may be nearer an average: Silex, 66;
alumina, 30; potash, magnesia, and lime, 4. In the glaze the proportions are
different, the silica largely preponderating: Silex, 73.4; alumina, 15.7;
potash, lime, and magnesia, 10.9.
The following table is given by M. A. Salvetat as the result of analyses
made at different times by himself and others:
Oxide
Pastes. Silica. Alumina. Lime. Magnesia. Potash. Soda.
of Iron.
China, 1st quality 69.00 23.60 1.20 0.30 0.02 3.30 2.90
China, 2d quality 70.00 22.20 1.30 0.80 traces 3.60 2.70
China, 3d quality 73.80 19.30 2.00 0.60 traces 2.50 2.30
China, 4th quality 68.94 21.30 3.48 1.14 traces 3.42 1.78
Meissen 58.50 35.10 0.80 0.30 traces 5.00 ....
Vienna 59.60 34.20 0.80 1.70 1.40 2.00 ....
Berlin 64.30 29.00 0.60 0.30 0.45 3.65 ....
Limoges 70.20 24.00 0.70 0.70 0.10 4.30 ....
Sèvres 58.00 34.50 .... 4.50 .... 3.00 ....
Sèvres (sculpture) 64.10 30.24 .... 2.82 traces 2.80 ....
Worcester 82.00 9.10 ..... 1.30 7.40 .... ....
Paris 71.20 22.00 0.80 0.80 .... 4.50 ....

{61}
The English artificial porcelain differs from the natural paste of China
and the European continent chiefly in one particular. At first the compound
used was white clay, white sand, and glass, the latter being employed to
impart the necessary transparency. More recently bone came largely into
use, and is now one of the distinctive ingredients of English paste. The
phosphoric acid of that material was found to produce, in combination with
the other materials, a clear, translucent body, of less strength than natural
paste, but less liable to sink. The following may be taken as the mean
composition: Bone, 47; kaolin, 34; felspar, 19. The kaolin is found in
Cornwall, where a very large tract is formed chiefly of decomposed granite.
The purest rock having been selected, it is placed on an inclined plane, upon
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