The Eclipse Project has posted the seventh milestone release of Eclipse 3.4 Ganymede, their open integrated development environment for Java. This milestone can now use multiple CPUs/cores to compile in parallel.
Google has posted the first release candidate of GWT 1.5, an open source Java-to-JavaScript compiler and library for building AJAX applications in Java. The major new feature in this release is support for Java 5, including generics, enums, annotations, and the enhanced for loop.
Mort Bay Consulting has released Jetty 6.1.10, an open source servlet engine that supports version 2.5 of the Java Servlet API and version 2.1 of Java Server Pages, and my personal favorite embeddable web server. This is a bug fix release.
Teodor Danciu has released JasperReports 3.0.0, an open source (LGPL) Java library for generating reports from XML templates and customizable data sources (including JDBC). The output can be displayed on the screen, printed, or written to XML or PDF files. Version 3.0 adds custom properties at element level in generated documents, having static or dynamic values and fixes some bugs.
Rich Hickey has released Clojure, a Lisp dialect that runs on top of the Java virtual machine:
Clojure is a compiled language - it compiles directly to JVM bytecode, yet remains completely dynamic. Every feature supported by Clojure is supported at runtime. Clojure provides easy access to the Java frameworks, with optional type hints and type inference, to ensure that calls to Java can avoid reflection.
Clojure is a dialect of Lisp, and shares with Lisp the code-as-data philosophy and a powerful macro system. Clojure is predominantly a functional programming language, and features a rich set of immutable, persistent data structures. When mutable state is needed, Clojure offers a software transactional memory system and reactive Agent system that ensure clean, correct, multithreaded designs.
Clojure is published under the Common Public License 1.0.
Karmasphere Labs has released jcpp 1.2.1, a free-as-in-speech (GPL) pure Java implementation of the C preprocessor. Java 5 or later is required.
Sun has posted the early draft review of JSR-292, Supporting Dynamically Typed Languages on the Java™ Platform, to the Java Community Process. According to the JSR,
This design introduces an
invokedynamicinstruction. Syntactically, it is a variation of theinvokeinterfaceinstruction. It carries a symbolic method name and just enough type information to accurately type the arguments on the JVM stack. It makes no requirements on its receiver argument, except that it be a non-null object reference. The machine-level semantics of this instruction are minimized, in that they defer as many decisions as possible to up-calls implemented in ordinary bytecodes.In particular, the process of linking an
invokedynamicinstruction is completely defined by software, above the level of the JVM. Linking possibly includes decisions which take receiver or argument types into account, before deciding the outcome of an invocation. These decisions can possibly depend on changing method definitions and argument types, which means that linking is an ongoing process.The linkage state of an
invokedynamicinstruction is an object called a target method (represented as a method handle, as defined below); it can also be the null reference. This linkage state starts out null and can be updated by the application.Every call to an
invokedynamicinstruction directly invokes the call site&rquo;s target method, if it is not null. This target method can (in principle) be any method whose incoming argument types match the outgoing argument types from theinvokedynamicinstruction, and whose return type likewise matches the invocation. The method can be static or non-static (virtual or final), and can (in principle) be defined in any class. The dynamic language runtime can easily wrap adapter code around target methods to create new target methods to manage argument type mismatches and meet other requirements.The first time an
invokedynamicinstruction is run, or whenever the target method is null, the JVM makes an up-call to a compiler-supplied routine called the bootstrap method. The bootstrap method receives the arguments to the call site. The arguments are boxed, varargs style, into an object array.The bootstrap method also receives a reference to a
CallSiteobject which reifies the particularinvokedynamicinstruction. TheCallSiteobject reports static information about the call, including the method name and descriptor. It also provides a method for updating the target method of the call site. Because this object reference is specific to the call site but not to the current call, the dynamic language can save it away, or it can use it once and discard it.The bootstrap method must execute the call directly. Optionally, it may install a target method for the call site to use next time. Whenever a non-null target method is installed, the application has (in effect) dynamically linked the call site to the desired target method.
The target method (or if there is none, the bootstrap method) is responsible for fulfilling the language-specific semantics of the call site. If the compiler of the call site requires dynamic typing, it must install any type specific target method (or methods) in a suitable adapter which will check argument types, maintain appropriate type history (if needed), invoke the type specific method, and perform relinking or error processing if an unexpected type is seen.
Here is a pseudo-code example, of the logic for dynamically invoking the name
alphaon an untyped receiver, with two additional arguments (untyped reference and 32-bit integer):// Running example of invokedynamic call site class MyCaller { private static final CallSite site1 = (...); private static final MethodHandle bootstrapMethod = (...); Object myMethod(Object x, Object y, int z) { // x . invokedynamic["alpha",(Object,int)Object] (y, z) MethodHandle method1 = site1.target; if (method1 == null) return bootstrapMethod.invoke(site1, x, y, z); return method1.invoke(x, y, z); } }A key feature of this design is that it does not distinguish between linking and execution phases of a call site. Linking (i.e., introduction of new target methods) is expected to be rare, but any method call has the potential to lead to further linking or unlinking activity, if the original call to the bootstrap method preserves the call site’s static context. This is appropriate to dynamically typed languages, since dynamic call linkage is always provisional.
Another key feature is that arbitrary methods can be target methods, and method calling sequences are the same as with the other call instructions (like
invokevirtual), etc. This makes it easy for dynamic languages to link to static languages (like Java), and allows JVM optimizations (such as inlining) on standard invocation instructions to apply to the new instruction also. There is no need to package code in a particular type hierarchy (e.g., =java.util.concurrent.Callable=), or in a limited range of argument types (as with =java.lang.reflect.Method=). Put another way, this design is polymorphic across all method descriptors, and interoperates with method everywhere. This polymorphism is reflected in the API for method handles, which, though not completely orthogonal to the Java type system, strike a new angle relative to it.This specification defines a number of details:
- the format of the
invokedynamicinstruction- the API for the up-call to the bootstrap method
- the installation and removal of target methods
- the rules for conforming call-site descriptors (type signatures) to the target method
- the API for managing linkage state across multiple call sites
- the API for creating and managing method handles
Other important questions deserve detailed treatment elsewhere, but cannot be specified here:
- the processing performed by the bootstrapping up-call
- the use of this instruction by any particular language
- any type-specific dispatching or conversion performed by the target method
- any call site state (such as inline caches) encapsulated in the target method
- the JIT optimizations enabled by this instruction
- heuristics or algorithms for managing the target method
Extra-special kudos to the working groups for publishing the draft in HTML instead of PDF, even if they still make you click through an annoying, pointless license agreement and download a zip file to read it.
I am pleased to announce that my latest book,
Refactoring HTML has been released by Addison Wesley. This book endeavors to improve the design of existing web sites along multiple axes: maintainability, security, attractiveness, and performance.
It does this by moving sites to web standards: XHTML, CSS, and REST.
Rather than approaching this as a big bang project, small changes can be made in small steps that offer linear improvement. You don't need to spend months of developer time and thousands of dollars before you see any payback. You can improve your site some today, and then some more tomorrow. Refactoring a web site doesn't require large blocks of uninterrupted development time. Add up enough small changes in the little pieces of time scattered throughout the workday, and before you know it, your site is dramatically improved.
Not convinced yet? Let me offer a brief excerpt from Chapter 1:
Refactoring. What is it? Why do it?
In brief, refactoring is the gradual improvement of a code base by making small changes that don’t modify a program’s behavior, usually with the help of some kind of automated tool. The goal of refactoring is to remove the accumulated cruft of years of legacy code and produce cleaner code that is easier to maintain, easier to debug, and easier to add new features to.
Technically, refactoring never actually fixes a bug or adds a feature. However, in practice, when refactoring I almost always uncover bugs that need to be fixed and spot opportunities for new features. Often, refactoring changes difficult problems into tractable and even easy ones. Reorganizing code is the first step in improving it.
The concept of refactoring originally came from the object-oriented programming community, and dates back at least as far as 1990 (William F. Opdyke and Ralph E. Johnson, “Refactoring: An Aid in Designing Application Frameworks and Evolving Object-Oriented Systems,” Proceedings of the Symposium on Object-Oriented Programming Emphasizing Practical Applications [SOOPPA], September 1990, ACM), though likely it was in at least limited use before then. However, the term was popularized by Martin Fowler in 1999 in his book Refactoring (Addison-Wesley, 1999). Since then, numerous IDEs and other tools such as Eclipse, IntelliJ IDEA, and C# Refactory have implemented many of his catalogs of refactorings for languages such as Java and C#, as well as inventing many new ones.
However, it’s not just object-oriented code and object-oriented languages that develop cruft and need to be refactored. In fact, it’s not just programming languages at all. Almost any sufficiently complex system that is developed and maintained over time can benefit from refactoring. The reason is twofold.
Increased knowledge of both the system and the problem domain often reveals details that weren’t apparent to the initial designers. No one ever gets everything right in the first release. You have to see a system in production for a while before some of the problems become apparent.
2. Over time, functionality increases and new code is written to support this functionality. Even if the original system solved its problem perfectly, the new code written to support new features doesn’t mesh perfectly with the old code. Eventually, you reach a point where the old code base simply cannot support the weight of all the new features you want to add.
When you find yourself with a system that is no longer able to support further developments, you have two choices: You can throw it out and build a new system from scratch, or you can shore up the foundations. In practice, we rarely have the time or budget to create a completely new system just to replace something that already works. It is much more cost-effective to add the struts and supports that the existing system needs before further work. If we can slip these supports in gradually, one at a time, rather than as a big-bang integration, so much the better.
Many sufficiently complex systems with large chunks of code are not object-oriented languages and perhaps are not even programming languages at all. For instance, Scott Ambler and Pramod Sadalage demonstrated how to refactor the SQL databases that support many large applications in Refactoring Databases (Addison-Wesley, 2006). However, while the back end of a large networked application is often a relational database, the front end is a web site. Thin client GUIs delivered in Firefox or Internet Explorer are everywhere, replacing thick client GUIs for all sorts of business applications, such as payroll and lead tracking. Adventurous users at companies such as Sun and Google are going even further and replacing classic desktop applications like word processors and spreadsheets with web apps built out of HTML, CSS, and JavaScript. Finally, the Web and the ubiquity of the web browser have enabled completely new kinds of applications that never existed before, such as eBay, Netflix, PayPal, Google Reader, and Google Maps.
HTML made these applications possible, and it made them faster to develop, but it didn’t make them easy. It didn’t make them simple. It certainly didn’t make them less fundamentally complex. Some of these systems are now on their second, third, or fourth generation; and wouldn’t you know it? Just like any other sufficiently complex, sufficiently long-lived application, these web apps are developing cruft. The new pieces aren’t merging perfectly with the old pieces. Systems are slowing down because the whole structure is just too ungainly. Security is being breached when hackers slip in through the cracks where the new parts meet the old parts. Once again, the choice comes down to throwing out the original application and starting over, or fixing the foundations; but really, there’s no choice. In today’s fast-moving world, nobody can afford to wait for a completely new replacement. The only realistic option is to refactor.
Most of the refactorings in this book focus on upgrading sites to web standards, specifically:
- XHTML
- CSS
- REST
They are going to help you move away from
- Tag soup
- Presentation-based markup
- Stateful applications
These are not binary choices, or all-or-nothing decisions. You can often improve the characteristics of your sites along these three axes without going all the way to one extreme. An important characteristic of refactoring is that it’s linear. Small changes generate small improvements. You do not need to do everything at once. You can implement well-formed XHTML before you implement valid XHTML. You can implement valid XHTML before you move to CSS. You can have a fully valid CSS-laid-out site before you consider what’s required to eliminate sessions and session cookies.
Nor do you have to implement these changes in this order. You can pick and choose the refactorings from the catalog that bring the most benefit to your applications. You may not require XHTML, but you may desperately need CSS. You may want to move your application architecture to REST for increased performance but not care much about converting the documents to XHTML. Ultimately, the decision rests with you. This book presents the choices and options so that you can weigh the costs and benefits for yourself.
It is certainly possible to build web applications using tag-soup table-based layout, image maps, and cookies. However, it’s not possible to scale those applications, at least not without a disproportionate investment in time and resources that most of us can’t afford. Growth both horizontally (more users) and vertically (more features) requires a stronger foundation. This is what XHTML, CSS, and REST provide.
Refactoring HTML is available now at Amazon, Safari, and other fine bookstores everywhere. The price is a very reasonable $39.99, and most stores are offering their customary discounts. (Amazon is 10% off at the moment.) I hope you enjoy it.
Barcode4J 2.0, an open source (Apache license) barcode generation library, has been released Supported barcode formats include Interleaved 2 of 5, Code 39, Codabar, Code 128, UPC-A and UPC-E (with supplementals), EAN-13 and EAN-8 (with supplementals), EAN-128, POSTNET, Royal Mail Customer Barcode, PDF417, and DataMatrix. Output formats include SVG, EPS, PNG, JPEG), and Java2D.
I missed JavaOne this year, but from what I'm reading it doesn't sound like I missed all that much. No Java 7. JavaFX still being pitched as the next big thing. Threads are important. Closures good! Closures bad! Blah. Blah. Blah. Sounds like a repeat of last year's show. Did anything new happen? Maybe Java has grown too large to change significantly in just one year. Should JavaOne be biennial? Or maybe we should just attend every other year. Here's a thought: how about moving Javaone to the East Coast or Europe every other year so even if it's the same story, different people will attend?
Nokia and Vodafone have posted the early draft review of JSR-249 Mobile Service Architecture 2 :
The Java ME community has developed a unified Java application environment standard for mobile phones as part of the JSR 248 Mobile Service Architecture (MSA) specification. Mobile Service Architecture 2 (MSA2) Initiative continues the work by providing an updated platform specification needed by the mobile industry today. MSA2 Specification (JSR 249) addresses an even broader set of devices than MSA with more enhanced and diverse capabilities but continues its focus on high-volume mobile devices. This JSR broadens the architecture defined by MSA by adding support for new technologies and features that are already available or will become available in the foreseeable future. It also oversees compatibility with the JSR 248 MSA environment.
The MSA2 Specification is a Java architecture definition that describes the essential Java client components of an end-to-end wireless environment. The MSA2 Specification defines a set of Java ME technologies and shows how these technologies must be be correctly integrated in a mobile device to create an optimal mobile Java platform. As a normative specification, the MSA2 Specification produces compatibility requirements that are reflected in the MSA2 TCK. Service and content providers can use the MSA2 Specification as a guideline for application development and can benefit from better application portability between different MSA2 compliant implementations.
Comments are due by May 29.
Sun has posted the early draft review of JSR-317 Java Persistence API. "This draft addresses improvements in the areas of domain modeling, O/R mapping, and EntityManager and Query runtime APIs. " Comments are due by June 1.
Bill Pugh of the University of Maryland has released FindBugs 1.3.4, an automated open source tool for finding potential bugs in Java code. New bug detectors in this release include:
- EQ_OVERRIDING_EQUALS_NOT_SYMMETRIC: equals method overrides equals in superclass and may not be symmetric
- EQ_ALWAYS_TRUE: equals method always returns true
- EQ_ALWAYS_FALSE: equals method always returns false
- EQ_COMPARING_CLASS_NAMES: equals method compares class names rather than class objects
- EQ_UNUSUAL: Unusual equals method
- EQ_GETCLASS_AND_CLASS_CONSTANT: equals method fails for subtypes
- SE_READ_RESOLVE_IS_STATIC: The readResolve method must not be declared as a static method.
- SE_PRIVATE_READ_RESOLVE_NOT_INHERITED: private readResolve method not inherited by subclasses
- MSF_MUTABLE_SERVLET_FIELD: Mutable servlet field
- XSS_REQUEST_PARAMETER_TO_SEND_ERROR: Servlet reflected cross site scripting vulnerability
- SKIPPED_CLASS_TOO_BIG: Class too big for analysis
Sun has posted a public review draft of JSR 311 JAX-RS: The Java API for RESTful Web Services 1.0. This amounts to a moderately complex API for server side HTTP. There's some good stuff here, including support for URI templates, and the use of annotations to associate methods with paths. I still suspect it's more complex than it needs to be; and I'm not sure if Java code is really the right place to be mapping handlers to paths. The again maybe it is appropriate for some HTTP servers, even if not all of them. Comments are due by May 22.
Google has posted the second milestone of GWT 1.5, an open source Java-to-JavaScript compiler and library for building AJAX applications in Java. The major new feature in version 1.5 is support for Java 5, including generics, enums, annotations, and the enhanced for loop. According to Bruce Johnson, new features in this milestone include:
- There is a new DOM API package. Using the new ability to subclass JavaScriptObject, GWT 1.5 M2 includes bindings for nearly the entire W3C HTML DOM spec. See the javadoc for the package com.google.gwt.dom.client for details. The widgets will be retrofitted to use the new DOM classes in the upcoming release candidate.
- Some widgets now have animation effects. Popups, trees, etc. have subtle animation effects to provide visual cues when hidden and shown.
- The addition of a "Showcase" sample. This sample combines features from several other samples and demonstrates the new, nicer-looking GWT default stylesheet and widget animations. Note that the default style is still in flux and is likely to change.
- Keyboard support has been added where previously absent in UI classes, including in menus and tab panels.
- ARIA support for enhanced accessibility is now present in most widgets, including menus, trees, tabs, and button variants.
- Bi-di. Widgets and panels have built-in support for bi-directional layout.
- "long" emulation. The Java language defines "long" types to be 64-bit signed integers, whereas JavaScript only supports 64-bit floating point numbers, which cannot accurately represent the same whole-number range as a true "long" type. GWT 1.5 M2 transparently emulates long types properly to more faithfully maintain Java semantics in web mode.
- There is a single Mac OS X distribution that works on both Leopard (10.5) and Tiger (10.4).
Sun announced financial results for the third quarter of their fiscal year that ended in March, and they weren't pretty. Sun lost $34 million, 4 cents per share. Total revenue was $3.266 billion, down down half a percentage point from the same quarter last year. Gross margins grew to 44.9%. Plans were announced to lay off another 2500 or so people.