The Legion of the Bouncy Castle has released version 1.31
of the Bouncy Castle Java Cryptography API, an open source,
clean-room implementation of the Java Cryptography Extension (JCE).
It supports X.509 certificates, PKCS12, S/MIME, CMS, PKCS7, and lots of other juicy acronyms. It also includes its own light-weight crypto API that works in Java 1.0 and later, and does not depend on the JCE.
Version 1.31 has "bug and compatibility fixes for the PGP library as well as some defects
fixed in the X.509 extension processing, ECDSA key encoding and the EC point encoding.
The most notable new addition is the support for very large files in the SMIME package
via streaming."
Download it while it's still legal.
MySQL A.B. has released Eventum 1.7.0, an open source issue tracking system designed for the needs of technical support teams in particular. Eventum is published under the GPL.
Sun's posted a maintenance release of JSR-36 Connected Device Configuration. The changes are extremely minor and editorial. The most significant is, "A conformant implementation need only support loopback communication to the local host. Network communication to external hosts is not required. If an implementation does not support network communication to external hosts, the system property java.net.isRestricted shall be set to 'true'. If java.net.isRestricted is set to 'true', then the APIs of java.net and java.microedition.io shall throw exceptions as specified (i.e., java.io.IOException and subclasses) at any point that external communication would be required, e.g., resolving a host name or establishing a connection."
There's also a maintenance update to the Foundation Profile, that's equally minor. An update to the Personal Basis Profile is a little larger, but not hugely more significant. It's just clarifications of assorted minor points.
Sun has posted the early draft review of JSR-270 Java SE 6 Release Contents. The download appears to be corrupt, but Mark Reinhold has posted a nice summary which I quote from here:
client 2d GIF image writer awt Access to desktop helper applications Fast splash screens Improved modal dialogs System-tray support i18n Pluggable locale data Resource-bundle enhancements Unicode string normalization swing Baseline/gap APIs Improve Swing drag-&-drop JTabbedPane: Tabs as components JTable sorting, filtering, and highlighting SwingWorker Text-component printing core – JSR 223: Scripting for the Java Platform debug Access to heap contents Attach-on-demand Multiple simultaneous agents libs Array reallocation Collections: Deques Collections: Sorted sets and maps with bidirectional navigation Critical file-I/O enhancements Floating point: Add core IEEE 754 recommended functions java.util.concurrent updates JSR 202: Java Class-File Specification Update Password prompting Reflective access to parameter names Service-provider lookup m&m Generalized lock monitoring Generalized MBean descriptors Generic annotations for MBean descriptor contents MXBeans net Internationalized domain names Internationalized resource identifiers Programmatic access to network parameters Simple HTTP cookie manager sec JSR 105: XML Digital-Signature APIs tools JSR 199: Java Compiler API JSR 269: Pluggable Annotation-Processing API ee – JSR 250: Common Annotations jdbc JSR 221: JDBC 4.0 xml JavaBeans Activation Framework (JAF) 1.1 JSR 173: Streaming API for XML (StAX) JSR 181: Web-Services Metadata JSR 222: Java Architecture for XML Binding (JAXB) 2.0 JSR 224: Java API for XML Web Services (JAX-WS) 2.0
Comments are due by February 19.
Etienne M. Gagnon, Ben Menking, Mariusz Nowostawski, Komivi Kevin Agbakpem, and Kis Gergely have released SableCC 3.2, "an object-oriented framework that generates compilers (and interpreters) in the Java programming language. This framework is based on two fundamental design decisions. Firstly, the framework uses object-oriented techniques to automatically build a strictly-typed abstract syntax tree. Secondly, the framework generates tree-walker classes using an extended version of the visitor design pattern which enables the implementation of actions on the nodes of the abstract syntax tree using inheritance." SableCC is published under the LGPL.
IBM's alphaWorks has released API Usage Scanner, a tool that scans Java bytecode to detect references to targeted APIs.
Binary compatibility and toleration are some of the biggest and most frequently-experienced problems for customers. They often run into unpredictable breakages when upgrading or applying services to components of the software stack on which their applications run. One of the leading causes for these breakages is the use of unpublished, internal APIs between software products. Therefore, when an upgrade or service is applied, some internal APIs can change and break the dependent products, thus disrupting the stability of a customer's operation. To maintain and improve product stability, these fragile dependencies must be eliminated.
The API Usage Scanner (AUS) tool can help quickly locate these internal API usages so that compatibility problems can be avoided or remedied. AUS is a pure Java™ utility that scans Java bytecode for references to targeted APIs. In other words, AUS can be used to scan one product to detect the use of another product's internal APIs. Once these usages are identified, the situation can be remedied by replacing those internal APIs with published ones. If a suitable published API is not available, the product team can alert the API developers of the existence of fragile interfaces between the two products and request an agreement to hold that API stable until a suitable replacement can be provided.
SpaceRoots has released Mantissa 6.1, "a collection of various mathematical tools aimed towards for simulation. It is not a complete mathematical library like GSL, NAG or IMSL, but it contains various algorithms useful for dynamics simulation and 3D geometry computation." Its algorithms include:
- a small set of linear algebra classes
- a least squares estimator
- some curve fitting classes
- several ordinary differentials equations integrators, either with fixed steps or adaptive stepsize control (see below)
- vectors and rotations in a three dimensional space
- algebra-related classes like rational and double polynomials
- various orthogonal polynomials:
- Chebyshev
- Hermite
- Laguerre
- Legendre
- some random numbers and vectors generation classes:
- Robert M. Ziff four tap shift register (contributed by Bill Maier)
- Makoto Matsumoto and Takuji Nishimura Mersenne twister
- generators for vectors with correlated components
- some basic (min, max, mean, standard deviation) statistical analysis classes
- some optimization algorithms using direct search methods:
- the Nelder-Mead simplex method
- Virginia Torczon's multi-directional method
- Ordinary
Differential Equation integration including the following methods:
- Euler
- Midpoint
- classical Runge-Kutta
- Gill
- 3/8
- Higham and Hall 5(4)
- Dormand-Prince 5(4)
- Dormand-Prince 8(5,3)
- Gragg-Bulirsch-Stoer
IBM's alphaWorks has released version 1.2.7 of the IBM Toolkit for MPEG-4, a Java class library for working with MPEG-4 video and audio. Version 1.2.7 improves RTSP/RTP streaming compatibility.
IBM's alphaWorks has updated HeapRoots, a tool for debugging memory leaks in Java applications through analysis of "heap dumps." Examples of analysis include:
- searching/filtering of individual objects
- summary/tabulation of the various types of objects
- statistics on heap address space (such as gaps between objects)
- inward and outward references of an object
- paths between two objects
- exploring the heap from source/root objects by following references
- calculation of objects reachable by an object
- calculation of objects kept alive by an object.
This release "should open all variants of the PHD file format up to and including IBM 1.4.2 SR3."
Oracle has posted the early draft review of JSR-247 Data Mining 2.0 to the JCP. According to the draft,
In JDM 2.0, data mining [Mitchell1997, BL1997] includes the functional areas of classification, regression, attribute importance, clustering, association, feature extraction, time series, and anomaly detection. These are supported by such supervised and unsupervised learning algorithms as decision trees, neural networks, Naive Bayes, Support Vector Machine, K-Means, Apriori, Non-negative Matrix Factorization, and ARIMA.
JDM supports common data mining operations such as model build, test, and apply (score). JDM also supports the creation, persistence, access, and maintenance of metadata supporting mining activities.
Also in JDM 2.0, the standard includes extensions for basic text mining, statistics, and transformations integrated with the mining process. A particular implementation of this specification may not necessarily support all interfaces and services defined by JDM. However, JDM provides a mechanism for discovery of supported interfaces and capabilities.
Comments are due by January 9.
Sun has posted the proposed final draft of Java Specification Request (JSR) 220, Enterprise JavaBeans 3.0 in the Java Community Process (JCP).
The EJB 3.0 release is focused on a simplification of the Enterprise JavaBeans architecture from the developer’s point of view. This simplification has several main aspects:
- Simplification of the interface definition requirements for enterprise beans: elimination of requirements for the specification of home and component interfaces in the EJB 3.0 programming model.
- Simplification of the contractual requirements between the bean provider and the container: elimination of the requirements for enterprise beans to implement the javax.ejb.EnterpriseBean interfaces.
- Simplification of APIs for access to a bean's environment: definition of a dependency injection facility and simpler look-up APIs.
- Introduction of Java metadata annotations to be used as an alternative to deployment descriptors.
- Simplification of object persistence by the definition of a light-weight object/relational mapping facility based on the direct use of Java classes rather than persistent components.
Sun has posted the public review draft of JSR-221 JDBC 4.0 to the Java Community Process (JCP). New features in 4.0 include:
- Automatic loading of
java.sql.Driver - Annotations for JDBC
- ROWID data type
- National Character Set Conversions
- Improved support for BLOBs and CLOBs
- SQL/XML
- Chained, iterable exceptions
Comments are due by January 23.
Sun has posted the early draft review of JSR-231 Java Bindings for OpenGL to the JCP. This describes the Java bindings to a native OpenGL 3D graphics library. Comments are due by January 23.
Sun has also posted the public review draft of JSR-239 Java Bindings for OpenGL ES to the Java Community Process (JCP). According to the draft:
JSR 239 defines an optional package that may be run on a number of Java Micro Edition (Java ME) platforms including CLDC 1.1/MIDP 2.0, CDC 1.0/Personal Basis Profile, and CDC 1.0/Personal Profile, as well as backwards-compatible versions of those platforms.
The OpenGL ES and EGL APIs are defined by the Khronos Group (www.khronos.org). OpenGL ES defines two profiles: the Common profile and the Common-Lite profile. The Common-Lite profile is a 32-bit fixed-point profile, while the Common profile supports floating point. The Common profile is a superset of the Common-Lite profile. This specification provides bindings to the Common profile (including all fixed-point functions). No separate specification addresses only Common-Lite.
JSR 239 requires an underlying native engine that has been certified by Khronos to be conformant with the OpenGL ES and EGL APIs. This engine must support version 1.0 of the OpenGL ES and EGL and all core extensions associated with those APIs. It may optionally support version 1.1 or the OpenGL ES and EGL APIs; if not, certain methods of the bindings will throw a java.lang.UnsupportedOperationException. Bindings are also provided for all currently defined optional profile extensions, including the extensions in the OpenGL ES 1.1 Extension Pack.
Comments on this are due by January 9.
Nokia has submitted JSR-287, Scalable 2D Vector Graphics API 2.0 for J2ME to the Java Community Process (JCP). According to the JSR,
This specification will define an optional package for rendering enhanced 2D vector graphics and rich media content based on select features from SVG Mobile 1.2 for Java ME platform, with primary emphasis on MIDP. This API will be designed as an extension to JSR 226, and therefore must remain to be fully backwards compatible with JSR 226 applications and Scalable Vector Graphics (SVG) rendering model. The primary use cases for this API are interactive maps with rich graphics, scalable user interfaces, rich media services, games, entertainment, and other compelling graphics applications aimed at mobile devices.
The API is targeted at mass market devices that typically have limited processing power and memory. The API shall be defined such that implementations on these target devices are feasible and allow utilization of underlying native SVG implementations of the device.
The scope of the API should include the following:
- Extend Features in JSR 226
- Add the ability to create and modify animations. Not having the ability to create or modify animations makes application development using 226 a bit of a challenge.
- DOM serialization to allow compelling use cases. Note: this should be designed to avoid large performance overhead, and avoid any security issues.
- Support for select SVG Mobile 1.2 features
SVG Mobile 1.2 is the next-generation profile for scalable vector graphics. It brings a substantial set of compelling features such as support for opacity, gradients, advanced text rendering, and embedded multimedia (audio, video). The features to be included from the SVG Mobile 1.2 specification must be carefully chosen not to compromise the important requirements for this JSR such as high performance and low implementation footprint, especially for the low-end mass market devices.
- Support for additional uDOM APIs from SVG Mobile 1.2
Currently JSR 226 supports only a subset of uDOM as defined in SVG Mobile 1.2 specification. The proposed JSR will expand the support of uDOM subset to support new interfaces that are only relevant to the use cases envisaged in this document. It is important to note that during this process of subsetting, any changes or issues that may affect the SVG Mobile 1.2 specification will be coordinated with W3C SVG working group to ensure compatibility between JCP and W3C specifications. For the generic XML DOM API part, the work will be closely coordinated with JSR 280 in order to have a common solution for the XML DOM API.
- Support of Rich Media content Streaming
Rich media content update and streaming is gaining high importance in the mobile domain, especially with new work-items in both OMA and 3GPP standards. Such technology is also important for Java ME platform to allow or offer rich media solutions based on SVG Mobile 1.2 which already specifies mechanisms to embed and display rich media data such as graphics, video, audio and text. At the minimum, this JSR intends to define a scene update syntax and APIs to allow rich media services or applications to dynamically update the content on the client terminal with minimum processing overhead.
- Advanced immediate-mode rendering APIs (compatible with OpenVG)
OpenVG defines a standard 2D graphics for hardware acceleration, particularly for vector graphics content such as SVG, Flash, and GUI. We would like to investigate possibilities of defining such an immediate-mode API that can take advantage of this standard.This work however, needs to be coordinated with other Java ME JSR expert groups to minimize overlaps.
Sun has also posted the maintenance review change log for JSR 185: Java Technology for the Wireless Industry specification. There are only two changes, both focusing on increasing the flexibility of security policies. One is to "Allow the JTWI Security Policy (defined in JTWI Specification, Chapter 7) to be revised and/or superseded in new JCP platform JSRs such as JSR 248." The second is to allow "operators and device manufacturers to override and redefine certain aspects of the JTWI security policy." Comments are due by January 16.
Does anyone know of any published benchmarks about NIO non-blocking I/O compared to traditional blocking I/O? If so, I'd appreciate it if you could send me the relevant citations. So far here's what I've got:
For my own measurements on my own server, I'm also looking for a simple, cheap load testing solution that will let me connect to a server from a few hundred to a few thousand times in parallel. The server itself is quite simple: it sends a continuous stream of data across each connection as fast as it can. There's no real protocol involved. (i.e. this is not HTTP). For testing purposes the client can simply drop all the data on the floor. It's the server's capabilities that interest me. Essentially I'm trying to determine at what point the server keels over and dies under various implementations. Any ideas?
The Eclipse Project has posted the fourth milestone of Eclipse 3.2, an open source integrated development environment (IDE) for Java. It also doubles as a base platform for your own applications, an alternative to the AWT and Swing, and a powerful floor wax and dessert topping. This release adds assorted cool new features. Most importantly you can now link resources from anywhere in the filesystem into a project. (Requiring a particular file system layout has long been a problem in most IDEs.) Other new features include:
- Draggable trimmings
- Filtering in Import, Export, and New wizards
- JFace field assistance
- Dynamic Help content
- Support for secondary types
- Code Completion on labels
- Deleting a package removes empty parent packages.
- Quick fixes for annotations
SWT has also been much improved with
- HSB color support
- StyledText alignment, indentation, justification
- Embedded objects in StyledText
- Background images for controls
- Dragging text
There's quite a bit more. This is really quite an impressive milestone.
The fourth release candidate of Mantis 1.0, a free-as-in-speech (GPL) bug tracking system based on PHP and MySQL, has been posted. This release fixes security and other bugs. All users should upgrade.
I've updated the conferences page. New shows include Eclipse Forum, JAX, and The Server Side. If you know of any other Java-centric conferences I'm missing, please send in their info. In January, I'll be at the XML Developers Network of the Capital District in Albany on the 17th to talk about XOM; and on February 8, I'll be at the Capital District Java Developers Network, also in Albany, to talk about Measuring JUnit Code Coverage. Then in March it's back to Santa Clara for Software Development 2006 West. If you'd like me to talk to your user group, just send me an e-mail. I do ask that groups outside the New York City area cover my travel expenses, though sometimes we can piggy back a user group talk on top of a conference in the same general vicinity. See you there!
Interestingly I've noticed that a lot of the biggest and most interesting Java conferences are now happening in Europe. After JavaOne, the three biggest are Javapolis (Belgium, 2100 people this year), JavaZone (Norway), and JAOO (Denmark). Possibly JavaOne just sucks up all the U.S. developers so other U.S. conferences have to compete to be the second conference a programmer attends. Also interesting: none of those three European conferences are run by professional conference organizations. Javapolis and JavaZone are run by user groups, and JAOO by a consulting firm. Javapolis is also much cheaper than JavaOne or other U.S. conferences of similar size, the strong Euro notwithstanding. (I'm not sure what JAOO and JavaZone cost.) Possibly the relatively small size of Europe helps too. Almost anyone in Europe can get to Belgium/Denmark/Norway more quickly and easily than a New Yorker can reach San Francisco or vice versa.
The RSS feeds may be temporarily broken at various times today while I work on upgrading them. Update: it should all be fixed now. If you notice any remaining problems, please holler.
![[Valid RSS]](images/valid-rss.png "Validate my RSS feed")
Sun's posted an early access release of JavaMail 1.4. JavaMail is a basic library for performing POP, SMTP, and IMAP. I wrote about this in the final chapter of Java Network Programming. According to Sun's Bill Shannon, "This release of the JavaMail API also includes bug fixes and performance improvements." There also appear to be a few minor additions to the API, nothing earth-shattering.
Apple has posted the third beta of Java 5 Release 4 for Mac OS X 10.4 (Tiger) on the Apple Developer Connection (first born child required). This is based on Sun's J2SE 1.5.0_06. It also uses Sun's rendering by default instead of native Quartz graphics. (This will probably change again before final release.) Most importantly it finally makes Java 1.5 the default instead of 1.4. "This release is not compatible with the Intel-based Developer Transition Systems." The second beta caused a lot of problems for people who installed it. This release fixes assorted bugs, but I'd still be very wary of installing it.
The Eclipse Project has released AspectJ 5.0. AspectJ is a derivative of Java that allows programmers to write code that applies across multiple classes. The AspectJ compiler requires Java 1.3 but can generate code for Java 1.1 and later. "This release constitutes a full-upgrade of AspectJ to support Java 5, while also delivering a large number of quality improvements that will benefit users running on JDK 1.4 or below. In addition to the Java 5 related language changes AspectJ 5 also supports an @AspectJ style of aspect declaration, greatly enhanced load-time weaving capabilities, a full reflection API, and tools APIs for parts of the weaver."
The Jakarta Apache Project has released version 3.0 of
HTTPClient, a
full-featured HTTP class library for those times when URL and URLConnection don't cut it.
New features in 3.0 include:
- New preference architecture
- Improved exception handling framework
- Granular non-standards configuration and tracking
- Improved HTTP Version configuration and tracking
- Support for streaming entities
- Support for tunneled HTTP proxies via the ProxyClient
- Ability to abort execution of HTTP methods
- Support for closing idle connections
- Support for JDK1.4 connect timeout through reflection
- Support for connection manager shutdown
- Improved authentication framework
- Plug-in mechanism for authentication modules
- Interactive authentication support
- Alternate authentication support
- Cookie specification plug-in mechanism
- 'Ignore cookies' cookie policy
- Improved Netscape cookie support
- Cross-site redirect support
The Apache Jakarta Commons Project has released Commons Math 1.1, an open source library providing many mathematical functions for statistics, random data generation,
linear algebra, root finding,
interpolation,
erf, gamma and beta functions,
arrays, factorials,
complex numbers, distributions, matrices, and solving linear systems.
1.1 adds some new probability distributions, a Fraction class, new matrix and numerical utilities, and a PRNG pluggability framework to enable the replacement of the JDK random number generator with alternative PRNG implementations.
This release is API compatible with 1.0.
Commons Math is published under the Apache 2.0 license.
The Apache Jakarta Project has released Commons Configuration 1.2, a Java class library that
enables an application to read configuration data from a variety of sources. Commons Configuration provides typed access to single, and multi-valued configuration parameters as demonstrated by the following code:
Double double = config.getDouble("number"); Integer integer = config.getInteger("number");Configuration parameters may be loaded from the following sources:
Different configuration sources can be mixed using a
- Properties files
- XML documents
- Property list files (.plist)
- JNDI
- JDBC Datasource
- System properties
- Applet parameters
- Servlet parameters
ConfigurationFactoryand aCompositeConfiguration. Additional sources of configuration parameters can be created by using custom configuration objects. This customization can be achieved by extendingAbstractConfigurationorAbstractFileConfiguration.
Apple has posted the second beta of Java 5 Release 4 for Mac OS X 10.4 (Tiger) on the Apple Developer Connection (first born child required). This is based on Sun's J2SE 1.5.0_05. This release uses Sun's rendering by default instead of native Quartz graphics. (This will probably change again before final release.) Most importantly it finally makes Java 1.5 the default instead of 1.4. I'd hold off installing this unless one of the bugs Apple thinks they've fixed is affecting you.
Nathan Fiedler has released version 3.4 of JSwat, a graphical, stand-alone Java debugger built on top of the Java Platform Debugger Architecture. Features include breakpoints, source code viewing, single-stepping, watching variables, viewing stack frames, and printing variables. Version 3.4 adds several small features and fixes bugs. JSwat is now published under the Sun Public License. (It was previously published under the GPL.)
IBM has released Version 1.0.1 of their Java USB API implementation for Linux. This is published under the Common Public License.
The Jakarta Apache Project has released version 1.2.13 of Log4j, a vastly overused logging toolkit for Java. Not that it's a bad product or toolkit. It's just that the majority of projects that bundle Log4j this could use much simpler, homegrown solutions and avoid yet another large, complicated dependency. "Log4j version 1.2.13 contains several bug fixes related to the TRACE level introduced in version 1.2.12 and a fix in the ConsoleAppender for a bug that affected JBoss."
The Big Faceless Organization has released the Big Faceless PDF Library 2.6.5, a $700 payware (more if you want support) Java class library for creating PDF documents. The $1300 Extended Edition adds the AcroForms support, digital signatures, and the ability to import and edit and existing PDF documents. Version 2.6.5 improves performance and fixes bugs.
The Apache Software Foundation has released Maven 2.0.1, an open source build tool for Java that's more declarative and less procedural than Ant. 2.0.1 is primarily a maintenance release. There've been a lot of problems reported with Maven 2 so far, including one apparently affecting XOM and Jaxen I don't yet fully understand. I'd stay with Maven 1.0 for now until all the kinks get worked out.
I've posted the notes from my XOM Design Principles and Effective XML talks at Javapolis. The former focuses more on general principles of Java API design and less on the details of using XOM.
Werner Randelshofer has released version 3.5 of Quaqua Look and Feel, "an extension for Apple's implementation of the Aqua Look for Swing. Quaqua aims at fixing inconsistencies between user interface elements implemented in Swing and those of native Mac OS X applications. To achieve this, Quaqua selectively replaces UI elements of Apples Aqua Look And Feel with elements of its own." This release improves the fidelity of FileChooserUI, adds a new SplitPaneUI with "plain" style and "bar" style, and adds slide-in/slide-out transition effects for JSheet components. If you're serious about making your application work look native on the mac you need to check this out, especially the FileChooser. The default Swing file choosers don't work anything like a standard Mac file chooser, and many applications that appear native at first glance shatter that illusion as soon as the user tries to open or save a file. Quaqua is dual licensed under the BSD license model and the LGPL. Java 1.3 or later and Mac OS X 10.2 or later are required.
Etienne Gagnon has released version 1.13 of SableVM, a Java bytecode interpreter (that is, a virtual machine) written in C. "SableVM requires an ANSI/ISO C compiler (but preferably GCC) and a POSIX platform. It requires a strong memory model (sequential consistency) on multiprocessor systems." SableVM is available for GNU/Linux, Solaris, and FreeBSD. This is essentially a bug fix release. SableVM is published under the GNU Lesser General Public License (LGPL).
I spent today at the first Weekend with Experts conference in Pennsylvania. I've posted the notes from my presentation on Test Driven Development with Eclipse.
Tomorrow I leave for Antwerp and Javapolis, so updates here will be infrequent until I return next week.
The Omni Group has released
OmniGraffle 4.1,
a general purpose Mac OS X diagramming tool and my
UML editor of choice. 4.1 is a bug fix release.
OmniGraffle ranges from $79.95 to $149.95.
Mark Doliner has released Cobertura 1.7, a free-as-in-speech (GPL) code coverage tool for Java. Version 1.7 adds support for AspectJ and fixes numerous significant bugs. If you're not already using another code coverage tool, this is definitely worth a look. Java 1.4 or later is required.
Websina has released BugZero 4.2.2, a $1299 payware (+$300 for maintenance) Web-based bug tracking system that supports multiple projects, group-based access, automatic bug assignment, file attachment, email notification, and metric reports. Bug Zero is written in Java and can run on top of various backend databases including MySQL. 4.2.2 adds assorted minor features and bug fixes.
The discussion of humane interfaces continues in various and sundry places. I suspect there's more middle ground between Fowler and me than perhaps some people realize. His essential point is "The essence of the humane interface is to find out what people want to do and design the interface so that it's really easy to do the common case." I don't disagree with the principle. However we part ways on the practical application of that theory to class design. In particular I believe:
- The common cases don't all have to be handled in a single class. It's OK to divide some functionality into new classes.
- One must not forget the corresponding principle that one should not design for the uncommon cases. Too often programmers forget the "common" part of the principle and end up with classes that try to be all things to all people.
- The Ruby
Arrayclass is a really bad example of this principle because it goes way beyond the common cases.
There's been some push back on the specific case of the first() and last() methods Fowler cites. Some people like them.
I didn't understand why since I almost never use any such method. However, several people noted that these are useful for queues and stacks; but if you're using a queue or a stack, shouldn't you use a Queue or Stack class rather a List class? (Yes, I know Java's Stack class is an abomination. No, that doesn't affect my basic point.) But let's grant the first() and last() methods for moment, and look at what else you'll find in Ruby's 78 method Array class.
Array.new(size=0, obj=nil)This method creates an array that has
sizecopies of the object. Why? Have you ever needed to create an array/list that begins its life containing more than one copy of the same object? I don't think I have. I can imagine a few uses cases, especially if Ruby doesn't distinguish primitive types from objects like Java does; but I don't think they're nearly common enough to justify explicit support in the API. On the rare occasions when you need this, there's afillmethod you can call after constructing the list.array * int -> an_array"Returns a new array built by concatenating the int copies of self." I've thought and I've thought, and I still can't figure out when you might need this.
-
array <=> other_array -1, 0, +1 A comparison between arrays. However, without me stating it here, can you understand how to tell whether two arrays are greater than, equal to, or less than each other? There's more than one possibility here. This needs to be pulled out into a separate interface that allows for different comparison algorithms. Plus how often do you need to compare lists for anything but equality anyway? Even that's uncommon. I'll leave it as an exercise for the reader to read the documentation for this method and find the underspecification. It is possible for implementation A to conclude that array
foois less than arraybarand implementation B to conclude the exact opposite. These things happen when classes get so big that even the programmers who write the specs don't have time to fully understand them.-
abbrev(pattern = nil) "Calculates the set of unambiguous abbreviations for the strings in self." Excuse me. What?! This one's totally out of left field. Does it even make sense if the list contains anything other than strings? If someone needs this, it should be in a separate class. The list class cannot hold every operation anyone might ever want do to a list. If we try that, why not a method to capitalize all the strings in the list? Or spell check them? Or translate the entire list into Swahili? The list of things you might want to do is endless, but the list class shouldn't be.
-
array.compact! -> array or nil "Removes nil elements from array. Returns nil if no changes were made." Compacting a list seems useful if a little uncommon. But compacting an array and sometimes returning nil? Does anyone ever use this? There's also a perfectly good method to compact an array and return it, without ever returning nil. That's a lot more useful. I only care whether the list now contains any nil objects or not, not whether it once contained nil objects.
-
array.each_index {|index| block } -> array "Same as Array#each, but passes the index of the element instead of the element itself." Am I missing something, or is this just a
forloop across the array indexes? Why not just use aforloop, or whatever Ruby's equivalent is?array.at(index) -> obj or nilAs near as I can figure, this is exactly the same as using array brackets except it uses a method call. If there is a difference, it's pretty subtle. DRY, anyone?
array.fetch(index) -> objThis one is mostly the same as array brackets, but there is one difference. It will throw an IndexErr rather than returning nil if you go outside the range. But will anyone remember that difference and which does which when reading code? Sometimes when presented with different possible options, it's best just to pick one. Don't provide every possible option in an API.
-
array.nitems -> int "Returns the number of non-nil elements in self. May be zero." Another one it never even occurred to me I might need. I suspect this one's beyond the 90/10 point. heck. It's beyond the 99/1 point.
-
arr.pack ( aTemplateString ) -> aBinaryString I'm not even going to try to explain this one. This method alone is easily complex enough to justify several separate classes. What it's doing here I have no idea.
-
array.popandarray.push(obj, ... ) Someone pushed a stack into the list. Didn't we learn from that mistake in Java? (OK.
pushis really just append, but still,pop? And if you havepopwhy do you needlast? Does anyone here remember DRY?)array.rassoc(key)Is it a list? Is it a stack? Is it a map? It's three, three, three data strcutures in one!
-
array.shiftandarray.unshift(obj, ...) Now the list has turned into a queue!
-
array.transpose --> an_array And now it's a matrix! What's next? a B-tree?
-
array.reverse and array.reverse! Have you ever needed to reverse a list outside of a job interview? Iterate through the list in reverse order, yes; reverse the list, no.
-
size() Exactly the same as
length(). This class is looking pretty WET.-
array.to_a -> array "Returns self. If called on a subclass of Array, converts the receiver to an Array object." Is Ruby not object oriented? Is there some deep, dark reason we can't just use an instance of the subclass as an instance of the superclass?
array.zip(arg, ...)I don't want to pick on programmers who are not native English speakers, and Lord knows Java's API documentation is not a model of good English; but perhaps if this class weren't so damn large, someone who is a native English speaker might have read to the end of this page once or twice and noticed the multiple typos in the description of this method? (I don't think it's a coincidence that the grammar gets worse the closer to the end of the page you get.)
Do you really need any of this getting in your way? Possibly you need one or two of these methods; but how often, and how many? These methods are all way beyond the 80/20 point. I promised today I was going to show you all the methods you could take out of the Array class and still have a humane, indeed a more humane interface. I'm afraid I haven't fulfilled my promise. I got tired before I got halfway through the class and started skipping some cases. Try reading the entire documentation yourself from start to finish, and you'll see what I mean. It's just too damn big. A smaller, simpler API would be more humane.
The Gnu Project has released version 3.4.5 of GCC,
the GNU Compiler Collection.
GCC contains front ends for C, C++, Objective C, Chill, Fortran, Ada, and Java as well as libraries for these languages.
GCC is a clean room implementation of Java that doesn't use any Sun code,
so it doesn't always exactly match Sun release versions, but this is roughly at the Java 1.4 level with some omissions. 3.4.5 is a bug fix release.
Yesterday's response to Martin Fowler touched a few nerves, but I'm holding my ground.
Java's List class is demonstrably superior
to Ruby's Array class, and the difference has nothing to do with the difference between the languages. There's no syntax-based reason Java's class couldn't have the extra
methods Ruby's does or Ruby's couldn't eliminate the extra methods it does have. The difference is between the classes, not the languages in which they're written. To explain, let me borrow an example from Steve Jobs. Which of these three remotes would you rather use?
More buttons/methods does not make an object more powerful or more humane, quite the opposite in fact. Simplicity is a virtue. Smaller is better. Do you want to go all the way down to the absolute theoretical minimum? For a list class that's probably about four public methods (new, insert, delete, get). Probably not. That's too few, but 78 is way too many. 10-12 is ideal purely from human-interface concerns. (I'd say 7-8 except I don't think most classes can really get that small. Maybe it is 7-8 if we count all overloaded variants as a single method though.) 25-30 is sort of the outside maximum: roughly the most signatures you can fit on a single piece of paper so that the programmer can see the whole class at once without scrolling their eyes.
If that still doesn't convince you, tomorrow I'll take another look at the Array class that started this whole brouhaha and show exactly how pointless most of those 78 methods really are.
The Jakarta Apache Project has released version 5.5.14 of the Tomcat open source servlet container and official reference implementation of the Java Servlet API 2.4 and Java Server Pages (JSP) 2.0. This release "is an update of the APR optional dependency to version 1.1.1, and related configuration changes for the APR connector and installer. There are a few additional bugs fixed, as detailed in the change log." "Tomcat 5.5 is designed to run on J2SE 5.0 and later, and requires configuration to run on J2SE 1.4....In addition, Tomcat 5.5 uses the Eclipse JDT Java compiler for compiling JSP pages. This means you no longer need to have the complete Java Development Kit (JDK) to run Tomcat, but a Java Runtime Environment (JRE) is sufficient. The Eclipse JDT Java compiler is bundled with the binary Tomcat distributions. Tomcat can also be configured to use the compiler from the JDK to compile JSPs, or any other Java compiler supported by Apache Ant."
Martin Fowler's a really smart guy, and he's pretty reliably right; but
today he manages to get it 180° wrong. A 78 method List class is about three times as bad as a 25 method List class, not three times as good. A 12 method List class would be about twice as good.
Simplicity is a virtue for both users and implementers.
There's simply no reason for 78 methods in a basic List class.
In fact, there's no reason for 78 public methods in any class.
78 public methods in one class is a code smell.
78 public methods make a
class hard to learn, hard to use, hard to test, and hard to maintain.
When a
class has 78 public methods, it's time to refactor.
For instance, the Ruby List class (actually called Array but it's a list) Fowler's so fond of has a method to return the number of non-null items in the list. Now have you ever needed to do that? I haven't. Doubtless someone somewhere has occasionally needed this functionality; but one shouldn't put anything in a class just because one person needs it once a year.
It's not as if figuring out the number of non-null items in a Java list is particularly hard to do in the unlikely even you need to know that.
Another example:
Fowler likes the first and last methods in Ruby, but list.first() is not significantly simpler than list.get(0). list.last() is perhaps a little simpler than list.get(list.size() - 1) but only because Java stupidly indexes everything from 0 rather than 1. And how often do you actually need to get the first item in the list?
Needing the last item in a list is even less common.
Normally the reason we have a list in the first place is so we can
iterate through it using an Iterator or foreach.
More often than not
no single element—first, last, or middle—is explicitly identified in the code.
Java's List class does not lack any of the functionality in Ruby's. Java just factors it out into a few more classes, especially the Collections class, and skips a couple of rarely used "convenience" methods. The result is a simpler, easier-to-understand, easier-to-use, more humane API.
The Eclipse Project has released version 4.1 of the Test and Performance Tools Platform. New features in this release include suypport for TPTP-based performance tools for applications in C/C++ and other compiled languages, Web application testing, and simplified data collection on the local system with no need for a separate agent controller.
The Jakarta Apache Project has released version 5.5.13 of the Tomcat open source servlet container and official reference implementation of the Java Servlet API 2.4 and Java Server Pages (JSP) 2.0. This release is considered to be a beta that "contains several important bug fixes, minor feature additions, and documentation enhancements." "Tomcat 5.5 is designed to run on J2SE 5.0 and later, and requires configuration to run on J2SE 1.4....In addition, Tomcat 5.5 uses the Eclipse JDT Java compiler for compiling JSP pages. This means you no longer need to have the complete Java Development Kit (JDK) to run Tomcat, but a Java Runtime Environment (JRE) is sufficient. The Eclipse JDT Java compiler is bundled with the binary Tomcat distributions. Tomcat can also be configured to use the compiler from the JDK to compile JSPs, or any other Java compiler supported by Apache Ant."
Object Refinery Ltd has released JFreeChart 1.0.0, a free (LGPL) chart library for Java.
The Blackdown Project has released their version of the Java 2 Standard Edition for Linux 1.4.2-03. This includes a software development kit, runtime environment, and Java plug-in for Linux on x86 and Sparc. It's based on Sun's source code for JDK 1.4.2_10. It is not open source. This release plugs a security hole and fixes some significant bugs. All users should upgrade.
The Apache Jakarta Commons Team has released Commons Net 1.4.1 (formerly known as ORO NetComponents), an open source (Apache license) suite of internet protocols implemented in Java including Finger, Whois, TFTP, Telnet, POP3, FTP, NNTP, SMTP, discard, rexec, rcmd, rlogin, Time, Echo, NTP, and SNTP. 1.4.1 restores compatibility with pre-1.4 VMs.
Sun has posted the sixth update release for Java 5.0 Tiger with dozens of assorted bug fixes. Most notably this release "introduces various security enhancements in Java Plug-in and Java Web Start to better protect users and enterprises." As usual it's available for Solaris, Windows, and Linux.
Tom Copeland has released PMD 3.4, an open source tool for automatically checking Java code for various classes of bugs. Version 3.4 adds thirteen new rules including:
- ClassCastExceptionWithToArray
- AvoidDecimalLiteralsInBigDecimalConstructor
- NonThreadSafeSingleton
- UncommentedEmptyMethod
- UncommentedEmptyConstructor
- DefaultPackage
- UseStringBufferLength
- MisleadingVariableName
- ReplaceVectorWithList
- ReplaceHashtableWithMap
- ReplaceEnumerationWithIterator
- AvoidEnumAsIdentifierTest
- AvoidAssertAsIdentifier
The last five come from a new migration ruleset for helping to migrate from one Java version to another. This release also adds a "lint comment" facility for suppressing warning with annotations.
I tested this release out on XOM. This time it didn't locate any real bugs. There were some design points it flagged one might want to address, but I'm not sure. (Is it really helpful to declare private fields final? That always feels redundant to me.) PMD found a couple of really minor issues I chose to address to improve code clarity; but that's about it. I've definitely hit the point of diminishing returns with these sorts of tools.
David Hovemeyer and Bill Pugh have posted FindBugs 0.9.4, an automated open source tool for finding potential bugs in Java code. This is mostly a bug fix release.
I also tested this out on XOM. Almost all the bugs it found were false positives, though it did finally inspire me to fix one minor issue of string concatenations inside loops. FindBugs also worked its way back from XOM into Jaxen where it found some unreachable code I could eliminate. If I hadn't used this tool frequently in the past, it would have found more.
I'm pleased to announce the release of
XOM 1.1, my free-as-in-speech (LGPL)
dual streaming/tree-based API for processing XML with Java.
Version 1.1 maintains backwards compatibility with XOM 1.0 while adding a number of important new features including XPath queries, document subset canonicalization, exclusive XML canonicalization,
external XSLT parameters, and xml:id support. It also fixes a number of bugs that were present in XOM 1.0, uses less memory,
and is two to four times faster for many common operations.
The addition of XPath is especially significant. It removes the last remaining reason you might plausibly choose JDOM or dom4j instead of XOM. Going forward I think you'll find that XOM is more robust, faster, smaller, better documented, and much, much easier to use than the alternatives. While there's a lot of working legacy code out there using JDOM or dom4j that no one's going to throw away, new projects should seriously consider XOM. In my not so humble opinion, it is demonstrably the best library of its type. There are still use cases for which one would choose a pure streaming API such as SAX, StAX, or XNI instead. However if you want an XML tree model in Java, XOM is the obvious choice.