Posts Tagged ‘ OpenSource ’

XStream roadmap: What do YOU want to see?

I’m assessing where the next version of XStream should go. There are three major chunks of work I’d like to tackle (described below), however I can only take on one at a time and need to prioritize.

What do you want to see? Leave your comments on my blog.

1. Full support for the Java serialization specification.

Current situation: XStream uses reflection to access an objects fields and convert them to and from XML.

Problem: While this works well with most custom objects, there are many classes (particularly in the standard java and javax packages) that rely on advanced features of the serialization API, by implementing the methods, readObject(), writeObject(), writeReplace() or the methods found in java.io.Externalizable.

Solution: The default Converter in XStream could be enhanced to support these features.

Outcome: XStream should be able to serialize any object that standard Java serialization can, without any modifications.

2. Improved JVM support.

Current situation: XStream uses reflection to instantiate objects when deserializing. Using plain reflection, this requires each object to have a default constructor, which XStream will call. An ‘enhanced-mode’ is also supported that uses JVM specific calls to construct objects without ever invoking a constructor, guaranteeing no side-effects.

Problem: Currently the ‘enhanced-mode’ is only available if using the Sun 1.4 JVM or later.

Solution: Enhance the enhanced mode to support more popular JVMs, including Sun 1.3, IBM 1.4, and JRockit.

Outcome: More users can use XStream without having to make intrusive modifications to their classes.

3. Configurable mappings.

Current situation: XStream was originally designed as a tool for transparent serialization of objects (specifically for persistence or to send across the wire in messaging systems). As such, the goal was to allow XStream to figure out what the XML should look like on the fly, without forcing the mappings to be defined for each class.

Problem: An unforseen popular usage of XStream is for assembling objects from XML configuration files. However, because XStream has been designed to just figure out the XML on the fly, it does not allow users to (easily) specify their own XML structure.

Solution: To add more simple to use ‘tweaks’ to the generated XML. For example, to allow attributes to be used in some elements, alias elements based on where they appear or remove redundant tags to make the XML easier to understand.

Outcome: More flexibility for the resulting XML, without forcing users to write custom converters.

2004
08/07
CATEGORY
Software
TAGS


13 comments

XStream 1.0.2 released

Changes:

* Many more converters for common Java types.
* Fields of type byte[] are now encoded using Base64.
* Improved support for using XStream in environments where classes are hot-redeployed.
* More…

Download: Full distribution or Jar only

xstream.codehaus.org

2004
08/07
CATEGORY
Software
TAGS



Comments Off on XStream 1.0.2 released

SiteMesh 2.1 released

SiteMesh 2.1 has been released. The main changes in this release:

* Out-of-the-box support for writing decorators in Velocity.
* Performance improvements.
* Numerous bug-fixes, particularly container-specific issues.

Read an introduction and then download.

http://www.opensymphony.com/sitemesh/

2004
08/03
CATEGORY
Software
TAGS



Comments Off on SiteMesh 2.1 released

Announcing XStream: Java to XML serialization, and back again.

XStream is a simple library to serialize objects to XML and back again.

Features

  • Ease of use. A high level facade is supplied that simplifies common use cases.
  • No mappings required. Custom objects can be serialized without need for specifying mappings.
  • Performance. Speed and low memory footprint are a crucial part of the design, making it suitable for large object graphs or systems with high message throughput.
  • Clean XML. No information is duplicated that can be obtained via reflection. This results in XML that is easier to read for humans and more compact than native Java serialization.
  • Requires no modifications to objects. Serializes internal fields, including private and final. Supports non-public and inner classes. Classes are not required to have default constructor.
  • Full object graph support. Duplicate references encountered in the object-model will be maintained. Supports circular references.
  • Integrates with other XML APIs. By implementing an interface, XStream can serialize directly to/from any tree structure (not just XML).
  • Customizable conversion stategies. Strategies can be registered allowing customization of how particular types are represented as XML.
  • Error messages. When an exception occurs due to malformed XML, detailed diagnostics are provided to help isolate and fix the problem.

http://xstream.codehaus.org/

2004
05/14
CATEGORY
Software
TAGS



2 comments

What’s a YAUL? Or a YAUC?

Hani has a very valid post about util libraries.

Libraries that just have a bunch of non focussed utils in them, rarely provide a benefit to anyone other than the original authors.

When developers are looking into using a third party library, it is for a specific reason. A library that has a specific focus may meet this requirement, whereas an all-purpose util library rarely will (and even if it does, it is unlikely that it will be found).

Much of the code within the library may serve little purpose outside the context of the application it was originally built for, but not necessarily all.

By identifying the code within that has defined focus, you can extract that out and provide a library with a specific purpose.

Example

Whilst developing many parts of OpenSymphony (and our own bespoke applications that use OpenSymphony), we noticed there were many odd little methods that we found useful, which lead to the conclusion that other people would also find them useful. We slapped them together into a util library and OSCore was born.

This library lacked a clear responsiblity and in the end became a dumping ground for code that didn’t seem to belong elsewhere. As a consequence, it wasn’t successful. No one is going to choose to use a library that does this, that, a bit of this and has that really useful method there.

Eventually this was learned and the one part of the library that had a clearly defined use (PropertySet) was split out into its own project. Today, PropertySet is a well used library, whereas the rest of OSCore has faded into the background.

Incidently, this is a lesson we learned early on in OpenSymphony and the result has been many quality components since, many of which I rely on today.

YAUCs

As well as libraries, this also applies to individual classes. A class named CheeseUtil express very little about the focus of the class other than it’s got something to do with cheese. As a result util classes often grow fairly big and lack clear design (in fact, they often end up as a bunch of public static methods).

In this case a util class can be refactored into many smaller classes which can each flourish on their own, with their own design.

YAUC Example

In OSCore there’s a class called XMLUtils.

From the JavaDoc:

XMLUtils is a bunch of quick access utility methods to common XML operations.

These include:

* Parsing XML stream into org.w3c.dom.Document.
* Creating blank Documents.
* Serializing (pretty-printing) Document back to XML stream.
* Extracting nodes using X-Path expressions.
* Cloning nodes.
* Performing XSL transformations.

Authors: Joe Walnes, Hani Suleiman :)

Unless someone had specifically looked at the JavaDoc or methods of every single class in the system, there would be little chance of knowing that.

Breaking this class up into many smaller classes, errm, objects such as XMLParserFacade, XMLPrettyPrinter, NodeCloner, XPathEvaluator and XSLTransformere, expresses the intent clearer and is much more likely to be found.

(Hani and I have since learned from these mistakes).

h4. Conclusion

Small and clearly defined responsibilities for libraries and individual classes results in improved reuse as they have an increased chance of meeting part of a developer’s requirement.

2004
01/10
CATEGORY
Software
TAGS


3 comments

When simplicity backfires

I put a lot of effort into refactoring a larger, more complicated library into the lean and simple Squiggle you see today.

Annoyingly…

bq. Freshmeat tries to avoid listing projects which fall below a certain level of size and/or complexity, and yours is unfortunately a bit too simple for our application index. Your contribution has been respectfully declined.

2004
01/08
CATEGORY
Software
TAGS




7 comments

Easily build complicated SELECT statements with Squiggle

After serving me loyally for four years, I’ve finally got around to open-sourcing Squiggle – a small Java library for dynamically building complicated SQL SELECT statements.

Sometimes (not often these days) you just need to get your hands dirty and write a beastly SELECT statement. Maybe a persistence layer is deemed overkill for your application, or maybe a persistence layer is struggling with the type of query you want to do. There are times when writing some SQL is the right thing to do.

Here’s the blurb from the website:

Squiggle does one thing and only one thing. It generates SELECT statements based on criteria you give it. It’s sweet spot is for applications that need to build up complicated queries with criteria that changes at runtime. Ordinarily it can be quite painful to figure out how to build this string. Squiggle takes much of this pain away.

The code for Squiggle is intentionally clean and simple. Rather than provide support for every thing you could ever do with SQL, it provides support for the most common situations and allows you to easily modify the source to suit your needs.

Features

* Concise and intuitive API.
* Simple code, so easy to customize.
* No dependencies on classes outside of JDK1.2.
* Small, lightweight, fast.
* Generates clean SQL designed that is very human readable.
* Supports joins and sub-selects.

Here’s a very simple example:

Table people = new Table("people");

SelectQuery select = new SelectQuery(people);

select.addColumn(people, "firstname");
select.addColumn(people, "lastname");

select.addOrder(people, "age", Order.DECENDING);

System.out.println(select);

Which produces:

SELECT
people.firstname ,
people.lastname
FROM
people
ORDER BY
people.age DESC

Go check out the website and two minute tutorial.

2004
01/08
CATEGORY
Software
TAGS



17 comments

Java Open Source Programming book biled

Well I knew eventually the book would be biled.

While I usually find negative feedback very helpful (thanks Werner!), I feel that Hani’s review has unfortunately missed the point of the book.

The book is based around the theme of improving development productivity and the quality of real world systems through simplifying code. Whereas many other books on the shelves at the moment are ‘bibles’ that provide a comprehensive in-depth guide to specific technologies, this book tries to do something different by illustrating how using some simple tools and design techniques you can stay on top of development. Admittedly, the title of the book doesn’t convey this – I hope that really isn’t a reason to read the book.

The simplicity expressed in the JUnit and mock objects chapters was exactly what we were trying to get across to the reader. Rather than providing a brute-force approach to testing complicated applications by using tools equally as complicated, we advocate simplifying the design of applications.

Through using techniques such as test driven development (though not exclusively), you are driven towards this simpler design. Rather than show how you can use mock objects to test complicated things like environment, resources and complicated dependencies, we show how you can alter the design of your code so these complexities are encapsulated behind simpler abstractions. The examples used in many of the chapters are not much simpler than those used in my real applications at work – and I don’t write pet stores for a living ;).

There are also books that go into the theory behind simpler design, we try and make it more concrete by showing how you can make these kind of abstractions with technologies that are common in the Java development community. We often promote the use of one technology over the other (for example WebWork over Struts or Hibernate over CMP) because these are more geared towards simplicity and abstraction. In these cases we often summarise the key differences between these technologies. That’s not to say that this book is useless to you if you are not using these technologies as the simplicity we illustrate is beneficial in many kinds of application development.

Even if you are familiar with (or choose not to use) the technologies explained in first half of this book, the second half really captures what we are trying to get across. It illustrates by example how the technologies and techniques come together in many small steps, creating a system that can evolve, scale and has a high quality of design.

One of the most challenging tasks of writing a book is putting yourself in the mind of the reader audience. Some content may be obvious to some people. Some people may find none of it useful. Our aim is for most people to find most of it useful, which as Hani has made clear, unfortunately means most people find some of it completely useless.

If Hani’s review has put you off from reading the book, please take time to look at some other reviews (positive and negative) and remember that Hani’s view more-often-than-not skips over the positive aspects of something he is critiquing.

2004
01/05
CATEGORY
Software
TAGS



4 comments

XStream 0.2 released

See this.

2003
11/30
CATEGORY
Software
TAGS



9 comments

Java Open Source Programming book reviewed on TheServerSide

Dion Almaer has reviewed our book:

* Full review
* Discuss the review

I’m glad he picked up on many of the points we tried to emphasise to make the book stand out from the crowd.

2003
11/30
CATEGORY
Software
TAGS


1 comment