Variable and method names use the fooBar capitalization style per the Java (TM) Servlet API specification.
Java (TM) allow multiple signatures for each method, while Perl only allows one. Luckily, the Java (TM) API specifies few methods with multiple signatures, and those that do exist are easy to collapse into one method simply by allowing parameters to be optional and/or undef values. It turns out to be a non-issue.
Return values are mapped from Java (TM) to the Perl API as such:
The Java (TM) version of the Servlet API is mostly comprised of
interfaces. They cannot be instantiated directly but rather must be
implemented by classes. Their function is to specify attributes and
methods that must be provided by the implementation classes. Perl has
no equivalent builtin mechanism, so we simply provide a package for
the interface (to enable isa() type checking) and leave
it to servlet container developers to provide implementations.
The API uses Exception::Class for exceptions. It
uses die() to throw them and eval() to catch
them. Servlet::Util::Exception
inherits from Exception::Class::Base and is itself
the base class for all exceptions used by the Servlet API, whether
part of the API specification or provided as utilities.
The API provides Servlet::Util::Event as a base class for event objects.
Perl's IO::Handle provides an excellent I/O subsystem with almost all of the functionality needed for input and output streams. It does not provide seeking functionality, leaving that to IO::Seekable, but I don't see that being a problem. Also, containers will likely provide instances of IO::Socket as input and output handles, at least some of the time, and that class is not seekable.