Apple has released Java for Mac OS X 10.5 Update 2 which supports Java 1.6.0_07, Java 1.5.0_16, and Java 1.4.2_18. They have also released Java for Mac OS X 10.4 Release 7 that supports Java 1.5.0_16, and Java 1.4.2_18. Several security vulnerabilities are closed in these releases.
David Gilbert has released JFreeChart 1.0.11. "This release features a new chart theming mechanism plus various other enhancements." JFreeChart is free software under the terms of the GNU Lesser General Public Licence (LGPL), and requires Java version 1.3.1 or later.
Google has released the Android Software Development Kit 1.0. This is an open source Java environment for writing programs that run on the Android platform mobile phones such as the recently announced T-Mobile G-1. Unlike IPhone apps, you don't need Google's or T-Mobile's or anyone else's permission to install software, and you can run apps in the background. Android is a far more powerful development platform than the IPhone, and I'm very psyched about it. The initial hardware isn't quite as well-designed as the IPhone, but one of the advantages of Android is that there'll be more than one manufacturer so we'll have a much wider choice of phones. More seriously the user interaction model isn't as clean as the IPhone's. Hopefully that will improve with time.
But the kicker is the open software development environment vs. Apple's walled garden. You'd think Mac v. Windows would have taught Apple the importance of opening up the world to developers if they wanted a platform to achieve broad adoption. Apparently they are stubbornly rfusing to learn from history. In fact, quite the opposite. The IPhone is far more closed than the Mac ever was, and now that there's a real competitor out there, the writing is on the wall. Unless Apple radically opens up, the IPhone's going to go from market leader to niche within a year.
Jeff Heaton has released
Encog for Java 1.0,
"an advanced neural network and bot programming library. Encog can be used independently either to create neural networks or HTTP bot programs. Encog also includes classes that combine these two advanced features. Encog contains classes for Feedforward Neural Networks, Hopfield Neural Networks, and self organizing maps. Training can be accomplished using backpropagation, simulated annealing, and genetic optimization. Additional classes are provided for pruning neural networks.
Encog also includes advanced HTTP bot programming features. A multithreaded spider that can store its workload either in memory on a database is provided. HTML parsing is provided, as well as advanced form and cookie handling."
Encog is published under the LGPL.
Sun has posted an early draft review of Java Specification Request 314: JavaServer Faces 2.0. This makes various minor updates to support Java 1.5 features, align the spec with JAX-RPC 2.0, and support subsitution groups. According to the JSR:
Requirements are grouped into four major categories: Ease of Development, New Features and Fixes, Performance, Technology Adoption. Following are some initial requirements that will be prioritized and considered when the Expert Group convenes. Not all of these ideas will be in the final specification. Some of these requirements may be met in the Servlet specification (or other Java EE specification) but they are stated here because they are critical to the success of JavaServer Faces.
Ease of Development
While this was the major theme for Java EE 5, it was not the major theme for the version of the JavaServer Faces specification included therein. The act of writing JSF applications and components "by hand" will be made much easier by this JSR. Example requirements in this category include:
- Component aggregation. Allow development of custom component with little or no Java coding. [A] Perhaps consider a standard set of aggregations.
- Allow for "zero configuration" web applications. No faces-config.xml, no web.xml. If necessary, annotations will be used to supplement the configuration data.
- Vastly improve the developer experience with regard to error messages that happen during iterative development, and even during deployment of the application. For example the EG will consider options including, allowing the developer to tell the runtime what stage of development the web application is in, and take action accordingly: Development, Test, Deployment. Line precise error reporting. Pluggable Exception Handling.
- Provide default exception handling mechanisms. For example, all runtime errors get forwarded to an error page.
- Eliminate the need to author a JSP tag handler when writing JSF components.
- Leverage annotations to declare JSF artifacts (components, managed beans, navigation rules, etc) to the runtime.
- Declarative Renderers, otherwise known as Renderers without resorting to out.println().
- Real world, production view description technology, including templating: include something influenced by Facelets, JSFTemplating or Tiles in the specification.
- Make it very easy to create CRUD based applications.
There are also a number of container improvements that should be considered to improve developing web applications in general:
- Eliminate the "deployment step". All the artifacts that comprise a JSF application can be modified while the application is running. This will bring the responsiveness people have been used to with iterative JSP development to the JSF developer. One design idea for this is to allow JSF artifacts to be authored in Script.
- Expand the contract of the exploded WAR (and non-exploded WAR) to have knowledge of JSF artifacts. For example, define a place within the WAR structure for such artifacts as components, renderers, converters, etc. Having a concrete correspondence between the constituent parts of a JSF application and actual directories within a WAR will make it easier to understand an application and also map help with the elimination of the deployment step.
New Features
Requirements in this category stem from feedback from real world JSF users and are incremental improvements on the existing specification. This category includes fixes and updates to existing APIs. Example requirements in this category include:
- Expand the request processing lifecycle to be aware of Ajax. This may include describing a small developer-contract footprint JavaScript library as part of the JavaServer Faces specification.
- Separate the "build the tree" and "render the tree" processes into two separate lifecycle phases.
- Allow for partial tree traversel during lifecycle execution via Ajax.
- Allow for bookmarkable JSF pages. More broadly, if HTTP GET can be used, it should be used.
- Decent client side, inter-component and form-level validation (leveraging JSR-303 validation if possible).
- First class support for bundling and delivering static resources associated with a component: images, stylesheets, scripts, etc. Should be able to specify default locations for resources.
- Strategic additions to the Standard HTML RenderKit: Date Picker, Tree, Tab View, File Upload components.
- Provide a mechanism to minimize the "Lost Update" and "Duplicate Button Press" problems. These mechanisms must be pluggable or customizable from the user.
- Page actions: The ability to say, "when this page loads, invoke this action (via Ajax if necessary)."
- Provide a mechanism to easily access persistent store.
Runtime Performance and Scalability
The flexibility of the JavaServer framework can lead to performance concerns. Requirements in this category make modifications and restrictions to the specification to increase performance across the board for all implementations of the specification. Example requirements in this category include:
- Saving and restoring page deltas rather than saving and restoring the full view state each time.
- Re-do UIComponent state saving with a view towards making stateless components the default.
- Allow for moving as much of the event processing and inter-page component interaction into the client as possible. This may imply specifying client side controller framework.
- Streamline the rendering process via caching if possible.
- Improve the interceptor mechanism delivered via the PhaseListener feature so that the developer can control exactly what kinds of requests are allowed to be processed by each PhaseListener instance.
Adoption
Increasing the capability of the JavaServer Faces standard will continue to attract more people to write applications targeting the standard, thereby raising the bar for Java web applications. Features in this category aim to attract new developers to use products that implement the JavaServer Faces specification. Example requirements in this category include:
- Enable components to have a client based lifecycle in addition to, or instead of the server based request/response lifecycle. Such a client based lifecycle would enable use-cases such as drag-and-drop, master-detail and sub-dialogs on a single page interface web application.
- Improve the UIComponent specification to allow an increase in the interoperability of UIComponent libraries from arbitrary vendors.
- Enable applications to use features that are defined in the JavaServer Faces specification but are intended for use in the Java EE platform as a whole. For example, the managed bean facility is useful even in an application that only uses Servlets from Java EE but provides the rest of the web application features from software outside of the platform.
- Allow JSF application resources to be accessed via REST.
- Enable components that publish events via RSS/Atom.
- Add support for REST (JSR 311)
- Broad and pervasive support for scripting at all levels of the specification. It will be possible to use a scripting language to write all executable artifacts in a JSF application.
- Specify command line interface for authoring JSF applications.
- Support for passing values from page to page. This will be a standardization of the many different Dialog/Conversation/Scope/Flash ideas currently in use.
- "Skinning", or "Themeing" of components.
- An important target user for JavaServer Faces technology is the developer who relies on an Internet Service Provider (ISPv) to host their application, as well as hosting their development environment. It must be easy to iteratively develop a JavaServer Faces application that is hosted entirely on an ISP.
I've paid essentially no attention to JavaServer faces, but looking at the list of improvements for 2.0 what I'm struck by is how badly wrong they got version 1.0. I mean, they're just figuring out that GET and bookmarkable pages are a good idea now in 2008? Comments are due by October 16.
Bill Pugh of the University of Maryland has released FindBugs 1.3.5, an automated open source tool for finding potential bugs in Java code. New bug detectors in this release include:
- calls to methods that always throw UnsupportedOperationException
- repeated conditional tests (e.g., if (x < 0 || x < 0) ...)
- Fairly complete implementation of JSR-305 custom type qualifier analysis (no support for custom validators yet). (TQ_MAYBE_SOURCE_VALUE_REACHES_NEVER_SINK TQ_EXPLICIT_UNKNOWN_SOURCE_VALUE_REACHES_ALWAYS_SINK TQ_EXPLICIT_UNKNOWN_SOURCE_VALUE_REACHES_NEVER_SINK)
- Unsatisfied obligations such forgetting to close a file
- Warning when a parameter is marked as nullable, but is always dereferenced.
- Separate warning for dereference the result of readLine
CMP has posted the call for abstracts for Software Development 2009 West. The conference takes place March 9-13, 2009 in Santa Clara. Tracks this year include:
- Agile Processes, People & Methods [Submit]
- Business of Software [Submit]
- C++ [Submit]
- .NET [Submit]
- Dynamic Languages [Submit]
- Java [Submit]
- Mobile Development [Submit]
- Modeling & Design [Submit]
- Requirements & Analysis [Submit]
- Security [Submit]
- Testing & Quality [Submit]
- Web 2.0 and Beyond [Submit]
- Web Services, REST and SOA [Submit]
- New Horizons [Submit]
Submissions are due by October 3.
java.net has published my latest article, The Open Road: javax.annotation. Java 5 introduced annotations to the language. Since then, several important third-party libraries and frameworks have taken advantage of them to good effect, including Guice, Hibernate, and JUnit 4. Libraries designed around annotations are often simpler and easier to work with than the equivalent libraries that use reflection or naming conventions to achieve the same result.
However, the core of Java itself has made relatively little use
of annotations. In fact, only three are built into the language as
of Java 6: @Override, @Deprecated, and
@SuppressWarnings. These are certainly useful, but
they hardly exhaust the space of information we may wish to
annotate in our Java programs.
The JSR 305 effort being led by Bill Pugh of the University of Maryland plans to change this in Java 7, and dramatically increase the number of annotations used in standard Java code. By adding annotations to classes, methods, fields, and variables, you'll be able to tell static and dynamic analysis tools how you think the code is supposed to behave. Then the tools can warn you when they suspect the code will behave in some other fashion. This improves on the current situation, where static analysis tools need to guess not only what the code does, but what it's supposed to do. Such tools will still generate many false positives; but they'll find many more true positives—that is, genuine errors—in annotated code than in non-annotated code.
The Apache JAMES Project has posted JSieve 0.2, a Java implementation of RFC 3028 Sieve: A Mail Filtering Language. According to Robert Burrell Donkin, "A prime (though not the only) use case for Sieve is rule-based filtering into mailboxes after delivery to a server. JAMES server uses JSieve for this purpose."
Panayotis Katsaloulis has posted JavaPlot 0.4.0, a library for interfacing with gnuplot through Java. Java 5 or later and Gnuplot 4.2 are required. JavaPlot is published under the LGPL.
Subversion 1.5.2, an open source version control system designed to replace CVS, has been released.
This appears to be a bug fix release.
Google has released GWT 1.5, an open source Java-to-JavaScript compiler and library for building AJAX applications in Java. The major new feature in 1.5 is support for Java 5, including generics, enums, annotations, and the enhanced for loop.
The Apache Commons Group has released Commons BeanUtils 1.8.0. This provides some easier-to-use wrappers around Java's built-in Reflection and Introspection APIs. "BeanUtils 1.8.0 is binary compatible with version 1.7.0 and contains a number of bug fixes and enhancements." In particular:
- A new "generic" that delegates the individual component conversion to a Converter for the component type.
- Numeric Converters convert between numeric types and to and from Strings
- The SQL Date, Time and Timestamp converters now convert between Date/Calendar types and to and from Strings
BeanUtils is published under the Apache License 2.0.
Copyright 2008 Elliotte Rusty Harold
elharo@metalab.unc.edu