Bill Pugh of FindBugs fame has submitted JSR-305, Annotations for Software Defect Detection to the Java Community Process. According to the JSR,
This JSR would attempt to develop a standard set of annotations that can assist defect detection tools. Such annotations have been found to be useful in tools such as FindBugs and IntelliJ, but developers are hesitant to invest time in providing annotations if they don't know that their annotations will be portable across tools.
These annotations will be applied using the existing annotations capabilities introduced in Java 5, and may also utilize any additional annotation capabilities introduced in Java SE 7.
Some annotations already identified as potential candidates include:
Nullness annotations (e.g., @NonNull and @CheckForNull). Both FindBugs and IntelliJ already support their own versions of nullness annotations.
Check return value annotation - an annotation that says ignoring the return value of a method is likely incorrect (e.g., String.toLowerCase())
Taint annotations - We want to check for errors such as SQL injection and cross-site scripting (see Detecting Format-String Vulnerabilities with Type Qualifiers, Umesh Shankar, Kunal Talwar, Jeffrey S. Foster, and David Wagner 10th USENIX Security Symposium. Washington, D.C., August 2001 for a discussion of using taint annotations in static analysis).
concurrency - We all know that concurrency is hard and statically detecting concurrency errors is very hard. We can look at the annotations proposed by Java Concurrency In Practice and by the CMU Fluid project as a starting point.
Internationalization annotations, such as @NonNls or @Nls, indicating values that either are or are not natural language strings that need to be localized for different locations. These annotations are currently used by IntelliJ.
Many of these annotations could be much more useful if annotations could be supplied in places where that can't currently be applied (e.g., to generic type parameters), and if default annotations could be supplied (e.g., marking all methods in a class or package as having nonnull parameters unless otherwise specifically so annotated).
In addition to FindBugs and IntelliJ, other tools could benifit from such annotations, such as Fortify Software's SCA, Coverity's forthcoming Java analysis tool, the Netbeans Jackpot tool, and IBM's SAFE tool.
We would try to develop annotations that could be usefully applied with a low annotation burden (e.g., making only a few annotations per class), although more intensive annotations might provide additional value.
WBEM Solutions, Inc has posted the public review draft of JSR-48 WBEM Services Specification to the Java Community Process (JCP). According to the draft:
Web Based Enterprise Management (WBEM) is a set of specifications that unify the management of enterprise computing environments. WBEM provides the ability for the industry to deliver a well-integrated set of standard-based management tools leveraging the emerging Web technologies. The Distributed Management Task Force (DMTF) has developed a core set of standards that make up WBEM.
This specification along with the Javadoc defines the JavaTM WBEM API This allows any JavaTM VM to become WBEM enabled as well as allow any JavaTM VM to manage any WBEM (SMI, SMASH, ...) enabled managed elements.
Sun has posted the fifth maintenance review change log for JSR 3: Java Management Extensions. The single proposed change is to clarify how MBean runtime exceptions are handled. Comments are due by September 26.
Novell has released Mono 1.1.17, an open source implementation of Microsoft's .NET framework that runs on Linux, Unix, Mac OS X, and Windows. Changes in this release include:
The Mono Basic compiler and the Basic runtime have been removed from the Mono distribution. A new compiler that is compatible with Visual Basic 2005 and a matching runtime are now part of a separate distribution. On this particular release, we are offering the basic runtime, but the compiler is not able to run completely on Mono yet.
Windows.Forms: Printing is now supported.
This release is able to compile and build IronPython 1.0 RC2.
COM: Basic COM support has been integrated.
Sun has posted the public review draft of JSR-270 Mustang Release Contents to the Java Community Process (JCP). As expected many other JSRs are rolled up in this release including:
- JSR 105 XML Digital-Signature APIs
- JSR 173 Streaming API for XML (StAX)
- JSR 181 Web-Services Metadata
- JSR 199 Java Compiler API
- JSR 202 Java Class-File Specification Update
- JSR 221 JDBC 4.0
- JSR 222 Java Architecture for XML Binding (JAXB) 2.0
- JSR 223 Scripting for the Java Platform
- JSR 224 Java API for XML-Based Web Services (JAX-WS) 2.0
- JSR 250 Common Annotations
- JSR Final Release
- JSR 269 Pluggable Annotation-Processing API
- JSR 3: Java Management Extensions (JMX)
- JSR 160: Java Management Extensions (JMX) Remote API 1.0
- JSR 206: Java API for XML Processing 1.4
Specific new features include:
- System-tray support
- Pluggable locale data
- JTable sorting, filtering, and highlighting
- File-I/O enhancements
- Console class (This would have been important about 20 years ago. Why they're bothering now I have no idea.)
- Generalized MBean descriptors
- MXBeans
- GIF image writer
- Access to desktop helper applications
- Fast splash screens
- Per-window modal dialogs
- Resource-bundle enhancements
- Unicode string normalization
- Baseline and gap APIs
- Easier Swing layout manager
- Improved Swing drag-&-drop
- Tabs as components in
JTabbedPane - SwingWorker
- Text-component printing
- Access to heap contents
- Multiple simultaneous agents
- Array reallocation
- Deques
- Sorted sets and maps with bidirectional navigation
- Core IEEE 754 recommended functions
- Service-provider lookup
- Generalized lock monitoring
- Generic annotations for MBean descriptor contents
- Internationalized domain names
- Programmatic access to network parameters
- Simple HTTP cookie manager
One of the biggest changes is that this draft actually defines a process for removing a feature from Java. (I can think of quite a lot that deserves that treatment.
Removing a feature is a two step process that involves two feature releases and, therefore, two Umbrella Expert Groups (UEGs).
The UEG for release N of the platform may decide to propose that a feature be removed. The only immediate consequence of this action is that the release N specification is updated to indicate, in a very prominent way, that the feature may be removed in release N+1, or in some later release.
The UEG for release N+1 gets to make the actual decision as to whether the feature is removed from that release, retained as a required component, or left in the “proposed removal” state for the next UEG to decide. It is generally expected that they will follow through on the proposal made by UEG N unless new information indicates that the Java community would be better served by one of the alternatives.
If the UEG for release N+1 decides not to remove the feature but also decides not to retain the feature as a required component then the UEG for release N+2, and so on, will be faced with the same three-way decision.
The decision by UEG N to propose the removal of a feature, and the decision by UEG N+1 or some later UEG to remove the feature, or to retain it, or to leave it in limbo, must be made prior to the publication of the Public Review draft of the corresponding platform specification and, obviously, communicated in that draft.
Each UEG involved in this process is expected to undertake widespread consultation with the Java SE community, and especially with those using current releases in production settings, in order to ensure that the community supports the proposed feature removal.
Once a feature has been proposed for removal, but before it is actually made optional, platform implementors are strongly encouraged to provide mechanical assistance to developers, e.g., in the form of compile-time warnings, that the feature may be removed in the next release.
Maybe we'll finally get rid of some of the deprecated APIs.
A couple of features have been removed from this draft as well. In particualr IRIs are no longer supported and reflective access to parameter names has been deferred at least till Java 7.
Comments are due by September 26.
Nakina Systems has posted the public review draft of JSR-254 Java Authentication Service Provider Interface for Containers to the Java Community Process (JCP). According to the draft:
As part of the OSS Through Java Initiative, Discovery Control is an API which provides model agnostic control of the discovery and update of resource and service information that populates the OSS/J Resource and Service Inventories in J2EE based network, service and business management components.
In particular, Discovery Control provides APIs for:
- Discovery Instance Management
- Discovery Execution Management
- Seed Data
- Discovery Levels
- Schedule
- Status
Motorola and Nokia have posted the proposed final draft of JSR-232 Mobile Operational Management to the Java Community Process (JCP). According to the draft:
The Mobile Operational Management API specification defines an optional package1 for the Java 2 Platform, Micro Edition (J2ME™). The specification has been produced in response to Java Specification Request 232 (JSR-232), and specifies the a component management framework that will allow mobile devices based on the J2ME TM Connected Device Configuration to evolve and adapt their capabilities by installing new components on demand. These components can be a combination of active elements with no user interaction (services), active elements with user interfaces (applications), and shared libraries (both native and Java). The framework will also provide for multiple applications to coordinate the use of sharable services. In order to ensure a safe environment, these components will be controlled via a mandatory security model based on the JavaTM 2 Platform security model.
Sun has posted the public review draft of JSR-268 Java Authentication Service Provider Interface for Containers to the Java Community Process (JCP). According to the draft:
This specification defines a service provider interface (SPI) by which authentication providers implementing message authentication mechanisms may be integrated in client or server message processing containers or runtimes. Authentication providers integrated via this interface operate on network messages provided to them by their calling container. They transform outgoing messages such that the source of the message may be authenticated by the receiving container and/or such that the recipient of the message may be authenticated by the message sender. They authenticate incoming messages and return to their calling container the identity established as a result of the message authentication. The SPI is applicable to diverse messaging protocols (including SOAP, JMS, and HttpServlet) and message processing runtimes (including J2EE containers).
Comments are due by September 18.
Amdocs Management Ltd. has posted the public review draft of JSR-190 Event Tracking API for J2ME specification and reference implementation to the Java Community Process (JCP). According to the draft use cases include:
Collecting statistics for learning market behavior, for example, game launches can be monitored to determine the most popular games.
Monitoring the success or failure of users in regard to application activities to promote the usage of a particular game, for example, a peer-to-peer war game can be monitored and controlled by a game's server, which would be responsible for supplying "live points" for users who hit certain targets or who achieve certain goals. The monitoring and tracking is performed via a Tracking API.
Promoting the sale of games according to tracked information, for example, the purchase fee might be returned to the ten-highest scorers each week.
Improving the service using information collected from the Set Top Box, for example, the Set Top Box can enable the user, using the remote control to send feedback, to react to specific events in a show.
Tracking physical behavior, for example, tracking applications, such as GPS vehicle tracking systems using GSM or GPRS.
Monitoring and controlling various situations over GSM or other networks, for example, greenhouse temperature and humidity sensors can use the standard API to send event records from the sensors to the monitoring and control server.
The Object Refinery Ltd has released JFreeChart 1.0.2, a free-as-in-speech (LGPL) chart library for Java. JFreeChart supports:
- 2D and 3D pie charts
- Regular and stacked bar charts
- Line and area charts
- Scatter plots and bubble charts
- Time series, high/low/open/close charts and candle stick charts
- Combination charts
- Pareto charts
- Gantt charts
- Wind plots, meter charts and symbol charts
- Wafer map charts
According to David Giilbert, "This release features a range of API usability enhancements, two new array-based dataset classes, performance enhancements in some renderer classes, and numerous bug fixes. In addition, the distribution includes experimental support for the Standard Widget Toolkit (SWT) via a custom SWTGraphics2D class."
The Apache Project has posted the first beta of version 1.7 of Ant, the popular XML based, open source build tool for Java.
Ant 1.7 introduces a resource framework. Some of the core ant tasks such as <copy/> are now able to process not only file system resources but also zip entries, tar entries, paths, ... Resource collections group resources, and can be further combined with operators such as union and intersection. This can be extended by custom resources and custom tasks using resources.
Ant 1.7 starts outsourcing of optional tasks to Antlibs. The .NET antlib in preparation will replace the .NET optional tasks which ship in Ant. Support for the version control system Subversion will be only provided as an antlib to be released shortly.
Ant 1.7 fixes also a large number of bugs.
Ant 1.7 has no support for Java6 features, but first tests on Java6 did not fail.
The Apache Jakarta Project has released Commons Modeler 2.0:
Java Management Extensions (JMX) is an API that facilitates building management applications that can configure, and perform operations on, a server application. In general, each manageable component of the server application is represented by a Management Bean (or MBean, for short). JMX defines three types of MBeans, of which Model MBeans are the most flexible. Model MBeans provide a way to define MBeans for many different components, without having to write a specific MBean implementation class for each one.
However, this power comes at a price. It is necessary to set up a substantial amount of metadata about each MBean, including the attributes it should expose (similar to JavaBeans properties), the operations it should make available (similar to calling methods of a Java object via reflection), and other related information. The Modeler component is designed to make this process fairly painless -- the required metadata is configured from an XML description of each Model MBean to be supported. In addition, Modeler provides a factory mechanism to create the actual Model MBean instances themselves.
IBM's alphaWorks has released
the Pattern Modeling and Analysis Tool for Java Garbage Collector (PMAT) 1.2. "PMAT analyzes IBM verbose GC traces by parsing the traces and building pattern models. PMAT recommends key configurations by executing a diagnosis engine and pattern modeling algorithm. If there are any errors related with Java heap exhaustion or fragmentation in the verbose GC trace, PMAT can diagnose the root cause of failures. PMAT provides rich chart features that graphically display Java heap usage."
JCraft, Inc has posted JSch 0.1.29, an open source, pure Java implementation of SSH2 that supports port forwarding, X11 forwarding, file transfer, etc. This version adds some minor features including handling hostkeys included in known_hosts file and setting timeout values for opening sockets. Java 1.2 or later and the JCE are required. JSch is released under a BSD license. This release fixes bugs.
Dieter Krachtus and Chris Deckers are working on Eos, "a project to run Eclipse using Swing widgets exclusively." Having seen NeoOffice, this really shouldn't have surprised me, but it did. I'm not sure if they'll ever get it to really work, but if they do, that would be extremely cool. If nothing else it might make Eclipse look decent. While I prefer Eclipse to Swing-based IDEs like NetBeans and IDEA for reasons of functionality, there's little denying that SWT is a very old-fashioned and ugly toolkit. At first glance, Swing apps just look better; even if they don't have the underlying funcitonality and user interaction to go along ewith the chrome.
Jeff Pace has released version 5.1.2 of DoctorJ, an LGPL'd Java application that analyzes Java source code in three areas:
- documentation verification
- statistics generation
- syntax analysis
It especially focuses on comparing API documentation to code.
Version 5.1.2 is said to improve the detection of runtime exceptions (e.g. it no longer complains if you have an @throws comment for a runtime exception, but don't declare it in a throws clause) though I have yet to test this myself. Users will need to inlcude the relevant exception classes in their classpath if they're using custom runtime exceptions. Standard runtime exceptions like NullPointerException and IllegalArgumentException should be automatically detected though.
Google has posted the early draft review of JSR-284 Resource Consumption Management API to the Java Community Process. According to the JSR,
Software systems in many circumstances need awareness of their resource usage. Meeting performance requirements often requires the ability to manage consumption of resources provided by the environment. Resource management is traditionally handled by operating systems, but the growing need to use the Java platform in the systems programming domain adds increased pressure to equip it with resource management capabilities at a level of abstraction that fits gracefully with the language.
Preventing denial of service attacks, providing load balancing, and monitoring the usage of a given resource are all difficult to do in the current version of the Java platform. In general, these and other features cannot be provided without going beyond the Java language proper, through mechanisms such as native code or shell scripts that ask the OS to handle matters related to resource management. The lack of a standard, programmatic way to partition resources available to virtual machine(s) among Java applications has led to a number of ad-hoc solutions.
The Resource Management API for J2SE Applications should address the above and be characterized by the following:
- Wide applicability. The interface should be applicable to a variety of resource management scenarios and allow the expression of numerous resource management policies.
- Flexibility. The interface should enable managing a broad range of resource types. For example, for some applications resources such as the CPU time and heap memory matter most, while other applications may find it more meaningful to manage higher-level resources, such as the number of open JDBC connections or the number of transactions per second, and the API should accommodate this entire spectrum.
- Extensibility. The resource management interface should support the addition of new resources in a uniform manner.
- Completeness of abstraction. The interface should hide from applications whether a given resource is managed by the underlying operating system (OS), by the Java Virtual Machine (JVM), by a core library, or by trusted middleware code. As a consequence, it should be possible to write resource policies for resources exhibiting common behavior abstractly, without regard for how those resources are implemented.
- Lack of specialization. The interface should not require an implementation to depend on specialized support from an OS or from hardware, although implementations should be free to take advantage of such support if available.
- Ease of exposing resources through the API in a low-overhead fashion.
- Diagnosability. It should be straightforward to determine cause(s) of an application running into resource constraints.
- Simplicity of use. While excercising the full power of the API may require expert knowledge, it should be simple to perform common resource management tasks.
Concrete examples are given below to demonstrate the need for and usefulness of the proposed specification. None of them can be realized by current APIs.
- An application management environment needs to confine each application to at most 32MB of heap memory and would like to detect applications that use more than 90% of CPU time in order to terminate them. Moreover, a minimal quantity of heap and CPU should be reserved for each application to ensure a basic level of service.
- An application would like to be notified when its usage of network resources exceedes 10MB/s, so that it can start compressing data before sending it, but only if the total CPU time consumption is below 50% (effectively this policy is about trading one resource for another).
- A service provider would like to understand (for profiling or billing purposes) how much of each resource of interest (memory, CPU time, SQL statements submitted over JDBC connections, etc.) each user is consuming.
- A service provider would like to distinguish between users with "platinum", "gold", and "silver" contracts and offer them different QoS level. This translates into the need to partition resources according to the contractually agreed upon QoS.
The API should enable resource management policies to be programmed. In particular, such a policy should have the ability to define when an application may gain access to, or consume, a unit of a specific resource. It should be possible to bind computations dynamically to policies. Programs should be able to reserve resources in advance and thus ensure predictable execution. Applications should be able to install resource monitoring code so that proactive programs can observe resource availability and take any actions required to ensure performance and availability or to ward off denial of service attacks. Existing applications should run without modification, even if the Java platform classes or the Java runtime environment they depend depend on exploits the resource management framework. The interface should not impact in any way how actual resource providers (schedulers, automatic memory subsystems, etc.) should be written - it should be possible to make these providers become "RM-enabled" by inserting calls to appropriate API methods to convey information about resource consumption attempts. The effort required to retrofit existing resource managers should thus be minimized.
The specification will build upon the abstraction of an isolate, as defined in JSR 121. An isolate is an encapsulated Java program or application component that shares no state with other isolates. Isolates are a convenient abstraction on which to develop resource management: isolation allows unambiguous resource usage accounting and clean reclamation upon program termination. The expert group will also look at enabling the API to operate on platforms that do not support the Isolate API. In particular, a single JVM could be viewed as a special case of a single isolate.
In addition to defining an API, which will be a framework through which resources can be uniformly exposed to client programs as entities subject to management, the outcome of this JSR will include a non-empty set of resources deemed core and required by compatible implementations.
Comments are due by September 22.
Sun has posted the public review draft of JSR-268
Java Smart Card I/O API
to the Java Community Process (JCP). This defines the javax.smartcard package.
Jeff Pace has released
DiffJ 1.1.1, a commandline application "like the Unix program diff, but specifically for Java code. It compares Java source files so that only the code is compared, not whitespace nor comments. Output is also specific to Java code, showing, for example, methods that have been moved, parameters that have renamed, and exceptions added. For code within methods, the method name is displayed." 1.1.1 is a bug fix release.
I've been playing with IntelliJ IDEA 5.1 for the last day or so. It seems OK, less buggy than NetBeans and no stranger or buggier than Eclipse. I wouldn't exactly call it a model of good user interface design though. There are lots of little glitches, such as menu bars that disappear when certain windows are open, omitted menu shortcut keys, menu items that bring up dialogs but don't end in ..., a non-native busy cursor, Mac OS 9 file dialogs, application exiting when I close the last window, outdated screen shots in the Help files, a Windows menu that doesn't keep a list of open windows, and for some unexplained reason I have to save a color scheme before changing the default font.
I'm having a devil of a time figuring out basic things like how to stop IDEA from folding my comments, and how to set up the classpath. All of these are far from obvious. The small buttons with weird icons don't help here. I still haven't been able to figure out how to indicate that one project depends on another (e.g. that Jaxen depends on XOM and vice versa). I suspect Eclipse is equally or perhaps more confusing to a new user, but at least I'm used to its idiosyncrasies.
IntelliJ IDEA is famous for its refactorings, but so far I don't see why. To date it's made three suggestions, each of which was flat-out wrong. The latest is a claim that an import is unnecessary when the class it imports is used in the first line of the main() method.
IntelliJ hung on me once. It was a weak hang—the busy cursor spun indefinitely while opening a package, but I could still do other things—but it was still a hang. I had to quit and restart the program.
If I were evaluating IDEs on a level playing field, I might pick IDEA, but I'm not. Eclipse has two big advantages over IDEA:
- Eclipse is open source, and thus has a much larger active community fixing its problems and adding to its functionality.
- I'm already used to Eclipse's weirdnesses and UI glitches.
However, the bottom line is that the state of the art in IDEs for Java isn't nearly good enough. I wish someone would invest in some real human factors research on IDE design. What we have now is a confusing mishmash of features baked together without much thought for what the resulting product will look or feel like.
I could swear things didn't used to be this bad. Years ago when I was doing C and C++ development with products like Think C and Borland C++ Builder, the IDEs actually made sense. Maybe my sense of aesthetics has gotten more refined over the years, or maybe my projects are larger and more complex, or maybe Java is just harder to design for than a compiled language. (The classpath is a big part of that.) Whatever the reason(s), IDEs are just too klunky.
Polarion Software has released Subversive 1.0.2, a pure Java, open source Eclipse plug-in that provides Subversion integration. 1.0.2 adds a decoration for read-only files that need locks, a subversion import wizard, and the ability to checkout subdirectories.
Sun has posted the early draft review of JSR-291 Dynamic Component Support for Java SE to the Java Community Process. "The OSGi Service Platform Core Specification defines dynamic component technology for Java. JSR 291 introduces this into the Java Community Process (JCP) for Java SE. JSR 232 does the same for Java ME. The result is a consistent dynamic component technology across Java SE and Java ME. The requirements of JSR 291 are targeted at Version 4.1 of the Core Specification". Comments are due by September 1.
Sun has also posted the early draft review of JSR-286 Java Portlet Specification 2.0 . "This first draft does not contain all the functionality that the JSR 286 EG considers for this JSR, but mainly supports the features introduced with Web Service for Remote Portlets (WSRP) V 2.0 defined at OASIS and thus the JSR 286 EG seeks feedback these features. Additional features will be introduced with a second early draft." Comments are due by September 1.
Jeff Pace has released version 5.1 of DoctorJ, an LGPL'd Java application that analyzes Java source code in three areas:
- documentation verification
- statistics generation
- syntax analysis
It especially focuses on comparing API documentation to code. Version 5.1 adds support for Java 5.
I tested it on XOM, and the results weren't promising. All it caught were false positives about @throws clauses. Indeed the recommendations it gave were counter to accepted Java-design guidelines for documenting runtime exceptions.
David Cranshaw has released
SQLiteJDBC 016, a JDBC driver for the SQLite database. "It is written as a thin driver on top of the SQLite 3.3.x C API. The native JNI library has SQLite compiled into it so all you need to do is include the two files packaged above in your project." It's published under the BSD license.
The Big Faceless Organization has released the Big Faceless PDF Library 2.7.1, 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.7.1 adds digital signature timestamps and remote signatures via a web service.
I've been having troubles with Eclipse lately so I decided to give NetBeans yet another try. (Longtime readers will recall that I have been trying various versions of NetBeans and its predecessors for years and have yet to find a release that I considered good enough to use.) With the latest 5.5 beta NetBeans is clearly improving, but it's not there yet. As soon as I tried to create a new project, this is what I saw:
java.lang.ArrayIndexOutOfBoundsException: 1
at java.awt.Container.createHierarchyEvents(Container.java:1335)
at java.awt.Container.createHierarchyEvents(Container.java:1335)
at java.awt.Container.createHierarchyEvents(Container.java:1335)
at java.awt.Container.createHierarchyEvents(Container.java:1335)
at java.awt.Container.createHierarchyEvents(Container.java:1335)
at java.awt.Container.createHierarchyEvents(Container.java:1335)
at java.awt.Container.createHierarchyEvents(Container.java:1335)
at java.awt.Dialog.conditionalShow(Dialog.java:450)
at java.awt.Dialog.show(Dialog.java:506)
at org.netbeans.core.windows.services.NbPresenter.superShow(NbPresenter.java:816)
at org.netbeans.core.windows.services.NbPresenter.doShow(NbPresenter.java:859)
at org.netbeans.core.windows.services.NbPresenter.run(NbPresenter.java:847)
at org.openide.util.Mutex$1.run(Mutex.java:1194)
[catch] at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:199)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:461)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)Obviously this is a bug. In fact, they're at least three bugs here, one major, one serious, and one cosmetic. (If you only see two, it's because the cosmetic bug is hiding the serious bug.) Hopefully Sun will fix all of them before release. I'm not sure if they know about these yet. They've got quite a few ArrayIndexOutOfBoundsExceptions in thier bug database. It's not clear if any of them are the same as mine. I also found a fourth and fifth issue, unrelated to these three when moving on. If I file all of these, that will be seven bug reports today. (Two in Eclipse and five in NetBeans.) Do I really have the time for this? Especially when my first attempt to enter the issue is met with "Permission denied"?
I guess I'm a glutton for punishment, because I did file the bugs; but when I hit the sixth, seventh, and eighth issues, I gave up. It's not like I'm trying to break NetBeans, or look for edge conditions. I'm going right down the center path, doing exactly what any normal user would do; and I just keep spotting problem after problem without half trying. If Sun wants to hire me to test NetBeans, they can; but otherwise I don't have time for this right now.
Update: Bob Treacy tells me one of my bugs has been reported at least twice already, and is fixed in the nightly builds. I had done a cursory search for the bugs before reporting them, but nothing showed up. Google proved once and for all that smart, full text search beats the pants off of fielded boolean searches. Sadly most bug tracking systems haven't learned this lesson yet.
NetBeans vs. Eclipse feels a little like Achilles chasing the tortoise. NetBeans is always getting closer, but they never quite catch up.
Jeff Pace has released
DiffJ 1.1.0, a commandline application "like the Unix program diff, but specifically for Java code. It compares Java source files so that only the code is compared, not whitespace nor comments. Output is also specific to Java code, showing, for example, methods that have been moved, parameters that have renamed, and exceptions added. For code within methods, the method name is displayed."
IDRsolutions has released JPedal 2.8, a pure Java library for extracting content from PDF files and rasterizing them. Text fragments are extracted as XML elements with font and location information. Images are extracted in both their raw formats and their clipped and scaled formats as TIFF, PNG, or JPEG files. Version 2.8 adds a full-screen mode and page layout options. JPedal is published under the GPL.
The Big Faceless Organization has released the Big Faceless Graph Library 2.2.4, an $800 payware (more if you want support or to distribute your applications that use the library) Java class library for plotting 2D or shaded 3D pie charts, line graphs, area graphs, bar graphs and exporting them to PNG, GIF and PDF. Version 2.2.4 adds digital signature timestamps and remote signatures via a web service. Java 1.2 or later is required.
Joe Walnes has released QDox 1.6, an open source tool for extracting class/interface/method signatures and JavaDoc tags from Java source files. This release adds support for Java 5. QDox is published under the Apache 2.0 license.
Sun has posted the eighth update release for Java 5.0 Tiger with 139 assorted bug fixes and optimizations. As usual it's available for Solaris, Windows, and Linux.
The Eclipse Project has posted the first milestone of Eclipse 3.3, 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. New features in this release. mostly minor, include:
- System tray support on Mac OS X
- Printing support on GTK+
- Writing PNGs
- Browser support on PowerPC
- GtkComboBox now utilized when available
- Help search term highlighting
- Browse all references in the debugger in Java 6
- Auto format stack traces
- Scripted refactorings
- More Java search options
- Improved editing for MANIFEST.MF and plugin.xml files
Apple has posted the sixth beta of Java 6 for Mac OS X 10.4 (Tiger) on the Apple Developer Connection (first born child required). This release is based on Sun's JDK 1.6.0_b88.
The GNU Project has released version 0.92 of GNU Classpath, an incomplete free implementation of the core Java class libraries. Version 0.9 2"is the first release that has a full graphics 2D implemenation based on Cairo enabled by default. This enables the use of applications like JEdit, FlickrBackup and JFreeChart out of the box." 0.92 also adds an applet viewer and browser plugin. GNU Classpath is published under the GPL with library exception.
TeamDev Ltd has released JNIWrapper 3.3, a $149 payware library for invoking native API calls from Java without writing your own JNI code. It runs on Mac OS X, Windows, and Linux. I have not tried this myself, but it sounds like what JNI should have been. I'm intrigued. I'd definitely evaluate this if I were doing closed source development that needed to call the native API; but since I'm not, I won't. However if anyone who is wants to take a look and let me know what they find, I'll post it here.
Apple has released version 2.4 of Xcode, "Apple's tool suite and integrated development environment (IDE) for creating Mac OS X Universal Binaries that run natively on PowerPC and Intel-based Macintosh computers. The IDE provides a powerful user interface to many industry-standard and open-source tools, including GCC, javac, jikes, and GDB. Xcode is designed to fully support the Carbon and Cocoa frameworks and Java. It contains templates for creating applications, frameworks, libraries, plug-ins, Java applications and applets, and command-line tools. Developers can use Xcode to construct a user interface, test code performance, and perform many other common development tasks." 2.4 mostly focuses on 64-bit support and the native compilers. I don't notice any new Java features in it. Mac OS X 10.4 (Tiger) is required. Xcode and its updates are free beer. With Mac OS X Apple wisely stopped charging for developer tools. You'll still need an ADC membership (including the free membership) to get a copy.
The Exolab Group has released Castor 1.0.2, an open source (BSD license) data binding tool for XML and Java. Castor can marshal and unmarshal XML documents into Java objects, and store those objects in SQL databases. Automatic generation of Java classes from W3C XML schema language schema is supported, though that doesn't seem to be required. New features in 1.0.2 include generation of Java 5 code.
Frank Cohen has released TestMaker 4.4, an "open-source utility and framework for testing Web applications, services, and SOA for scalability, performance and reliability."
The Apache Portal Project has released Portals Bridges 1.0, the open source reference implementation of the Java Portlet Specification. According to the announcement, "The Portals Bridges Project provides Portal independent and JSR-168 compliant Portlet components. The released set of components supports Portlet development using common web frameworks like Struts, JSF, PHP, Perl and Velocity. The Bridges were initially developed by the Jetspeed-2 Team and is actively used by Jetspeed-2 itself. Several other Portals are already adopting and providing support for Bridges too like Apache Cocoon Portal, JBoss Portal, GridSphere Portal and Stringbeans Portal."
The Apache Jakarta Project has released JMeter 2.2 (a.k.a. 2.1.2 in the release notes), an open source (Apache 2.0 license)
load testing application written in Java. "Apache JMeter may be used to test performance both on static and dynamic resources (files, Servlets, Perl scripts, Java Objects, Data Bases and Queries, FTP Servers and more). It can be used to simulate a heavy load on a server, network or object to test its strength or to analyze overall performance under different load types. You can use it to make a graphical analysis of performance or to test your server/script/object behavior under heavy concurrent load."
Steve Roy has posted Jaree 1.1d6, a free-as-in-beer utility "that wraps a user interface around the jar and javap tools to let you see the contents of Java JAR files. It shows you the hierarchical contents of the packages, and double-clicking on a class shows you its members and methods. These can be copied to the clipboard, and one nicety is that you can also copy their internal type signatures which is useful when writing JNI code."
Slava Pestov has uploaded the sixth pre-release of jEdit 4.3, an open source programmer's editor written in Java with extensive plug-in support and my preferred text editor on Windows and Unix. Besides bug fixes, this release adds syntax highlighting for MySQL and django templates.
The Omni Group has released
OmniGraffle 4.1.2,
a general purpose Mac OS X diagramming tool and my
UML editor of choice. 4.1.2 is a bug fix release.
OmniGraffle ranges from $79.95 to $149.95.
The Apache Jakarta Commons Team has released Commons Attributes 2.2, an open source library that "enables Java programmers to use C#/.Net-style attributes in their code." This looks like a bug fix release. According to Henri Yandell, "Attributes is considered to have been made obsolete by the Java 5.0 release, so 2.3 and beyond are not expected to be created."
Sun has posted maintenance revisions of four Java 2 Micro Edition (J2ME) specifications. These are
David Koelle has released JFugue 2.1, a free-as-in-beer Java library for music programming thgat isloates developers from MIDI. Source code is provided.
Motorola has submitted JSR-304, Mobile Telephony API version 2 to the Java Community Process. According to the JSR,
This JSR will describe telephony connection enhancements to extend the API's defined in JSR253 (MTA) to cover additional functionality which were not included in that initial version. Examples of these capabilities include a mapping for use in Voice/Video over IP based protocols, methods to obtain telephony related device settings (device management specific), and control of the media stream associated with a session. Additional interfaces, as well as mappings to new protocols will be defined.
Specific functionality which is being considered for inclusion in this version of the interface includes:
- Media interface control associated with telephony sessions ? allowing an application to specify how the received images for a video call should be displayed, for example. Some use cases include volume control of calls, insertion of audio/video samples in voice/video calls, recording of calls, displaying video calls in the terminal and the possibility to apply media filters in the call media stream (equalizer, white balance, etc).
- Control over parameter negotiation related to a call, such as selecting a voice codec to be used for the session. Some use cases include getting the capabilities for media sessions in the terminal (support for voice, video, VoIP, etc.), setting audio/video parameters (codec, resolution, etc) for a call session, etc.
- Supplemental services not covered by MTA1, such as the user-user supplemental service and multicall;
- Interfaces to modify how the platform handles incoming calls, such as suppressing platform generated ringtones for compliance or overwriting of the platform profile settings;
- API mapping annex for Voice/Video over IP based services, for example in establishing a call session using these services. This annex would indicate how JSR-253 interfaces should be implemented over JSR-281.
Polarion Software has released Subversive 1.0.1, a pure Java, open source Eclipse plug-in that provides Subversion integration. 1.0.1 cleans up a few points and fixes bugs.
Oracle has submitted JSR-301, Portlet Bridge Specification for JavaServer Faces to the Java Community Process. According to the JSR,
Currently, there are a number of JSF Portlet Bridge implementations including a number that have been open sourced. These implementations vary in style and substance to such as degree as to neither provide consistent interoperability across bridge implementations nor to provide interoperability across JSR portlet containers. I.e. the same JSF artifact can run differently in different bridge implementations and/or the same JSF artifact can run differently in the same bridge implementation running on a different portlet containers. This reduces the effectiveness of developing portlets using JSF technology as there are different rules to learn for different environments.
The purpose of this specification is to standardize the behavior of these bridge implementations to ensure true interoperability for JSF artifacts. The specification will focus on defining behavior related to three areas:
- 1. Coexistence: the specification will define rules ensuring a portlet bridge's implementation doesn't subvert concurrently executing non-portlet based JSF artifacts within the same web application, i.e. servlet/http based JSF artifacts. In addition, the specification will define rules ensuring a portlet bridge's implementation doesn't subvert JSF (controller) extensions that are running in the environment.
- 2. Correctness: there are differences between the portlet model and the JSF model. This specification will define the correct transformations between them.
- 3. Extensions: there are some portlet features for which there are no corresponding JSF concepts. This is increasingly true in the ongoing consideration of the next revision of Java Portlet Specification (JSR 286). For example, how do portlet events map to the JSF execution lifecyle? This specification will define how these extensions behave and are treated in the JSF environment.
The Apache Commons Project has released Commons Email 1.0,
an open source e-mail library "built on
top of the Java Mail API, which it aims to simplify."
Sun has posted the second maintenance review change log for JSR 160: JMX Remote API 1.0 . Three changes, are proposed:
6343209: Specify how SubjectDelegationPermission works for ConnectorServer creators.
The creator of a JMXConnectorServer no longer needs to have all the permissions that connection created by the connector server will use. It can have a SubjectDelegationPermission for each remotely-authenticated identity instead. This simplifies deployment in security-conscious environments.
5021246: Spec for RMI connector should say code downloading used if applicable.
The RMI connector will use code downloading as specified in the article Dynamic code downloading using Java RMI if applicable. The Reference Implementation has always behaved this way, and the specification has been updated to reflect that.
6375696: CORBA tie classes for JMX Remote API should be in javax.management.remote.rmi
For compliance with the OMG's "IDL to Java Language Mapping Specification", the CORBA "tie classes" for the remote objects javax.management.remote.rmi.RMIServerImpl and javax.management.remote.rmi.RMIConnectionImpl should be in the javax.management.remote.rmi package.
Comments are due by August 14.
Sun has also posted the fourth maintenance review change log for JSR 3: Java Management Extensions (JMX) Specification . Proposed changes include:
- Remove javax.management.timer.TimerAlarmClockNotification
- Better support for schema evolution in CompositeData and CompositeType
- OpenType should not declare public static array ALLOWED_CLASSNAMES
- CompositeDataView.toCompositeData should have CompositeType parameter
- DescriptorKey has inconsistent meta-annotations
- ModelMBeanConstructorInfo says certain fields invalid, but doesn't check
- MLet support for native libraries is underspecified and should be optional
- Clarify how DescriptorKey used in an MBean interface is handled
- Clarify behaviour when null Descriptor parameter to MBeanInfo etc
- Better specify type strings in MXBean descriptors
- Added conventional metricType Descriptor field
- Specify that // is reserved in ObjectName domains
- JMX implementations should be allowed to make permission checks even if no SecurityManager
- @javax.management.PropertyNames becomes @java.beans.ConstructorProperties
Comments are due by August 14.