Bare Bones Software has released version 8.0 of BBEdit, my preferred text editor on the Mac. New features in this release include improved handling of Unicode files, HTML Tidy integration, HTML fragment syntax checking, and support for the Perforce source code control system.
BBEdit is $179 payware. Upgrades are $49 for 7.0 owners and $59 for owners of earlier versions. Mac OS X 10.3.5 or later is required so I won't be upgrading as all my systems are running 10.2 or earlier. I'm always amazed at the willingness of software vendors to just throw away potential sales by refusing to support anything but the newest and buggiest OS release.
Sun has posted the second proposed final draft of Java Specification Request 206, Java API for XML Processing (JAXP) 1.3, to the Java Community Process. New features in JAXP 1.3 include:
- An XPath 1.0 query API
- A
javax.xml.datatypepackage for XML<-->Java type mappings - A generic schema validation API
Plus the DOM APIs are upgraded to Level 3, and SAX is upgraded to 2.0.2.
I'll be on vacation for the next week on an island with limited Internet access, so updates will be infrequent to nonexistent until I return in September.
Wolfgang Hoschek found some bugs in DOM conversion in XOM beta 2 so I've posted beta 3 to fix the problem. I've also done some more work to improve the connection between Java 1.5's built-in parser and XOM. None of the public APIs have changed in any way. All beta and alpha code should still run without a recompile.
JPOX 1.0.3 is an open source implementation of Java Data Objects (JDO) JDO 1.0.1 that provides transparent persistence to Java objects. It supports most major SQL databases and can be queried using either JDOQL or SQL. It's published under an Apache-like License.
The Apache Jakarta Project has released Commons Launcher 1.1, a a cross platform Java application launcher that "eliminates the need for a batch or shell script to launch a Java class."
Some situations where elimination of a batch or shell script may be desirable are:
- You want to avoid having to determining where certain application paths are e.g. your application's home directory, etc. Determining this dynamically in a Windows batch scripts is very tricky on some versions of Windows or when softlinks are used on Unix platforms.
- You want to avoid having to handle native file and path separators or native path quoting issues.
- You need to enforce certain system properties e.g.
java.endorsed.dirswhen running with JDK 1.4.- You want to allow users to pass in custom JVM arguments or system properties without having to parse and reorder arguments in your script. This can be tricky and/or messy in batch and shell scripts.
- You want to bootstrap system properties from a configuration file instead hard-coding them in your batch and shell scripts.
- You want to provide localized error messages which is very tricky to do in batch and shell scripts.
Sun's submitted Java Specification Request (JSR) 250, Common Annotations for the Java Platform to the Java Community Process (JCP). According to the JSR, "This JSR well develop annotations for common semantic concepts in the J2SE and J2EE platforms that apply across a variety of individual technologies. With the addition of JSR 175 (A Metadata Facility for the JavaTM Programming Language) in the Java platform we envision that various JSRs will use annotations to enable a declarative style of programming. It would be unfortunate if these JSRs each independently defined their own annotations for common concepts. It would be especially valuable to have consistency within the J2EE 5.0 component JSRs, but it will also be valuable to allowconsistency between J2EE and J2SE. It is the intention of this JSR to define a small set of common annotations that will be available for use within other JSRs. It is hoped that this will help to avoid unnecessary redundancy or duplication between annotations defined in different JSRs. The exact set of annotations will be developed in consultation with the various specifications leads who are currently planning to use annotations within their JSRs." Comments are due by August 30.
Covad Communciations has submitted JSR-251, Pricing API to the JCP. According to the JSR,
Product and offer pricing has historically been the domain of billing, and has recently been duplicated in Ordering, Customer Relationship Management, Sales Force Automation, and Enterprise Resource Planning. As more systems and channels are concerned with pricing and offers, it makes sense to view this vital function as a role unto itself.
The offer and pricing functions are essential for a company to have dynamic responses to changing market conditions on a real-time basis. Resource utilizing transactions could be priced based on the current scarcity of the resource. A carrier could match multiple competitors? prices on a geographic basis. Lower cost channels could receive favourable pricing vis-a-vis higher cost channels.
The Pricing API will provide a central point to consult and determine offers and prices based on a variety of criteria including the specific customer?s profile, location, current promotions, other parties in the transactions, factors peculiar to the request, and any other set of complex, possibly inter-related points. The subscriber systems can use the Pricing API to present a list of offers, determine either static or one-time prices, or present prices that change over time and across the customer base.
The Pricing API will, by necessity, contain the offer and pricing definitions. These definitions, in aggregate, form the Pricing Catalogue. In the static pricing scenario, once a prospect selects an offer, its price must be bound to the order. That prevents future offer and price changes from effecting current customers, if that is the business' desire.
The Pricing API covers both service and resource pricing via their association with products (e.g., both data services subscriptions and purchase of an end-user terminal device). The API will allow the expression of the pricing rules or algorithms that will be used to calculate all fees be they for product or equipment purchase, service installation, recurring subscriptions, service usage fees or cancellation fees.
To compete, a carrier needs sophisticated offer and pricing methods and technologies, much like the mechanisms that have evolved in the air transport industry. Systems such as Billing, Ordering, CRM, ERP, and SFA should be seen as subscribers to pricing, not owners of it. This API promotes Offer and Pricing Management to first-class status within the enterprise systems environment, and supports the TeleManagement Forum's ( http://tmforum.org/) eTOM and its Product & Offer Portfolio Planning and Capability Delivery components.
The thing that jumped out at me about this was bit about "To compete, a carrier needs sophisticated offer and pricing methods and technologies, much like the mechanisms that have evolved in the air transport industry." Doesn't Covad realize how much customers hate pricing in the airline industry? Personally, I'm convinced an airline could charge more in total for its seat capacity if they simply sold one way tickets on any given route at the same price, instead of trying to figure which customers they had to entice with low fares and which they could gouge to make up the difference. I don't have an opinion about whether this a good API for Java or not, but the business model implied here is atrocious. Comments are due by August 30.
Sun's posted the first beta of the NetBeans Integrated Development Environment (IDE) 4.0. NetBeans is available for Windows, Linux, the Solaris(tm) Operating System and Mac OS X. New features in version 4 include:
- Java 1.5 support
- A new project system based on Ant
- Java 2, Micro Edition (J2ME) MIDP development support
- Refactoring including renames (class/method/field), move class, rename package, change method parameters, and encapsulate field.
Mark Hale has posted version 0.915 of JSci, a class library containing many useful mathematical and scientific functions such as complex arithmetic. This release fixes bugs.
Sun's posted a maintenance review draft of the Java Language Specification, Third Edition.
The Java Language Specification, 3rd Edition, has been revised as a result of generics (JSR 14), metadata (JSR 175), language additions (JSR 201), the assert statement (JSR 41 from Java 2 SDK 1.4), the revised memory model (JSR 133), and Unicode supplementary character support (JSR 204).
This Maintenance Review covers additional minor corrections and adjustments including clarifications to:
- floating point literals
- String operators
- private class members
- asserts in initialization
- handling the $ character in class names
- local class declarations
- the distinction between exception handling of expressions and statements
- caveats to interface type members
Comments are due by September 20.
Sun's Joshua Bloch has posted the second proposed final draft specification Java Specification Request (JSR) 175 A Metadata Facility for the Java Programming Language to the Java Community Process. According to the draft,
This document describes a simple program annotation facility for the Java programming language. This facility allows developers to define custom annotation types and to annotate fields, methods, classes, and other program elements with annotations corresponding to these types. These annotations do not directly affect the semantics of a program. Development and deployment tools can, however, read these annotations and process them in some fashion, perhaps producing additional Java programming language source files, XML documents, or other artifacts to be used in conjunction with the program containing the annotations. For example, a tool called a stub generator could generate remote procedure call stubs as directed by annotations indicating which methods were designed for remote use.
As another example of the sort of thing one could do with annotations, consider the familiar @deprecated tag. This tag does not affect the behavior of deprecated elements, but tells the compiler to emit warnings when annotated elements are used. The Javadoc tool also uses these annotations to generate appropriate documentation of the deprecated status of API elements. The deprecation facility was implemented in an ad hoc fashion using documentation comments, but could have been implemented atop a program annotation facility, had one existed at the time the deprecation facility was designed.
A second example of ad hoc program annotation already present in the Java platform is the transient modifier. The presence or absence of this modifier does not affect the semantics of a field, but it may be queried at runtime by the libraries that comprise the serialization subsystem as part of the serialization process. It is also queried at documentation generation time by the Javadoc utility as part of the process of generating documentation for the serialized form of the class.
Since many annotations will be used only by development tools such as stub generators, it makes little sense to retain all annotations at run time; doing so could increase run-time memory-footprint and harm performance. There are, however, some annotation types that are useful at run time, and some that are useful in tools that only have access to class files (not source files). Therefore, certain annotations are stored by the compiler in class file attributes (JVMS 4.7), and some of these annotations are then made available for inspection at runtime via new reflective APIs.
On a positive note, the specification is published in HTML rather than PDF like most Sun specs. Now if we could just convince Sun to make it available on the Web instead of forcing users to download a zip file. (And just to head off a frequent comment, this would in no way prevent Sun from enforcing license agreement as they do now. A document such as this can easily be a response to a POST request. Whether you should have to accept the license to read the document is another story, but there's no technical problem with it.)
Release early; release often. Stefan Matthias Aust noticed some problems using XOM beta 1 with Java 1.5 when the standard Xerces was not in the CLASSPATH so I've posted beta 2 to fix the problem. I would appreciate it if people could test this in both Java 1.4 and 1.5 without having any parsers besides the JDK bundled parsers in their classpaths. There are some pretty skanky hacks behind the scenes to make this all work seamlessly between different parsers and JVM versions, and I've stumbled across at least one major bug JDK 1.5 while implementing this. (Sun promises me the bug will be fixed in their next drop. For the moment, XOM uses a Sun-suggested work-around so it should still work until the underlying bug is fixed.)
While I was at it, I've used TagSoup to make the JavaDoc well-formed (possibly valid, I haven't checked) XHTML. tagsoup-0.9.7.jar is now bundled with the complete distributions. However it's only necessary to build XOM, not to run it.
None of the public APIs have changed in any way. All beta 1 and alpha, code should still run without a recompile.
IBM has posted a beta of Cloudscape 10.0, a relational database written in Java and designed for embedding in Java applications. IBM is preparing to donate Cloudscape to the Apache Software Foundation for eventual release as open source under the name "Derby," but source code does not yet seem to be available.
The Apache Jakarta Commons Team has released Commons Attributes 2.1, an open source library that "enables Java programmers to use C#/.Net-style attributes in their code."
Joshua Bloch and Gilad Bracha have posted the second proposed final draft specification for JSR-201, Extending the Java Programming Language with Enumerations, Autoboxing, Enhanced for loops and Static Import. This describes most of the changes to the core language in Java 1.5 (with the exception of generics). It's not immediately obvious to me what's changed since the last draft. I've done a little work with autoboxing and the enhanced for loops lately. I've decided I like enhanced for loops, but I'm still undecided about autoboxing. Also, kudos to the working group for the doing the spec in HTML instead of PDF. :-) If only they'd just post the damn files on a regular web site, instead of making you download a ZIP archive. :-(
Nathan Fiedler has released version 2.25 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 2.25 adds a close-all-but-this menu item to the tabbed views popup menu and fixes some bugs. JSwat is published under the GPL.
The Big Faceless Organization has released the Big Faceless PDF Library 2.2.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.2.5 reduces memory usage and fixes bugs. Java 1.2 or later is required.
Sun has posted the change log for Java Specification Request 59, J2SE Merlin Release Contents.
This document provides descriptions of specification changes being made in version 5.0 RC ("Tiger") of the JavaTM 2 Platform, Standard Edition (J2SETM).
Version 5.0 includes a set of new Java Specification Reviews (JSRs) that introduce major new functionality. This Maintenance Review does not cover new APIs defined through those JSRs; it documents only smaller changes made under the JCP Maintenance Review process.
The descriptions in this document correspond to the platform changes made since J2SE 5.0 Beta 2. The specification change descriptions are provided for purposes of Java Community ProcessSM public maintenance review.
Comments are due by September 20.
Siemens AG has posted an early draft review of Java Specification request 229, Java Payment API, "an optional package for the Java 2 Platform, Micro Edition (J2M™)" that "specifies the architecture and associated APIs that enables an open, third-party, application development environment for payment transactions." According to the draft:
The scope of this JSR is to define the following:
- A generic optional API to initiate payment transactions and,
- The syntax for the description of the associated provisioning data, enabling API implementers to support different payment instruments.
Both will allow 3rd party developers to build applications with control of features and services that are chargeable. The JSR API may include methods for:
- Requesting a payment transaction,
- Requesting feature and service price management
- Payment service availability
The provisioning data definitions take care that service providers and payment service providers can select a suitable set of payment instruments provisioned for applications during the application deployment time. Primarily payment instruments addressed will be:
- Operator charging
- Stored value accounts
- 3rd party payment service providers
This JSR enables application developers to initiate mobile payment transactions from J2ME applications. It is an optional package for the J2ME CLDC configuration and targeted for MIDP or IMP devices. Scope of this JSR is to provide a generic payment initiation mechanism, which hides the actual payment architecture and complexity from the developers. This JSR does not define and imply any concrete payment implementation and mechanism but is generic enough to support different implementations. It is up to the implementing party to realize the API based on one or more technical solutions enabling the application initiated payment. The JSR also does not define any user behaviour or user interface but leaves them to be defined by the actual implementation of the API.
The NetBeans Project has posted the first alpha release of a profiler based on Sun Labs' JFluid. It can profile memory and CPU usage. NetBeans 3.6 is required.
Robert Oloffson has posted version 0.43 of Java Memory Profiler (JMP). JMP uses the Java Virtual Machine Profiling Interface (JVMPI) interface to track objects and method times in a JVM. It uses a GTK+ interface to display statistics. The current instance count and the total amount of memory for each class is shown as is the total time spent in each method. This release adds method callee graph and can now group object allocations to the filtered methods only. JMP is written in C for Linux.
The Eclipse Project has posted the first milestone of Eclipse 3.1, 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. The main new features in 3.1 are Ant 1.6.2, quick fixes for serial version IDs, and some (still incomplete) support for Java 1.5.
Speaking of Eclipse, Eclipse 3.0 has recently started auto-hiding content on me. For instance, if I click ClassName.getSomething() in the Package Explorer, it only shows me that one method. The rest of the class is hidden and very hard to get back. Furthermore, sometimes when I do have the entire file displayed, and use an autofix, Eclipse promptly hides all of the class except the method I'm editing. This is very annoying. Does anyone know how to turn this behavior off? Barring that, is there a way to tell Eclipse to restore the complete class short of closing and reopening the file? There doesn't seem to be any pop-up menu item or button that does this as far as I can see. If you know how to fix this bug, please drop me a line.
Update: the probelm is solved. Thanks to everyone who wrote in. First response was Kevin Klinemeier, who noted,
The feature you're seeing is turned off by clicking on the button that looks like an 8.5x11 sheet of paper with a notecard next to it. The tooltip reads "Show Source of Selected Element Only". For me, it's the right-most button, which is wrapped onto a second line.
If you have trouble finding it, you may have removed it. Right-click your toolbar and choose to customize it. Look for this button under the "Commands" tab, in the "Editor Presentation" command group.
By the number of people who responded I'm not the only person to get caught by this. A few even sent screen shots to point out the button I had to press. This one's courtesy of Jeff Duska. The icon (a little page) has no apparent relationship to what it does. Oh wait, I get it. It's supposed to be a view (sliding window or peephole) on a page. I'm not sure a feature like this really deserves to be hidden on a toolbar, and there really does need to be an item in the context menu for "Show everything."
I'm very pleased to announce the first beta of XOM 1.0, my tree-based API for processing XML with Java. XOM emphasizes correctness, ease-of-use, and performance, in that order. It can also process documents in a streaming mode that handles documents larger than available memory. Features include XML canonicalization, XInclude resolution, and XSL transformation. XPath queries are sadly lacking. :-(
You should note that my criteria for entering beta is much stricter than most. In particular unlike some companies who shall remain nameless but who release major operating systems with thousands of known bugs, XOM Beta 1 has exactly zero known bugs. It is feature complete.
XOM has been tested in both client and server-side environments. It has been tested with a number of parsers including those bundled with Java 1.4 and 1.5. The internals of XOM have some pretty nasty hacks to work around various bugs in third party libraries it depends on, sometimes including the JDK itself. I'm fairly confident works as expected when bundled with the latest versions of Xerces and Xalan; and, aside from a few corner cases, works pretty damn well with earlier versions of these products and with other parsers and transformation engines too. (The XOM unit tests are very tough. They have exposed numerous bugs in underlying libraries over the years. I picked Xerces and Xalan because the Apache Foundation has fixed the bugs I found while working on XOM. All other parsers and transformation engines I've tested still have open bugs. Where possible, I've included code in XOM to work around known bugs, especially for processors bundled with JDKs, but it's not always been possible to do so.)
I now believe XOM to be ready for production use. Of course, I could be wrong about that, which is why there's a beta cycle. I encourage you to try out this library, and let me know of any issues that arise, be they bugs, missing documentation, or weak performance. However, omitted functionality will probably have to wait for 1.1 to be filled in. Unless new bugs are uncovered, this may be the one and only beta release. All that's left on my TODO list before final release is finishing the documentation and doing some minor code clean-ups. These include such housekeeping tasks as splitting long lines, spell checking the comments, and making sure the Javadoc is all valid XHTML. It may take a few months before I get all of this done, but none of it should have any affect on client code.
Beta 1 makes no backwards incompatible changes to the published API. Bug fixes since the final alpha include:
- The XInclude test suite is loaded and run from the W3C CVS server if it's not installed locally. Mistakes in the test suite (mostly involving document type declarations) are corrected on the fly.
- Work-arounds for various JDK bugs that prevent round-tripping of some characters in Japanese encodings
- Work-arounds for bugs in some versions of Xalan, as well for bugs in the OASIS XSLT conformance test suite.
- Improved compatibility with Java 1.5
XOM is published under the LGPL. Java 1.2 or later is required.
IBM's alphaWorks has released the Distributed Parallel Programming Environment for Java (DPPEJ). According to the web site, DPPEJ is
a set of tools and technologies for developing simple, distributed, parallel applications using the Java programming language. This project is being developed by the IBM India Software Lab.
DPPEJ includes an easy and intuitive programming model based on distributed threads; object-based, message-passing APIs; and distributable data collection. DPEEJ takes a class library-based approach to providing a distributed parallel programming environment. New classes and interfaces supporting distributed threads, message passing, and distributable data collections are included in this package.
DPPEJ consists of three major technologies:
DThread
- A group of distributed threads work in parallel on multiple distributed JVMs.
- Remote Method Invocation (RMI) is used as the underlying mechanism for distributed execution and control. Single Program Multiple Data (SPMD) distribution is currently supported. Class file migration is possible via RMI network class loading mechanism.
- New interfaces and classes for DThread are included.
Object-based message passing
- RMI-based, MPI-like messaging-passing operations
- Get, Put, Broadcast, Barrier, Multicast, Send, Receive, etc.
Distributable data collections
- Distributable data collection for int, long, float and double
- Support for familiar data-partitioning techniques.
Jim Menard has posted version 0.82 of DataVision, an open source "database reporting tool similar to Crystal Reports". DataVision is written in Java and supports multiple databases including PostgreSQL, MySQL, and Oracle. This is a bug fix release. DataVision is published under an Apache license.
IBM has posted the proposed final draft of Java Specification Request (JSR) 174, Monitoring and Management Specification for the Java Virtual Machine. In essence, this would allow external processes to hook into a virtual machine to watch over thread and memory use. According to the draft,
Modern enterprise solutions are complex and often comprise a stack of different distributed products, many of which are Java platform applications. In such an environment, the task of monitoring and managing the solution is very complex and requires a collection of probes and adapters in order to collect the necessary data.
Monitoring and understanding the overall health of the JVM is an important contributor to the management of the solution, and the monitoring should be as non-intrusive as possible in order not to alter the original characteristics of the solution.
JVM monitoring and management will be most useful in customer production environments where it will be used to gather information about the health of the JVM and the application and to dynamically select/configure data collection.
The current specification for the JVM does not include any lightweight standard interface for the monitoring of its health indicators nor for the management of some of its run-time characteristics. The main goal of this specification is to provide the necessary guidelines and recommendations for the definition of a set of APIs to enable the monitoring and management of the JVM. This specification will _not_ propose any interfaces to monitor or manage applications, nor to supply a higher level abstraction to monitoring and management. Monitoring and management intelligence shall be provided by another layer yet to be defined. The expectation is that monitoring and management intelligence shall be provided by 3rd party software vendors.
In essence, JSR174 is about the definition of the data required for the lightweight monitoring and the management of the Java virtual machine.
It's not immediately clear to me why this need isn't met by the Java Virtual Machine Profiling Interface (JVMPI); but one hopes the working group has good reasons for what they're doing.
Subversion is an open source version control system designed to replace CVS, the open source version control system we've all learned to hate. The second release candidate of Subversion 1.1.0 has been posted. "The term "release candidate" means the Subversion developers feel that this release is stable and ready for production use, so we encourage people to test this release thoroughly. The final 1.1.0 release is scheduled for mid-September, in order to provide plenty of time for testing." New features in 1.1 include:
- File system based (Non-database) repositories
- Symlink versioning
- Commandline auto-escaping of URI and IRIs
- Localized messages
ByteConsult GmbH has released nib4j 1.0.2, a $199 payware tool "that permits the use of Apple's Interface Builder to design Swing-based user interfaces. Runtime platform is Mac OS X. Cross-platform support will be included in the next major release."
David Hovemeyer has posted FindBugs 0.8.4, an automated open source tool for finding potential bugs in Java code. Since the last release I reported here, a number of new bug detectors have been added.
For a change, I tested this release on the latest XIncluder code base, which I've recently picked up again to try and get it ready for the final release of the XInclude specification, and which
I had not previously used static code checking tools on.
It found three places where a
stream that wasn't closed on all paths out of a method,
and one unused private method.
There was also a surprising report that my JUnit
test case did not call super.setUp(). Nothing in the JUnit documentation says it should. After a little research, it seems this is primarily an issue if you're only indirectly extending TestCase from one of a third party subclass, not if you're extending junit.framework.TestCase itself.
False positives were few.
Java 1.4 or later is required. FindBugs is published under the LGPL.
Novell has released Mono 1.0.1, an open source implementation of Microsoft's .NET framework that runs on Linux, Unix, Mac OS X, and Windows. Mono includes an ECMA Common Language Infrastructure (CLI) runtime engine, a cross platform IKVM Java runtime engine, a C# 1.0 compiler, class libraries implementing the .NET 1.1 profile, the Gtk# 1.0 GUI programming toolkit, GNU Classpath for the CLI and a Visual Basic runtime. Version 1.0.1 is a bug fix release. It's published under the GPL.
Sun's posted build 60 of JDK 5.0, beta 3 for those who like to live on the bleeding edge.
Apple has posted Java 1.4.2 Update 1 on Software Update and the Apple web site. This release updates the Macintosh Runtime for Java to JDK 1.4.2_05 and fixes various Mac-specific bugs. Mac OS X 10.3.4 or later is required.
Teodor Danciu's posted version 0.6.0 of JasperReports, an open source 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 0.6.0 adds batch exporters, improves SVG export, folloowsd the Java package naming conventions, and adds an XPath based XML data source.
Michael B. Allen has posted jCIFS 0.9.7,
a free (LGPL) SMB client library written in pure Java. It
supports Unicode, named pipes, batching, multiplexing I/O of threaded callers, encrypted authentication, full transactions, domain/workgroup/host/share/file enumeration, NetBIOS sockets and name services, the smb:// URL protocol handler, RAP calls, and more. The API is similar to
java.io.File. Version 0.9.7 fixes a few bugs.
J-domain has released CodePrinter 1.0.2, "a tiny utility to print out source code or other text files. Its main intent is to provide you with print-outs for your code reviews and to save some paper by fitting two code pages onto one sheet of paper. CodePrinter is written in Java and makes use of the Java Printing API." Version 1.0.2 fixes bugs with some printers. Code Printer is published under the GPL. An Eclipse plug-in is available.
Steve Roy has released MRJ Adapter 1.0.8, an open source library that implements a unified API for developers to access Mac specific functionality built into the various versions of the Macintosh Runtime for Java (MRJ). MRJ Adapter enables developers to add Mac specific functionality to their applications without compromising the cross-platform nature of their application. MRJ Adapter also "incorporates many little tricks known only to seasoned Mac Java programmers, such as how to bring up a file dialog to pick a folder, or how to set up a menu bar when no frame is opened, which is a normal state for a Mac application that isn't natively supported by Java." Version 1.0.8 is a bug fix release. MRJ Adapter is published under the LGPL.
BEA Systems, Inc. has released the final version of
Java Specification Request 94, a
Java Rule Engine API, in the Java Community Process.
"A rule engine may be viewed as a
sophisticated if/then statement interpreter. The if/then statements that are interpreted
are called rules. The if portions of rules contain conditions such as
shoppingCart.totalAmount > $100. The then portions of rules contain actions
such as recommendDiscount(5%). The inputs to a rule engine are a rule execution set
and some data objects. The outputs from a rule engine are determined by the inputs and
may include the original input data objects with possible modifications, new data
objects, and side effects such as sendMail('Thank you for shopping')."
This API describes how applications load and use rule engines.
It does not define a standard rule
description language. The zip file for the proposed final draft includes a reference implementation.
Java 1.3 or later is required.
The Apache Jakarta Project has released POI 2.5.1, an open source Java library for "manipulating various file formats based upon Microsoft's OLE 2 Compound Document format. OLE 2 Compound Document Format based files include most Microsoft Office files such as XLS and DOC." It's not immediately obvious what's changed in this release. POI is published under the Apache 2.0 license.
Sleepycat Software has released Berkeley DB Java edition 1.5.1. Berkeley DB JE is a non-relational embedded database written in Java. The data is exposed through "a Java Collections-style interface, as well as a programmatic interface similar to the Berkeley DB API." This is a bug fix release. Licensing is unclear, but it seems to be some weird form of semi-viral open source license. Java 1.4.2 or later is required.
Sun has posted the fourth proposed final draft of Java Specification Request (JSR) 200, Network Transfer Format for Java Archives. This describes the new Pack200 format for JAR archives. Sun claims compression factors of seven to nine when combined with a post-pack phase using a standard algorithm such as zip.
Apple has released Xcode 1.5 on the Apple Developer Connection (free registration required). Xcode is Apple's integrated devlopment environment for C++, Objective C, and Java. It has some nice features but I think most Mac-Java devlopers are mostly using IntelliJ IDEA or Eclipse instead. New features in this release include:
- Dead-code stripping
- Remote debugging
- Code completion for Java and AppleScript
- Support for the Subversion source-code control system
- Ant templates
- Documentation bookmarks
Sleepycat Software has released Berkeley DB Java edition 1.5.1. Berkeley DB JE is a non-relational embedded database written in Java. The data is exposed through "a Java Collections-style interface, as well as a programmatic interface similar to the Berkeley DB API." Licensing is unclear to me, but it seems to be some weird form of semi-viral open source license. 1.5.1 is a bug fix release. Java 1.4.2 or later is required.
The Big Faceless Organization has released the Big Faceless PDF Library 2.2.4, a $400 payware (more if you want support) Java class library for creating PDF documents. The $1000 Extended Edition adds the AcroForms support, digital signatures, and the ability to import and edit and existing PDF documents. Version 2.2.4 isa bug fix release. Java 1.2 or later is required.
The Apache Commons Group has released Commons BeanUtils 1.7.0. This provides some easier-to-use wrappers around Java's built-in Reflection and Introspection APIs. "This is an important service release intended to help downstream applications solve dependency issues. The distribution now contains two alternative jar sets. The all-in-one jar contains all classes. The modular jar set consists of a core jar dependent only on commons logging and an optional bean collections jar (containing classes that provide easy and efficient ways to manage collectionsof beans) which depends on commons collections 3. The core jar safely be used with either commons collections 2.x, 3.x or indeed neither."
The Jakarta Apache Project has released HTTPClient 2.0.1. According to the web page:
Although the java.net package provides basic functionality for accessing resources via HTTP, it doesn't provide the full flexibility or functionality needed by many applications. The Jakarta Commons HttpClient component seeks to fill this void by providing an efficient, up-to-date, and feature-rich package implementing the client side of the most recent HTTP standards and recommendations.... Designed for extension while providing robust support for the base HTTP protocol, the HttpClient component may be of interest to anyone building HTTP-aware client applications such as web browsers, web service clients, or systems that leverage or extend the HTTP protocol for distributed communication.
This is a bug fix release. It's published under the Apache 2.0 license.