Kevin Boone

Home Contact CV Software Articles

🔍

An introduction to Perl for Java programmers

Overview

This article is intended to help experienced Java (or possibly C++) developers to get started used Perl. It isn't a Perl tutorial -- there are plenty of those about -- but a guide to how Perl implements features that will be familiar to a Java programmer. I assume that you are basically familiar with programming language concepts, object orientation, and how compilers and interpreters work.

If you are a Java programmer, you'll find many things refreshingly familiar in Perl. You'll also find many things that are disturbingly different. On the familiar side, Perl is conceptually similar to Java. By that I mean that it can be used in the same way to tackle the same basic problems. It is procedural, it has similar keywords and constructs, functionality is divided into subroutines (or methods, or functions, if you prefer), and it supports object orientation, exception handling, and packages. On the unfamiliar side, it has a very fluid syntax, and a much larger set of basic language features than Java.

By `fluid syntax' I mean that Perl supports many different ways of saying the same thing. For example, here is a snippet of Java code.

if (!test)
  {
  throw new Exception ("aargh");
  }

This could be expressed perfectly well in Perl like this:

if (!test)
  {
  die ("aargh");
  }

and you'll notice how similar this is to the Java version. But it can also be expressed like this:

unless (test)
  {
  die ("aargh");
  }

with the unless operator meaning `if not'. But more commonly an experienced Perl hacker will write something like this:

test or die ("aargh");

In this example, we rely on Perl's short-circuiting of the or operator to ensure that die is not executed if test is true.

Why could we not write the Java version in the same, compact form? Well, Java has a very rigid syntactical structure. First, logical operators like AND (&&) and OR (||) can only be used on operands that have boolean type. test, we assume, does; but what about throw? In Java, throw is not assignable at all: you'd can't get a value from it. So we couldn't use throw in a logical comparison. Second, the statement constructed from logical operators must itself return boolean type. Third, a logical comparison cannot stand as a statement in Java. if (x || y){}; might be good Java, but x || y; isn't.

You can make your own mind up about whether Perl's increased syntactic flexibility makes it `better' or `worse' than Java; it certainly does allow some very common operations to be expressed in compact form, but they are often unreadable to non-Perl programmers.

Because I had been using C and Java for many years before starting to program in Perl, I tend to write Perl programs like Java programs, and the examples in this article will reflect that. For a Perl guru, there are more elegant (or at more contracted) ways of expressing the same thing, but then if you were a Perl guru you've no need to read this.

Considering the basic set of language features, Perl is much richer than Java. That doesn't mean that it can do more, it just means that the basic language can do more. The Java philosophy has always been to have a very simple core language, and put all other functionality into the standard class library. So, for example, Perl supports associative arrays as part of the language. Java does this through classes in the java.util package. Perl allows regular expressions to be written directly into program statements, while Java will expect to find this functionality encapsulated into a class. In the end, neither is better than the other, they're just different.

Basic stuff

So let's examine the basic features of Perl from the perspective of a Java programmer.

Program structure and philosophy

Perl, like Java, is a procedural language. A program consists of statements that tell the computer to carry out certain actions in a certain sequence. Statements are grouped using braces {...} and terminated using semicolons (;) just as they are in Java. Perl, as we shall see, is more fussy about the use of braces than Java.

Overall, Perl's syntax can be very close to Java's. Many of Java's keywords and structures can be found in Perl (which is hardly surprising, since they share a common origin in C). However, Perl is syntactically very fluid compared to Java. The same statement can be expressed in a number of different ways. Also, Perl has a much larger set of keywords. If you are a Java programmer, you'll very likely not use most of them.

Perl has some notional object-oriented features but, unlike Java, it is possible to write a perfectly satisfactory Perl program without defining a single class. Object orientation is optional.

Perl uses garbage collection, and the developer is not expected to get involved with memory management issues. Unlike Java, it is possible in Perl to define objects that cannot be recovered by the garbage collector, even when they go out of scope. The textbook example is to create two reference variables that reference each other; this brings us on to:

Like C++, and unlike Java, Perl allows specific manipulation of references to variables.

Perl, like Java, is case sensitive throughout.

On the whole, Perl is weakly typed, compared to Java.

Compilation and execution

Like Java, Perl is primarily an interpreted language. That is, it does not produce machine code that can run natively on any platform. Instead, it relies on a run-time environment to support the execution of code. The normal way of running Java applications is to use the compiler to translate them into Java bytecode. The bytecode is saved in a separate file (a `.class' file), which is then fed into the run-time environment. So, working with command-line tools, we will normally compile and execute like this:

javac Test.java
java Test

By default, Perl does not work this way. The Perl interpreter translates the Perl source code into a parse tree, which is then interpreted in the same process using the Perl runtime. Perl execution is thus a one-stage process. So, given a Perl application, we could do:

perl Test.pl

In a Unix environment, a more common method is to begin a Perl source file with a directive that tells the operating system to invoke the Perl interpreter. Typically we would start the source file with a line like this:

#!/usr/bin/perl

The program can then be run directly from the command line:

Test.pl

To the best of my knowledge, this technique has no equivalent on Windows platforms. However, what you can do on Windows platforms -- or at least on some Windows platforms -- is set up a shell association between the `.pl' filename extenstion and the Perl interpreter using the Explorer or File Manager. This, I am reliably informed, works from the command line on Windows XP and Windows 2000, and may work on other versions. It should work from an icon as well. Of course, you're limited to naming your Perl scripts with files that end in `.pl', but that's not unusual anyway.

More recent versions of Perl allow more sophisticated methods of compilation and execution. For example, there are now utilities that will translate Perl into C. The C source can then be compiled to native machine code. Alternatively, most Perl implementations now allow bytecode output, which can then be used in exactly the same way as Java bytecode. The bytecode is platform-independent, and should be capable of execution by any compatible Perl runtime. It's probably true that Perl's bytecode interpretation is less well-developed than Java. In particular, there is as yet no stable just-in-time (JIT) compiler. A good Java virtual machine will use a JIT compiler to compile the bytecode to native machine code on the fly, and this will result in very fast execution. In practice however, the performance of practical, real-world Perl applications is not markedly inferior to Java.

Execution sequence

As you probably know, execution of a Java program (apart from static initializers, etc) begins with a method called main() in a specified class. All code and data must be in some method or other, in some class or other. In Perl, execution order is (mostly) strictly top-to-bottom, starting with a specified file. Statements other than function definitions are executed as encountered. No special effort need be taken to indicate that the execution should stop: this will happen when the end of the file is reached.

Thus, the following is a valid, complete Perl program:

print "Hello, world!\n"

There are some exceptions to the top-to-bottom rule. First, it is possible -- and reasonable -- to execute a separate, complete Perl program within another Perl program. This allows Perl programs to be built from separate `modules', just like Java (see below). Second, modules can have constructors and destructors (somewhat similar to Java), and an `autoload' facility (not at all similar to Java). In Perl the function called AUTOLOAD is called whenever a reference is made to a non-existent function; this can be used to generate the function dynamically.

Execution can be terminated before the end of the file using the die function -- which throws an exception -- or the exit() function -- similar to System.exit() in Java -- or using a number of other constructs. One of these is the archaic __DATA__ directive, which informs the interpreter that everything thereafter is data, not executable code. The program can read this data using a predefined file handle. There is, of course, no equivalent to this technique in Java (which is what makes it interesting).

Packages and modules

Conceptually, Perl's packaging system is not all that different from Java's, although the underlying implementation is very different. In Perl, one program includes other programs or modules simply by loading and executing them at runtime. This execution causes any functions defined in the modules to become available. There are two basic ways to do this. First:

require Fred;

processes the file Fred.pm, which is assumed to be in one of a standard set of search directories. Alternatively

use Fred;

has similar functionality, but modifies the namespace of the including file such that the functions defined in Fred do not need to be referenced with their package names. That is, it imports the names in the module into the including program's namespace. In a sense, use behaves similarly to Java's import. Classes referenced by an import do not need to be referenced with their full class names (including the package): a short class name will do. The same is true in Perl.

Just like Java, Perl understands packages, and packages can be hierarchical. Also as in Java, the package hierarchy corresponds to a directory hierarchy. So, the following Java:

package calculator;
import math.Complex;

is loosely equivalent to this Perl:

package Calculator;
use Math::Complex;

In the Perl example, you can expect to find a file called Complex.pm in a directory called Math. The roots of the package structure can be specified on the perl command line, or default to system-defined locations, just as in Java.

Note that the package separator is `::'. As in Java, you don't need to give the full package name for an entity which is in the same package as its user, but it doesn't do any harm if you do. Unlike Java, the same file can (in principle) include multiple packages. The package function in Perl takes effect from where it is used, not over the whole file. The use of capital letters for package names (and class names) in Perl is a rule, not a convention.

Where Perl's packaging system differs most obviously from Java's is it's use in object-oriented programming (of which, more later). In Java, when we say

package x;

we mean `this is a class in package x'. The name of the class is specified later in the file. In Perl the same line means `this is a class called x'. In Perl, a package is a package of functions, not a package of classes. This is not a problem in practice, because packages -- in Java and in Perl -- can contain other packages. So all we need to do is to create one additional level of package in the Perl program and we have a situation analogous to that in Java.

Comments

Comments are introduced by a hash # character, which need not be the first character in the line. There is no (official) equivalent of the Java/C++ `block comment' /* ... */, which is a shame. There is, however, a `pod' comment block, which is used by the Perl documentation generator. This is similar to Java's /** ... */ comments, except that pod comments can't be defined to include less than a whole line. A pod comment block might look like this:

=pod
This is a comment
So is this
=cut

There are pod directives for section headings, etc., just like the `@' directives that Javadoc uses for Java documentation.

Literals, variables, and identifiers

Lexical symbols and tokens

In Java, a string of characters that begins with an alphabetic or underscore is treated as an identifier, while literals must be declared as such in some way:

String name = "fred";
double x = 2.0;

That is, String and name are identifiers, while fred is a literal. `2.0' is a literal as well, because it begins with a digit; this does not confuse the compiler because identifiers can't begin with digits. In Perl, identifiers must be indicated, while literals need not always be:

$name = fred;
$x = 2.0;

Here, $name is an identifier; the $ indicates that it identifies a scalar variable (see below). fred is a string literal. x is also a variable, as indicated by the $. Both these statements assign literal values to variables. Note that `fred' did not have to be quoted. However, it would also be correct to say

$name = "fred";

or

$name = 'fred';

So what is the difference? It is related to variable expansion (or `interpolation'), a concept with no equivalent in Java but very familiar to shell programmers. For example:

$name = 'fred';
$message = "Hello $name \n";
print $message;

Line 2 substitutes the value of the variable name into the string message. It also turns the escape sequence \n into whatever character is a `newline' on that platform. The form:

$name = 'fred';
$message = 'Hello $name \n';
print $message;

displays the string exactly as entered; no substitution takes place and the \n remains exactly as written.

In reality, the form

$name = fred;

is not all that useful, for two reasons. First, it only works where there is a single token. This is a syntax error:

$message = Hello fred;

Second, an unquoted string of characters that is not identified as a variable of some sort may be a file handle (see below). In practice, therefore, you will mostly see Perl strings declared similarly to Java Strings, but with a $ sign in front of the name. The $ is not a BASIC $, which indicates a string variable (although it does in this case), in Perl it indicates a scalar, not necessarily a string. Note that in Java a variable is declared by stating its type, but the type does not have to be given when the variable's value is taken. Perl requires the $ sign for both declaration and use of variables, because it denotes `scalar context' -- a concept which will be explained later.

Although the use of single and double quotes to group characters into a string literal should be familiar to Java programs, in fact, Perl's quotes are simply conventional shorthand for a general-purpose token-grouping scheme that has no equivalent at all in Java. For example, rather than writing

$name = "fred";

I could have written

$name = qq!fred!;

which has exactly the same effect. The token `qq' indicates that some tokens are to be grouped into a single element, and the `£' identifies the boundaries of the grouping. In fact, I could use almost any punctuation symbol instead of £, provided that the opening and closing symbols are compatible.

In practice, Java developers are unlikely to use this notation as it is so different from Java, but it is widely used for one application: defining a string that has lots of quotation marks internally. By using `qq' we can define the open and close symbols to be something other than ", so we can use " freely in the string itself. Otherwise every instance would have to be escaped.

Substitution

As hinted above, Perl has syntactic elements for variable substitution, and other forms of substitution. These devices are largely unknown in Java. Variable substitution can be used instead of string concatenation (although there is a concatenation operator: see below). This fragment of Java:

String m1 = "Hello ";
String m2 = "World";
String message = m1 + m2;

cannot be implemented like this in Perl:

$m1 = "Hello ";
$m2 = "World";
$message = $m1 + $m2;

(in fact, the value of $message ends up as zero, for reasons to be explained later). We need this:

$m1 = "Hello ";
$m2 = "World";
$message = "$m1 $m2";

The string $message is made by expanding the two strings $m1 and $m2 into a new string. Some books refer to this as `interpolation'.

Perl also supports command substitution, something totally alien to Java. This Perl fragment sets the value of the variable $ps to be the output from running the `ps' command.

$ps = `ps`;

Again, this notation should be familiar to anyone with experience of Unix shell scripting. Of course, this can be done in Java (create a process, create input streams to capture its output, bind the input streams to the process output, create threads to absorb the output, execute the process...) but its very easy to do in Perl.

Another form of substitution is filename substitution. This works similarly to Unix shells. The string is delimited using angle brackets. Here are some examples:

# get the user's home directory
$home = <~>;

# get the names of all files 
# in the /etc directory
@files = </etc/*>;

An example of Perl's syntactic flexibility, which is confusing and irritating to Java programmers, is that almost the same notation as above can be used to do a file input; the following reads all lines from a file specified by file handle f into the array lines.

@lines=<f>;

Data types and type checking

Perl supports a very small set of primitive data types: integer, real, and string. These basic types are called scalars as they store a single atomic value. Perl also supports arrays (indexed and associative) of these items (see below), and references to them. Java does not support explicit references, but does (invisibly) support `handles', which are in a sense references to objects.

Note: Perl does not support a `character' data type like Java's char. Operations on characters are usually treated as operations on strings one character long. Alternatively, characters can be manipulated by their ASCII values. The functions ord and asc convert a one-character string to an ASCII code and vice versa.

Java is strongly typed, and requires that all variables be typed before use. Perl has no such restriction: a variable might be declared (e.g., using $) but need not be typed at the same time. In fact, unless you use Perl in `strict' mode, you don't even need to declare variables before use: they just take on default values the first time they are used.

In Perl, a symbol gets a type when it is first assigned to. Until then it is undefined; the defined function can be used to determine whether a symbol has a value or not:

if (defined ($some_variable))
  {
  ...
  }

As well as scalars, arrays, and references, Perl supports a number of types that have no real equivalents in Java. A `code' variable denotes a subroutine, and is mostly used to construct function pointers. A `typeglob' contains symbol table information, and an `lvalue' is a entity that can be the subject of an assignment and is not one of the other types. There are various tricks you can do with these, but I have not found them to be very useful on many occasions (not because they aren't useful in general, but because I usually look for Java-like ways of doing things). One other type that is useful is the filehandle type, which will be described later.

Lists and arrays

Perl's concept of an array is similar to Java's, but also has elements of a List. For example, where we could say in Java:

String[] months = {"Jan", "Feb", "Mar"};

In Perl we would say:

@months = ("Jan", "Feb", "Mar");

In both cases we have defined and declared an array of strings. In Perl, there is a technical distinction between an array and a list. The right-hand-side of the assignment above is a list, not an array, because it does not have a name. In other words, an array is a `named list' in Perl. However, even the standard Perl functions get confused between lists and arrays; the function wantarray actually takes a list as an argument, not necessarily an array, and the documentation is decent enough to acknowledge this. So, in summary, don't assume that the distinction between `list' and `array' in Perl is important, or maps onto the (important) distinction in Java.

Having defined the array (or list) we can extract elements from it using the subscript operator []. In Java:

String month = months[2];

In Perl:

$month = @months[2];

Notice that both Java and Perl number array elements from zero. Perl also allows sub-arrays to be extracted directly. For example:

@earlyMonths = @months[1,2]

extracts months[1] and month[2] from @months and forms a new array from them. In Java, we could do this by assigning the array elements to a Vector or List, and using the subList method to extract the required elements.

In Java, the number of elements in an array is found like this:

int len = months.length;

In Perl, we have:

$len = scalar(@months);

The reason this works is because the operator scalar forces the evaluation of @months in a scalar context. The nature of context is discussed below; the point to note here is that forcing an array to scalar context returns its length.

Unlike Java, Perl defines what should happen when a scalar is assigned to an array, or vice versa. Such operations are not allowed in Java. Another interesting difference is that Perl does not respect array bounds: you can cheerfully read beyond the ends of the array. In such cases, Perl simply returns null elements. So, even though the size of @months is 3, it is not an error to say:

$month = @months[999];

you just get a null element.

Perl also has built-in support for associative arrays; see below.

As well as extracting elements from lists using indexing, Perl also supports direct assignment of scalar variables from lists. Again, this has no equivalent in Java. The principle may be illustrated using an example:

@months = ("Jan", "Feb", "Mar");
($m1,$m2,$m3)=@months;

Here the variables $m1, etc., are assigned directly from the corresponding elements of @months. This technique allows us to define functions that return multiple values -- or at least give the illusion of doing so.

Hashes

Java Hashtables (java.util.Hashtable) are similar to Perl's associative arrays, or hashes. However, Perl treats a hash as a language construct, while in Java it's implemented in a class. A hash is an array in which the index is a key string, not a number. So, the following Java:

Hashtable h = new Hashtable();
h.put("name", "Kevin");
h.put("address", "London");
System.out.print ("Address of " + h.get("name") + 
  " is " + h.get("address") + "\n");

has this equivalent in Perl:

$h{"name"} = "Kevin";
$h{"address"} = "London";
print ("Address of ", $h{"name"}, " is ",
    $h{"address"}, "\n");

In both cases the output is

Address of Kevin is London

Note that references to the whole associative array -- rather than elements of it -- are made using the % operator, not @ as for ordinary arrays.

An interesting use of an associative array is to store the program's environment variables. These end up in an array $ENV. For example:

$hostname = $ENV{"HOSTNAME"};

References

This section is quite technical, and may be unfamiliar to Java programmers. This is because, unlike Java, Perl supports explicit references to variables. This is important because Perl parameter passing is by value, so if a function is to modify the data passed to it, you must explicitly pass a reference. In Java, everything is passed by value except for objects, which are passed transparently by reference. That is, you don't have to say you are passing a reference, the compiler makes this assumption (Java nerds please don't write in about handles, OK? This explanation is good enough for now). In summary, Java references are invisible to the developer, which makes for simplicity at the expense of flexibility. Perl goes for flexibility at the expense of simplicity.

Perl scalar references are easy enough to declare and use:

# $x is an integer
$x = 2;

# $ref_x is a reference to integer $x
$ref_x = \$x;

# $$ref_x dereferences $ref_x into $x
print $$ref_x, "\n"; 

This produces the output `2', which was the original value of $x.

The operator \ creates a reference to whatever it is applied to. The operator $ applied to a reference dereferences it to its value. You can, of course, create references to references. Incidentally, the combined use of references, weak typing, and garbage collection can lead to problems. Consider this example:

$a = \$b;
$b = \$a;

$a and $b refer to each other, so they can't be garbage collected. This can't happen in Java, because we can't set references explicitly like this.

References are particularly important when used in combination with arrays. This is because Perl doesn't supported multi-dimensional arrays. In addition, as we shall see, there are problems with passing whole arrays as arguments to functions in Perl. Perl has an explicit syntactic device for creating references to arrays, the use of square brackets. So, for example, this code snippet creates a two-dimensional array.

@two_d = ([1,2], [3,4]);

In fact, what it really creates is an array of two references, each of which points to an array of two integers. So, to extract a particular value (let's say row 0, column 1) of this array we could -- if we were feeling masochistic -- dereference it explicitly like this:

my @two_d = ([1,2], [3,4]);

# get the reference to row 0
my $row_ref = $two_d[0];

# dereference the first row into a proper array
my @row = @$row_ref;

# get element 1 from this array.
$elem = $row[1];

In fact, Perl provides an explicit array dereference operator, written `->'. So we could write:

$elem = $two_d[0]->[1];

In this example, the `->' operator dereferences the array reference $two_d[0] into an array, so the index [0] can then be applied directly. In fact, where we dealing with simple square arrays, we can use the much simpler form:

$elem = $two_d[0][1];

which is essentially the same notation that Java uses. However, it's important to understand the technicalities of referencing and dereferencing because you'll need to manipulate references when working with Perl classes.

Operators

Comparison

Comparison operators in Perl appear bizarre to a Java programmer. First, there are specific comparison operators for strings and numbers. Second, the result type of a comparison depends on the entities being compared. In Java, comparison operators cannot be applied to anything except numbers (and number-like entities), and the result type is always boolean.

The number comparison operators are essentially the same in Perl as in Java: ==, !=, >, <, >=, and <=. There is one additional operator, <=>, that has no direct equivalent in Java; it returns the number 1 if the lhs is greater than the rhs, -1 if the lhs is less than the rhs, and 0 if they are equal. All the other numeric comparison operators return the number 1 if the comparison is true, and 0 if it is not. There is no specific boolean type.

The following table shows the standard Perl string comparison operators and their Java equivalents, where a and b are strings (or Strings).

Perl	Java
$a gt $b	a.compareTo(b) > 0
$a ge $b	a.compareTo(b) >= 0
$a lt $b	a.compareTo(b) < 0
$a le $b	a.compareTo(b) <= 0
$a ne $b	!a.equals(b)
$a eq $b	a.equals(b)
$a cmp $b	a.compareTo(b)

All string comparisons are done on the contents of the string. Java is unusual among modern programming languages in that when the `==' operator is applied to two strings, it does not produce true if the contents are equal. In Java, two Strings are equal only if they reference the same object, not if they have the same contents. Of course, Java's take on this is more technically correct: why should a comparison of two objects have defined semantics for Strings and not for other objects? Nevertheless, it is a rich source of error in Java programs. The Perl string comparison operators (except cmp) return the string "1" if the comparison is true, and "", the empty string, if false. Greater than/less than comparisons are done according to ASCII ordering. The cmp operator returns the numbers -1, 0, or 1 like the <=> operator does for numbers.

To add to the confusion some, but not all, number operators can also be applied to strings.

The only consolation in all this is that the results of the comparison operators are interpreted correctly by the conditional, looping, and logical constructs, so the exact results themselves may not be important. For example, constructs like

if (1 != 2) { ... }

and

if ("hello" ne "world) { ... }

behave in much the same way as common sense would suggest, despite the unfamiliar mechanism.

Logical

Comparisons can be conjoined and disjoined using the && and || operators just as in Java. The words and and or can be used instead if preferred. The result type of the conjunction or disjunction depends on the types of the individual terms, as well as their values, as was the case for the comparison operators. So the comparison

("a" eq "a") || ("a" eq "b")

returns the string "1", because both the individual terms return a string.

Logical operators short-circuit in Perl as they do in Java. This means, for example, that if the first term of an AND conjunction is false, the rest of the terms are never evaluated, as the result must be false. This leads to the totally bizarre situation that not only does the result of the operator change according to the values of the variables being compared, but the type can also change. In the example below, assume that $a and $b are numbers, and $c and $d are strings.

($a == $b) || ($c eq $d)

If it turns out to be true that the numbers $a and $b are indeed equal, then the second term is never evaluated, and the result will be the number 1. If $a and $b are not equal, then the second term is executed, and the result will be a string! This sort of behaviour is about as far away from Java's strongly-typed comparisons as you can get. Happily, it does not usually cause a problem in practice because the looping and conditional operators are designed to handle the output of the conditional operators.

File tests

Perl's file test operators are derived from shell programming, and have no direct equivalent in Java. They can mostly be emulated using methods in java.io.File, but the Perl operators are more convenient, if rather cryptic. There are a large number of file operators; here are a few examples.

# test if file exists
if (-e $filename) {...} 

# test if file is a directory 
if (-d $filename) {...} 

# test if file is a tty 
if (-t $filename) {...} 

# test if file is a text file 
if (-T $filename) {...} 

Note that the `-t' operator is probably impossible to implement at all in Java, unless we resort to using native method calls.

Arithmetic

Perl has much the same set of arithmetic operators as Java has, including +=, --, etc. Perl also has a power operator **, which needs to be done as a method call in Java. Perl does not concatenate strings using + as Java does: use variable expansion (above) or the concatenation operator `.'.

$message = "Hello " . "World";

The standard Perl library contains the usual maths functions (sin, cos, log, etc). What's more, there is a very nice implementation of complex number functionality in Math::Complex. This package also installs overloads (see below) for the standard arithmetic operators (+, -, etc) that makes them work on complex numbers. Even if you aren't interested in complex number maths, it's worth having a look at this package to see how operator overloading works.

Operator overloading

If, like me, you lament the decision to omit operator overloading from Java, then you'll be pleased to know that it is fully supported in Perl. Using operator overloading, you can define the behaviour of standard operators (like + and -) on program-defined classes.

Now, of course, we can get the same effect in Java using methods. Suppose I define a class that represents exact fractions (e.g., fractions whose numerator and denominator are integers, but whose value is non-integer, like 2/3). I can provide methods to do arithmetic on these objects easily enough. So, in Java, to add three fractions:

Frac frac1 = new Frac (2,3);
Frac frac2 = new Frac (3,4);
Frac frac3 = new Frac (5,6);
Frac frac4 = (frac1.add(frac2)).add(frac3);

But using operator overloading, in Perl I could write:

$frac1 = new Frac (2,3);
$frac2 = new Frac (3,4);
$frac3 = new Frac (5,6);
$frac3 = $frac1 + $frac2 + $frac3;

which I think is a lot more elegant. Now, operator overloading isn't without its problems, and it wasn't left out of Java for no good reason. However, it's nice to know that Perl does offer the functionality if you want it. Of course, it can be taken to extremes. You may remember that in C++ the `<<' operator (normally a bit-shift) is overloaded on output streams, so that you can do output like this:

cout << "Hello, world!" << endl; 

This uses the operator in two totally different contexts, which can be confusing and unmanageable. You can do this stuff in Perl if you like. As this is supposed to be a comparison of Perl and Java, and you can't overload operators in Java, I don't propose to say anything more about the subject. If you are interested, look in Math::Complex to see it at work.

Conditionals and loops

True and false

In Java, comparison operators yield a boolean result that can be used as the argument to if(), while(), etc. Perl has no specific boolean type, and conditionals can take any data type as input. We have seen that the results, and result types, of the comparison and logical operators depend on the types of the operands. This means that Perl has a very different notion of `true' and `false' to Java. The following table shows how flexible Perl's notion of `truth' is compared to Java's:

Java	Perl
true	a number other than 0, any non-empty list, any string except the empty String or "0"
false	0, an empty list, an empty string, the string "0"

In addition, an undefined scalar is taken to be `false', so some perl functions are written to return undef to indicate some sort of terminating condition.

Conditionals

if(), and else are used exactly as in Java. However, statements must be grouped using braces; the braces are never optional as they sometimes are in Java. elseif is `elsif' in Perl, for some unaccountable reason.

Perl has no equivalent of the Java switch statement, so it has to be imitated using if(){...} elsif(){...}, etc.

A Perl loop construct that has no direct equivalent in Java is foreach. This iterates over the elements of a list (or array). The example below iterates over the array months, setting the variable $m to the current element of @months at each step. [Update 08/07: Java 5, a.k.a. JDK1.5, now has this feature.]

@months = ("Jan", "Feb", "Mar");
$n = 1;
foreach $m (@months)
  {
  print "month $n is $m\n";
  $n++;
  }

Java conditionals must have their dependent statements grouped in braces, even if there is only one such statement. In Java, this notation is optional. Because this is rather ugly, many Perl developer make use of the qualified statements. These are single statements whose execution is governed by a conditional. For example, the following Java:

if (x == 4) x = 0;

may be conveniently written in Perl as:

$x = 0 if ($x == 4);

Perl also has an `unless' conditional, which is equivalent to `if not'. This can be used both with statement blocks or qualified statements.

Note that Perl has no switch statement, so you'll need to use if...elsif...elsif instead.

Loops

Perl supports while() {...} and do {...} while() constructs exactly like Java. However, Perl uses next to indicate that the next iteration should begin immediately (like Java's continue) and last to exit the loop (like Java's break).

Perl's for loop is identical to Java's, but the braces around the loop body are mandatory, even if the loop has only one statement.

Functions

Calling functions

In Java, method calls have a fairly rigid syntax. Although methods can be overloaded, completely arbitrary argument passing is not allowed. Moreover, method parameters must be properly demarcated by brackets. For example, in Java we might say:

String name = "fred";
System.out.print ("Hello " + name + "\n");

In Perl we could have:

$name = "fred";
print ("Hello ", $name, "\n");

That is, the print function takes an arbitrary number of arguments. Another distinction is that the brackets are not always necessary. For example:

$name = "fred";
print "Hello ", $name, "\n";

However, many Perl programmers quite sensibly eschew this usage, as it can be hard to follow. Function prototypes (see below) can be used to tell Perl how many arguments a function should expect.

NB: that there is another form of print, which takes a file handle as an argument. For example, if f is a file handle (see below) we can print to the file like this:

print (f "Hello", $name, "\n");

Note that there is conventionally no delimiter between the file handle and the argument list!

Like Java, Perl functions can return only one value to the caller. However, because Perl supports direct assignment of scalars from arrays (see above), we can get the illusion of returning multiple values if we return a list. For example, the function split() splits a string at a delimiter and returns both parts.

($before,$after) = split("=", "name=value");

We haven't really returned two values here, but it looks as though we have.

Defining functions

Function definition is far less elegant in Perl than in Java. There are no formal (named) parameters; instead, the entire parameter list is passed in an array called @_. It is good style to extract the array elements into named variables on entry to the function; failing to do so leads to ghastly, unreadable functions.

The following example shows how a function may be defined and called. This function, logN, calculates the logarithm of a number to an arbitrary number base.

sub logN{
  $number = @_[0];
  $radix = @_[1];
  $result = log($number)/log($radix);
  return $result;
}
print logN(128,2);

The keyword `sub' (subroutine) introduces the function; the function body is defined within the braces.

NB: some versions of Perl require the function to be called using "&" before the name. So we may have:

print &logN(128,2);

Modern Perls don't require this, but it may be advisable to call functions this way for backward compatibility.

Like Java, functions need not be defined above the point in the file at which they are called.

Perl supports a limited mechanism for function prototyping. In the example above, the function logN was defined without a prototype, which means that it would not be an error to call it like this:

logN(128, 2, $whoops);

The argument $whoops would be ignored, but this does make it easy to make trivial programming errors. To reduce the likelihood of such errors, we can define logN with a signature like this:

sub logN($$){
  ...
}

The two $ signs denote that the function expects two scalar variables. Note that there is no way to stipulate that they be of specific type. Because compilation proceeds from top-to-bottom, Perl programs don't benefit from the use of prototypes unless the functions are declared before they are used. Because it can inconvenient -- or impossible -- to define all functions between they are used, Perl allows function prototypes. These are simply declarations of the function name and arguments. So we could write something like this:

sub logN($$);

print logN(128,2);

sub logN($$){
 ...
}

Although the logN function is used before it is defined, the function prototype allows the arguments to be checked.

Very important: unlike in Java, variables defined within the function body are not local to that function. Unless otherwise stated, all variables are global. To restrict the scope of variables, use the my and local keywords. For example:

sub loop{
  my $i;
  local $j = 1;
  for ($i = 0; $i != 10; $i++)
    {
    ...
    }
}

Here the variable $j is `local'; this means that its scope includes the loop function and any functions called within it. $i is defined using my; this means that it is entirely local to that function.

A peculiar consequence (peculiar to a Java programmer, that is) of Perl's argument passing strategy can be discovered by running this piece of code:

sub test
  {
  $num = scalar(@_); 
  print "args=", $num, "\n";
  }

@a = (1, 2);
@b = (3, 4);
test(@a, @b);

The first line of test() gets the size of the array of arguments passed to the function. We call it as test(@a,@b), so how many arguments are there? If you say `2', you're thinking like a Java programmer. The real answer is `4' because Perl simply flattens the arguments into a single list and passes this flat list to test(). Again, it's straightforward to deal with if you are expecting this behaviour: simply pass references to the two arrays. References are scalars, so they aren't flattened like this.

Context

The concept of `context' is crucial one in Perl, and one that has no counterpart in Java. Because Java is strongly typed, the types of all variables are known at compile time. In Perl, variable types can be left undefined until runtime. This means that there must be a mechanism to resolve the types of ambiguously typed variables. For example, suppose the compiler executes this line:

$t1 = 1 + test();

The function test() can return any type of variable. However, only certain types can usefully be added to `1'. In this case, the evaluation of test() is said to be in scalar context in general, and integer context in particular. If the function returns a value of a fixed type, then Perl attempts to coerce it into a suitable type for the context. For example, if it returns a string then Perl attempts to convert it into an integer. If the string can't be converted (e.g., it does not consist of digits), then it is coerced to zero. If the value returned is a list, it is coerced to an integer representing its length. This can often be convenient, but is initially confusing for Java developers used to a strongly-typed environment.

Although Perl will attempt to coerce a value to the appropriate context, it is possible for a function to find out what context its caller is executing in. This opens the possibility for it to return a different value according to the context. This can be illustrated using an example.

sub test{
  return (1, 2) if wantarray;
  return 99;
}

$t1 = 1 + test();
print $t1 . "\n"; 
@t1 = test();
print $t1[0] . "\n";

This code produces the following output:

100
1

The statement

$t1 = 1 + test();

calls test() in scalar context. Therefore, if wantarray is false. So in this context the function returns `99', which is added to 1 to give 100. However, the statement

@t1 = test();

tries to assign the result of executing test() to an array. Thus in the function if wantarray is true, and the function returns the array (1, 2). The caller then extracts item zero from this array.

Needless to say, this technique has to be used with care.

File input and output

In Java, basic file I/O operations can be carried out using the rather complex classes in the java.io package. To process text files, these classes usually have to be used in combination. Perl has built in functions for handling files, particularly text files. The basic steps are the same, however: open a file, do something, close it.

Opening a file

Use the open function, passing a file handle identifier, and a filename. The filename should be preceded by characters indicating the open mode. These will be familiar to shell programmers:

filename       open for reading 
>filename      open for writing, delete existing file
>>filename     open for writing, append to existing file
>+filename     open for reading and writing

You can also open a pipe to another command for reading or writing:

|command    open pipe to command for writing 
command|    open pipe to command for reading 

Here are some examples.

# open a file for reading
open(f "/etc/group");

# open a file for appending
open(f ">>log");

# execute command dmesg and open
#  its output stream for reading 
open(f "dmesg|");

Note that a file handle is a variable type in its own right: it isn't a number or a string. It does not require an identifying character (like $ or @) to introduce it. Perl defines the special file handles STDIN and STDOUT for standard input and standard output.

Writing a file

A simple way to write a file is to use the print operator with a file handle argument:

print (f "Hello World");

Note the absence of a separator between f and the string.

As an example, here is how to open a file for writing, and write a single line of text. Don't forget to close the file afterwards.

open(f, ">log");
print(f "Hello World\n");
close(f);

In Java, the closest equivalent would be something like this:

FileOuputStream fos = new FileOutputStream ("log");
fos.println("Hello World");
fos.close();

If you try to print an array, you'll find it is output with no delimiters between the elements, which is not very helpful. A quick and dirty way to output a whole array, with elements separated by spaces, is to put it in double quotes:

@months = ("Jan", "Feb", "Mar");
open(f, ">dummy");
print(f "@months");
close(f);

The `interpolation' carried out on quoted strings automatically inserts spaces between the array elements.

Reading a file

The read operator is <f>, where f is a file handle. The amount of data read depends on the variable it is read into. If the variable is a scalar, then the next line is read. If it is an array, the file is read a line at a time until the end of the file, with each new line going into a new element of the array. Clearly this will use a lot of memory if the file is large.

So, to read a single line from file log:

open(f, "log");
$line = <f>;
close(f);

The closest Java equivalent is just too ugly to write. Notice how the Perl file handling functions are tailored to manipulating ASCII text files. The Java scheme is much more flexible, but very ugly when all you want to do is read or write a text file.

Object-oriented Perl

Perl has some object-oriented functionality, but it is somewhat different to that offered by Java. In particular, there is a strong overlap between Perl's concept of `package' and its concept of `class'. You may remember that a Perl package is a group of functions, not a group of classes as it is in Java. If a package is a group of functions, it should be clear that it is not all that different from a class; however, notions like instance variables, inheritance, and constructors are not fundamentally part of the Perl language; they can be implemented, but require some work of the programmer. As a result, various idioms have developed for handling such features. They are not part of the basic language, and are not the only way to implement OO functionality in Perl.

Classes and packages

In summary, a Perl class is fundamentally a package. Consider the following Java class definition.

public class Test
{
public void m(String arg)
  {
  System.out.println ("This is object " + this + 
     ", with arg " + arg);
  }
}

The corresponding Perl class definition will look something like this.

package Test;
sub m 
  {
  my $self = shift;
  my $arg = shift;
  print "This is object $self, with arg $arg\n";
  }

So far, not a million miles away from Java. However, you'll notice that we've written the method m to get something called $self from the first argument supplied, while the `real' argument will come from the second actual argument. The keyword shift shifts all the elements of an array one place to the left, and returns the left-most element. When shift is used without an argument -- as it is here -- it operates implicitly on the argument list. So the first shift shifts something out into $self, and leaves the original arguments in the argument array. The second shift shifts the argument supplied by the called -- the `real' argument -- into $arg. What is the `something' that formed the first argument? It turns out that it's either the class name, or a reference to an object of that class (more details below). In either case, it's supplied automatically as part of the method invocation. The caller does not have to worry about it, but it's crucially important to the object. Passing object information as an implicit first parameter to a method is characteristic of most object-oriented languages, but normally it's invisible and the developer does not worry about it. In Perl it's explicit. To get the real arguments we have to shift the object reference somewhere first.

To call method m at the class level in Java, we would write (inside another class):

Test.m(1);

which will produce output similar to:

This is object 0xFFD4421, with arg 1

In perl, we would write this:

Test->m(1);

and the output would be

This is object Test, with arg 1

The use of the operator `->' here simply tells Perl to call the method m in such a way as to pass the object information in the first argument. We'll discuss later where this information comes from in a proper example.

Actually, I've told a little white lie: you would not be able to call the method m() at the class level in Java, because it was not defined static. This illustrates another difference between Java and object-oriented Perl: methods may be called at the class level or the object level (see below) without any special provision. The only difference is in the implicit first argument passed to the method.

Instances

In practice, of course, we would more frequently wish to create instances of the class, and call methods on the instances, not on the class. In Java, we would do something like this:

Test test = new Test();
test.m(1);

To understand the equivalent in Perl, we need to understand something called a `blessed reference', and also that Perl does not automatically provide a constructor for the class: you must do this, by initializing a blessed reference. The blessed reference will then serve as a reference for all future uses of that instance.

Although probably unfamiliar to Java programmers, a blessed reference is nothing more than a reference that has been told which package it is to be associated with. When such a reference is used with the -> operator, the function call is made on a method with the specified name in the package for which the reference was blessed. This gives us a rudimentary way of modelling object behaviour, because the reference can be a reference to the object's state -- but I'm getting ahead of myself. For the time being, consider this code, which makes the same method call as the example above.

my $tester = "Fred";
my $ref_tester = \$tester;
bless $ref_tester, Test;
$ref_tester->m(1);

What's going on here, and what's `Fred'? The fact is, ``Fred'' is irrelevant, but we need a reference to something to `bless'. So in this case we create a reference to a simple string. The bless operator attaches it to the package (class) Test; so the last line calls the method m() in the package (class) to which ref_tester has been blessed. When m() is called this way, the first argument to the method -- supplied automatically -- is, in fact, simply the reference to the string "Fred". This isn't very useful in itself, but we'll see how to make it useful in a while.

Constructors

So far, so good, if not very Java-like. The clever part is to put the `bless' code inside a method, and call it a constructor. Remember that we don't get constructors for free in Perl, like we do in Java. So, here is the same package Test, with a constructor called new (the name `new' is not mandatory, as it is in Java; it's merely a convention):

package Test;
          
sub new    
  {       
  my $tester = "Fred";
  my $self = bless \$tester, shift;
  return $self;
  }

sub m 
  {
  my $classname = shift;
  my $arg = shift;
  print "This is class $classname, with arg $arg\n";
  }

To call this method we will use code which instantiates Test, and calls the method m() on the reference returned:

my $test = new Test();
$test->m(1);

Notice that now we have something that looks very similar to Java. We could, of course, pass arguments to the constructor if we wished. But hang on a minute: what's new Test() in Perl? It's just another way of writing

Test->new();

which is the same syntax we used earlier; new Test() just looks a bit more Java-like, and works exactly the same.

If you've been paying attention, you may have notice a slight subterfuge on my part: I have oversimplified by not saying what is really passed to the class methods by the -> operator. It works like this. If we use this operator with a class name (strictly a package name), then the first argument to the called function is simply a scalar representing the name of the class. There isn't much you can do with this scalar, but you can pass it to bless, which sticks the name into a reference and returns the resulting `blessed' reference. Note that what comes out of bless is a reference to some variable or other. When we apply -> to this reference to make a method call, then the first argument to the called method is the blessed reference itself, that is, the output from the original bless call.

In other words, if a is a blessed reference from class P, then this call:

a->m();

calls method m() in class P, passing a as the first argument to m(). Method m() can then extract that argument and use it to determine its own state, as we shall see. Note that this process is exactly what happens in C++ and Java, you just don't see it close up like you do in Perl.

Managing instance state

In the example above, we used a string reference called `tester' to indicate the class the method should be called on. Again, it doesn't matter what type that reference is, or what it contains, it's the `bless' that makes it work. Given that this is the case, it should be clear that we can bless anything, not just a string. If we bless a hash, rather than a string, we've got a simple method for handling state: we simply pass it around in a hash. To illustrate this, here is a class definition that exhibits `proper' object oriented behaviour, where each object has its own state. We'll examine it in more detail below. Note that the manipulation of the objects is not very different from what we do in Java, although the class definition is rather different.

my $test1 = Test->new(1);
my $test2 = Test->new(2);

$test1->printX();

$test2->setX(3);
$test2->printX();

#### class def starts here ####

package Test;

sub new
  {
  my $self = bless {}, shift;
  my $arg = shift;
  $self->{x} = $arg;
  return $self;
  }       
          
sub printX
  {
  my $self = shift;
  my $x = $self->{x};
  print "This value of x is $x\n";
  }

sub setX
  {
  my $self = shift;
  $self->{x} = shift;
  }

The constructor new() creates a `blessed hashtable', and returns a reference to it to the caller. Remember that bless takes two arguments: the thing to bless and the package it is attached to. The shift operator gets the first argument to the function new, which here is simply the class name determined by the Perl runtime. This is exactly what bless needs. So,

$self = bless {}, shift;

means `apply bless' to an empty hash and this current class name'. We then take the argument supplied to the constructor by its called, and place it in the hash, under the name `x'. This is equivalent to setting an instance variable called `x'.

my $arg = shift; 
$self->{x} = $arg;

When the constructor returns $self to the caller, it is really only returning a reference to the hash, which now contains the state of the object. However, this reference is `blessed' with the class name, so Perl will not which class to make the method call on when the reference is the subject of a method call.

Now let's look at the method printX. This method simply prints the value of the `instance variable' x. Because the Perl runtime supplies the blessed reference itself in the first argument, and this reference is to a hash that contains the object's state, the printX method simply shifts the state hash into a variable called $self.

  my $self = shift;

We can then get the value of the instance variable `x' from the hash, and print it.

  my $x = $self->{x};  
  print "This value of x is $x\n";

The method setX works in a similar way: it gets the argument supplied to the method (after shifting the object reference into $self) and puts it into the hash.

In summary, when we work with objects in Perl, we are generally working with hashes that contain (1) the object's state, and (2) the classname. There are other ways to get object-oriented behaviour, but one will be enough for this short article.

So what is to stop the user of the object simply manipulating the hash itself? The short answer is `nothing'. Perl's object-oriented behaviour really has no concept of access control: essentially, all data is public.

Inheritance

There's one final point to deal with in our discussion of object-oriented Perl: inheritance. In Java, again, the process of making calls on methods which are inherited from a superclass is largely invisible. In Perl, it's much more in your face.

To start with, we define a class's base class using the `@ISA' array. So:

package Dog;
use Mammal;
@ISA = ("Mammal");

This says that the current class is called Dog, we want to have access to functions defined in Mammal (assuming it's not in the same file), and Mammal is the superclass of this class. Actually, for technical reasons concerning identifier scope that I have got space to go into here, we don't usually use ISA this way because it generates a load of compiler warnings in strict mode. Instead, we usually say

package Dog;
use base qw(Mammal);

which does the same thing without the grumbles.

All this is well and good, but what does ISA do? Essentially it provides a place for the Perl runtime to look for methods that are called on the current class, but aren't defined there. If a method is so defined, then we don't need ISA. But then, if all methods are defined in all classes, we don't need inheritance.

ISA searches are upwards recursive, so that if any class in the ISA chain has the method defined it will get called. At the top of the hierarchy is the class called UNIVERSAL. This has much the same role as java.lang.object in Java: to provide basic functionality that all classes will have access to. Previous versions of Perl left it to the developer to provide this functionality, but modern versions define simple methods like isa() which tests whether the class is of a named type, and can() which tests whether a method is defined (in Java, we'd need to use the reflection API to do this). However, it remains possible to extend UNIVERSAL, something which has no equivalent in Java.

What if we need a method in a particular class to call its own superclass? In Java, we'd use super to do this, either on it's own in a constructor, or with a method name elsewhere. Perl uses the same technique, but with slightly different syntax. This is best illustrated using a comparison. In Java:

public class Dog extends Mammal
  {
  public void getDistinguishingFeatures()
    {
    return super.getDistinguishingFeatures()
      + ", barks, chases cats";
    }
  }

And in Perl:

package Dog;
use base qw(Animal);

sub getDistinguishingFeatures
  {
  my $self = shift;
  return $self->SUPER::getDistinguishingFeatures()
      . ", barks, chases cats";
  }

However, in Java there is a simplified form of super for use in constructors, because we don't need to supply a method name (the constructor always takes the same name as the class). In Perl, there is no mandatory name for a constructor, so a constructor must call it's superclass's constructor by name. For this reason, it makes sense to use a common name (like new) for all constructors.

You may have noticed that ISA is an array. Does this tell you anything? It turns out that Perl supports multiple inheritance. You may not like this idea -- the Java language developers didn't -- but it's there; you don't have to use it if you don't want to. If you do use it, you need to use it with care just as you do with other languages that support it. For example, there's nothing to stop a class W inheriting class X twice, by inheriting from Y and Z that themselves are derived from X. If this happens, it is possible that you'll end up with the methods in X getting called more than once for each method in W.

Comparison

To sum up, the following table provides a brief comparison of the availability of various OO features in Java and in Perl.

Feature	Java	Perl
Class methods	Yes, using static	Yes, but no compile-time enforcement
Instance methods	Yes	Yes, using blessed references
Class variables	Yes, using static	Yes, of a sort, using package-scope variables
Inheritance	Yes	Yes
Multiple inheritance	No	Yes
Polymorphism (type of a reference determined at runtime)	Yes	Yes
Constructor	Yes, standardised method naming	Yes, any method can be a constructor
Destructor	Yes, method finalize called at the whim of the garbage collector	Yes, method DESTROY called at the whim of the garbage collector
Operator overloading	No	Yes
Instantiation by name at runtime	Yes, using reflection	Yes
Method calling by name at runtime	Yes, using reflection	Yes
Method access control	Yes, using public, protected, etc	Not easily. By convention, `private' methods are denoted using names beginning with underscores, and programmers are expected to respect this convention when using each other's classes
Inner classes	Yes	No, although this behaviour can be simulated using other techniques
Abstract classes	Yes	No, but you can define a class which cannot be instantiated, by making its constructor throw an exception. It probably isn't possible to stop it being instantiated by indirect methods, however
Interfaces	Yes	No; Perl is weakly typed, so the notion of an interface makes little sense. A common use of interfaces in Java is to specify that a method takes an argument which represents an object with certain methods. In Perl, there is nothing to stop a method being supplied with any type of argument at all. At runtime, you can use the can() method to check whether the object you get exposes the methods you expect

Regular expressions

Perl has very comprehensive regular expression support built right into the language. Of course, we can use regular expression techniques in Java, but with the logic implemented in classes. If a program does a lot of regular expression manipulation, Perl's syntax is very convenient, albeit somewhat opaque. Perl's regular expressions mostly follow the POSIX standard, which is well documented elsewhere; the syntax is beyond the scope of this article. Here are a few examples.

# Match if $x contains `world'
if ($x =~ /world/)
  {
  ...
  }

# replace all instances of `placeholder' in string
#  $s with the contents of variable $replacement 
$s =~ s/placeholder/$replacement/g 

The final `g' indicates that there may be more than one match on a line.

Because Perl regular expressions have no equivalent in Java, this is probably not the place to pursue the matter.

Exception handling

The core of Perl's exception handling is the die keyword. The execution of die causes the current function to be aborted, and the exception to be raised in the caller. The caller can either trap the exception, or allow it to bubble up to its own caller. Eventually, the exception will be either trapped and handled, or passed out to the Perl runtime which will abort the program. This behaviour is, in outline, very similar to what happens in Java. The code below shows a simply example, in which eval() is used to trap the exception. eval() has a number of uses; here it is simply being used as a function that can run other Perl code.

sub test1{
  die "oops";
  print ("test1 OK\n");
}

sub test2{
  test1();
  print ("test2 OK\n");
} 

eval
  {
  test2();
  };
if ($@)
  {
  print "Error: $@\n";
  }

Here test2() calls test1(), which raises the exception and passes an error message. test1() aborts before the print line, as does test2(), because it does not trap the exception. The call to test2() was in an eval(), so the exception just causes eval() to set an error message; it does not abort the eval(). The if ($@) line just prints the error message that was set by eval; part of this will be the original argument to die.

So, in this example, die is loosely equivalent to throw, eval to try, and if ($@) to catch. However, this technique uses a simple string to indicate the exception, and thus exceptions cannot be typed. In Java, we typically use a hierarchy of exceptions, and allow methods to catch specific subtypes while allowing others to propagate out to the caller. Recent versions of Perl support a similar mechanism, using the object-oriented extensions. The standard Error package allows object-oriented exception handling that is very similar to Java's, even using the same keywords: try and catch.

Summary

We've seen that Perl offers many of the same features as Java, and can be used in a Java-like way if you like. It can also be used in a non-Java-like way, and its a good idea to become familiar with this style of Perl as well, if you have to read code written by other people. Perl also offers features that have no direct counterpart in Java, like command substitution and regular expression processing.

In this short article we have only scratched the surface of the Perl language. Among the features that the language supports, and which we haven't even mentioned, are: threads, unicode, localization, data structures, interactive debugging, signal handling, and interprocess communication. But that's a job for another day.

Categories: software development, Java, Perl Last update Jul 07 2020