Slashdot Mirror

I've found that XML is great for Object persistence in Java. The library to use is XStream.

The closing of Harold's article proposes a basic data format for XML. In fact, that's exactly what XStream provides out-of-the-box.

I've found that XML is great for Object persistence in Java. The library to use is XStream.

The closing of Harold's article proposes a basic data format for XML. In fact, that's exactly what XStream provides out-of-the-box.

"XML is really just data dressed up as a hooker."

--Dave Thomas

XML does suck if you stick with some of the W3C standards and common tools. Suggestions to make it less painful:

• Ditch W3C's XML Schema

  W3C Schema is painful; it forces object-oriented design concepts onto a hierarchical data model. Consider RELAX NG (an Oasis-approved standard) instead; it's delightful in comparison. Use the verbose XML syntax when communicating with the less technical - if you've seen XML before, it's pretty easy to comprehend:

  <r:optional>
  <r:element name="w3cSchemaDescription">
  <r:choice>
  <r:value>painful</r:value>
  <r:value>ugly</r:value>
  <r:value>inflexible</r:value>
  </r:choice>
  </r:element>
  </r:optional>

  Switch to the compact syntax when you're among geeks:

  element w3cSchemaDescription { "painful" | "ugly" | "inflexible" }?

  There's validation support on major platforms, and even a tool (Trang) to convert between verbose/compact formats, and output to DTD and W3C Schemas. And, if you need to specify data types, it borrows the one technology W3C Schema got right: the Datatypes library.

• Don't use the W3C DOM

  The W3C DOM attempts to be a universal API, which means it must conform to the lowest common denominator in the programming languages it targets. Consider the NodeList interface:

  interface NodeList {
  Node item(in unsigned long index);
  readonly attribute unsigned long length;
  };

  While similar to the native list/collection/array interfaces most languages provide, it's not an exact match. So, DOM implementers create an object that doesn't work quite like any other collection on the platform. In Java, this means writing:

  for(int i = 0; i < nodeList.length(); i++)
  {
  Node node = nodeList.item(i);
  // Do something with node here...
  }

  Instead of:

  for(Node node : nodeList)
  {
  // Do something with node here...
  }

  Dynamic languages allow an even more concise syntax. Consider this Ruby builder code to build a trivial XML document:

  x.date {
  x.year "2006"
  x.month "01"
  x.day "01"
  }

  I thought about writing the W3C DOM equivalent of the above, but I'm not feeling masochistic tonight. Sorry.

  The alternatives depend on your programming language, but plenty of choices exist for DOM-style traversal/manipulation.

• Forget document models entirely (maybe)

  In-memory object models of large XML document can consume a lot of resources, but often, you only need part of the data. Consider using an XMLPull or StAX parser instead. Pull means you control the document traversal, only descending into (and fully parsing) sections of the XML that are of interest. SAX based parsers have equivalent capabilities, but the programming model is uncomfortable for many developers.

  Even better, some Pull processors are wicked fast, even when using them to construct a DOM. In Winter 2006, I benchmarked an XML-heavy application, and found WoodStox to be an order of magnitude faster at constructing thousands of small DOM4J documents

"XML is really just data dressed up as a hooker."

--Dave Thomas

XML does suck if you stick with some of the W3C standards and common tools. Suggestions to make it less painful:

• Ditch W3C's XML Schema

  W3C Schema is painful; it forces object-oriented design concepts onto a hierarchical data model. Consider RELAX NG (an Oasis-approved standard) instead; it's delightful in comparison. Use the verbose XML syntax when communicating with the less technical - if you've seen XML before, it's pretty easy to comprehend:

  <r:optional>
  <r:element name="w3cSchemaDescription">
  <r:choice>
  <r:value>painful</r:value>
  <r:value>ugly</r:value>
  <r:value>inflexible</r:value>
  </r:choice>
  </r:element>
  </r:optional>

  Switch to the compact syntax when you're among geeks:

  element w3cSchemaDescription { "painful" | "ugly" | "inflexible" }?

  There's validation support on major platforms, and even a tool (Trang) to convert between verbose/compact formats, and output to DTD and W3C Schemas. And, if you need to specify data types, it borrows the one technology W3C Schema got right: the Datatypes library.

• Don't use the W3C DOM

  The W3C DOM attempts to be a universal API, which means it must conform to the lowest common denominator in the programming languages it targets. Consider the NodeList interface:

  interface NodeList {
  Node item(in unsigned long index);
  readonly attribute unsigned long length;
  };

  While similar to the native list/collection/array interfaces most languages provide, it's not an exact match. So, DOM implementers create an object that doesn't work quite like any other collection on the platform. In Java, this means writing:

  for(int i = 0; i < nodeList.length(); i++)
  {
  Node node = nodeList.item(i);
  // Do something with node here...
  }

  Instead of:

  for(Node node : nodeList)
  {
  // Do something with node here...
  }

  Dynamic languages allow an even more concise syntax. Consider this Ruby builder code to build a trivial XML document:

  x.date {
  x.year "2006"
  x.month "01"
  x.day "01"
  }

  I thought about writing the W3C DOM equivalent of the above, but I'm not feeling masochistic tonight. Sorry.

  The alternatives depend on your programming language, but plenty of choices exist for DOM-style traversal/manipulation.

• Forget document models entirely (maybe)

  In-memory object models of large XML document can consume a lot of resources, but often, you only need part of the data. Consider using an XMLPull or StAX parser instead. Pull means you control the document traversal, only descending into (and fully parsing) sections of the XML that are of interest. SAX based parsers have equivalent capabilities, but the programming model is uncomfortable for many developers.

  Even better, some Pull processors are wicked fast, even when using them to construct a DOM. In Winter 2006, I benchmarked an XML-heavy application, and found WoodStox to be an order of magnitude faster at constructing thousands of small DOM4J documents

def joinTwoWordsWithSymbol = { symbol, first, second -> first + symbol + second }
assert joinTwoWordsWithSymbol('#', 'Hello', 'World') == 'Hello#World'

def concatWords = joinTwoWordsWithSymbol.curry(' ')
assert concatWords('Hello', 'World') == 'Hello World'

def prependHello = concatWords.curry('Hello')
// def prependHello = joinTwoWordsWithSymbol.curry(' ', 'Hello')
assert prependHello('World') == 'Hello World'

And about scalability, I'm not sure if Rails is as much a problem as is Ruby. Still, people managed to build websites like Twitter and Yellow Pages on RoR, and afaik neither of them even resorted to JRuby, which on v1.0 already performs slightly better overall than Ruby 1.8 for Rails apps, and with the soon-to-be-released v1.1 shows considerable performance gains, beating even YARV (Ruby 1.9) on some specific tests.

Sun has new language for client-side scripts.. Just-so-coincidentally, Sun has had a variation of this new "language" available in your browser for a decade! It's called applets and the JRE.

Python, Ruby, JavaScript, Groovy. Whatever. Sun has a Java runtime in the browser, a sandboxed one that can only access the DOM and browser. But you still get all the Java benefits, like multithreading and bytecode compilation. And all the Java benefits, like it's implemented for IE AND Firefox on Mac, Windows, Linux and Solaris. Further, it is available under the GPL, so you can port it to any other platform.

See this web page for details of Sun's leaner faster in-browser JVM.

It can host a variety of scripting languages such as Python, Ruby and, surprise, even JavaScript, as well as a couple home-grown languages such as Groovy and the purpose built JavaFX Script

Now before you shriek in horror at the thought of a JVM running in a web browser, Sun have made a renewed commitment to the browser via the soon to be released Consumer JRE, which aims to relieve some of the bloat and provide an improved experience.

Still no official 64 bit browser plugin but the IcedTea folks are working on a substitute.

One thing I forgot to mention, if I started a project fresh today, I would seriously consider enunciate http://enunciate.codehaus.org/ or Axis2. Both seem to be a good way to easily produce a full REST stack (to fully handle get, post, put, and delete). I haven't had the chance to try either, but it's on my todo list.

I'm sorry, I got my X(insert natual element here) projects confused. I meant XStream http://xstream.codehaus.org/ not XFire. I use Castor, I just know others use XStream for the same thing I use Castor for.

Basically, if you use Castor/XStream to produce XML documents for your objects, it's dirt simple to pull in the document and use it in Flex. An example of a project where we've done exactly that is this product: http://www.mastercard.com/us/business/en/smallbiz/specialoffers/index.html

Using Firebug, you should be able to see the types of REST responses we are using in the app. They are all produced with Castor, and consumed with Flex's built-in support for HTTP and XML.

As for compatibility, last figure I heard was 93% of browsers have Flash 9. Considering included in the remaining 7 percent are mobile devices, tinfoil-hat wearers, minimalists, etc, the 93% covers most of my target audience.

When I think about it, I don't even know one scripting language which has proper kernel threads support.

I really like boo. It's a statically typed language targeting .NET, with Python-like syntax and conventions. It manages to do away with most of the type declarations through (semi-)implicit typing, and it supports "duck" typing, which is something similar to Python's object model (although, as you observe, most Python code doesn't take full advantage of its dynamic nature). Boo has access to .NET's huge object library, and of course it runs much faster than Python.

It's a pity there isn't a non-.NET version available, as it's really quite a nice language. I think it's better-suited to large-scale programming than Python, since it will catch errors like type mismatches and uninitialized variables, and it's more amenable to other kinds of static program analysis. Apart from the common library differences, Python and Boo code is very similar, so it's a short step between writing Python code and porting to Boo to make it fast (which is something like how Pyrex is typically used).

Do you mean like this?

http://grails.codehaus.org/
http://www.opensymphony.com/webwork/

JRuby is one of many languages that can be run on the JVM. It has been around since 2001 (IronRuby was announced in 2007). Jython, a Python implementation on Java, was started even earlier, in 1997. There is also Groovy and JACL and many others.

JRuby is one of many languages that can be run on the JVM. It has been around since 2001 (IronRuby was announced in 2007). Jython, a Python implementation on Java, was started even earlier, in 1997. There is also Groovy and JACL and many others.

"This idea has been around for a little while."

Several ,several whiles Even Flash wants in on the act.

OK, that's three. We've only got 197 to go. If the point of this exercise is trying to determine how many applications are being used, then from that perspective they're all instances of Firefox.

Your approach answers one particular question, how many different versions of how many different applications are we using? That obviously matters in some cases like license management, but if the question is more along the lines of "how many open-sourced applications are we running," then I don't think versioning is all that relevant.

I'm not trying to argue about what's "fair," I'm just wondering how we get to 200. Let's suppose that your company has three or four different versions of every open-sourced application running. That still works out to something like 50-70 different applications which seems to me to be pretty high number. Particularly when most anecdotal evidence suggests that open-sourced applications are a rarity in many companies. It's taken me quite a while to convince my (small business/nonprofit) clients to adopt one or two of the most commonly-used open-sourced applications like Firefox, Thunderbird, and OpenOffice.

The only way I see getting to a number like 200 is if you count *nix servers. And, then, 200 is probably too small a number especially in Linux shops.

BTW, their list of discoverable software (XLS) doesn't include any versions of Firefox before 2.0.0 and doesn't list Thunderbird at all. On the other hand, they do list a number of different versions of server software like Apache (8 versions) and MySQL (17). This tends to confirm my original conjecture that a lot of the software counted toward this 200 figure is running on servers, and yes, they're probably counting different versions as different instances. There are also a lot of packages that are likely to be relevant only to development shops. Just going through the A's and B's required me to look up some things like activemq (about 80 versions), berkano (about 100 versions), and bouncycastle (about a dozen).

So I guess I'd conclude that this product might be highly relevant to development shops and server managers, but much less relevant for determining what's running on the desktops of firms outside the IT industry.

...install X, use a terminal window and enjoy the freedom to have as many columns as you want.
Also, if you're loaded, get hold of an IBM T221 monitor and enjoy my eternal envy while you look at all your code at once :)
screenshot

Say, can I use an interpreted scripting language on the JVM? Which one would be most suited?

• Rhino Javascript engine - built in to Java SE 6
• Groovy - An agile dynamic language for the Java Platform
• BeanShell: Lightweight Scripting for Java
• The Sleep Scripting Project

We all have one, it's called Groovy - a Java-based scripting language that steal functional tricks from elsewhere.

And I can use it on any platform.

I actually really like C# as a language, but I'm one of those people that thinks strict typing makes programming easier.

That's a very interesting criticism you include about Ruby's threading model. If anything, it's a reason to move to JRuby with its much better Java threading.

Too bad GWT uses Java. I wouldn't say that Java is the easiest language to use for rapid development like web applications usually require.

Xix.

I have tried using Groovy for command line utilities and JVM performance has, in fact, been an issue. There are ways such as Nailgun for elminating JVM startup overhead, but Groovy (last I checked) doesn't provide an "out of box" solution.

Groovy and Java code can call each other. Groovy can be used in script mode or compiled to a .class file. For deployment, it's like any other Java app with the addition of a groovy jar file. The integration with Java is what separates it from other scripting languages.

The value of Groovy is mostly for Java developers. Dynamic typing, closures, dynamic code evaluation, generated getters/setters and other goodies not included with stock Java. Like other scripting languages, it contains powerful constructs to do more with less code.

I've read most of the book. Actually, it's quite good as programming books go.

Check out some of the examples. http://groovy.codehaus.org/

The reviewer is an author of several Groovy articles and has a vested interest in seeing the book succeed. How about a little objectivity and professionalism?

Performance isn't everything, but then again, when you are 400 times slower than Java..

400 times slower? Still too efficient. Consider a Ruby implementation on the JVM and multiply inefficiencies! Should be thousands of times slower for those same benchmarks.

About JRuby; Sun recently hired two (both?) of the JRuby developers and progress has accelerated. The promise is a highly capable Ruby implementation running on a JVM. This, coupled with very recent changes to the JVM to facilitate scripting languages could lead to an interesting future. Sun is also leveraging the JVM for other language projects such as Fortress.

Apparently Sun isn't content to let Microsoft's CLR become the de facto standard bytecode runtime platform. I don't know whether it's possible to make Ruby performance on the JVM competitive with native implementations, but I am hoping.

The only downside to Jira is that it's price tag (for business users) has risen steadily, but at least they've given free licenses to open source projects like Apache Software Foundation, Codehaus and JBoss.

I've also used Mercury's TestDirector, but it seems like a glorified excel-sheet when compared to JIRA. TD is more suitable for reporting bugs, and it doesn't support the software development process like JIRA does. Jira has projects, components, issue links, releases, change notes, workflows, security levels, reports and so on.

We also have an inhouse built issue tracking system. It works to some extent, but its GUI doesn't really scale to handling large number of tickets. And since it's not developed actively it will probably stay as it is for some time.

Maybe you can have a look at JRuby: http://jruby.codehaus.org/.

They aim for 100% Rails compatibility (I think they are nearly there) and there are developments to allow deployment of your rails application using Java's war web archive system to a Java application server.

You mean, things like Ruby, Python or PHP running on an open-source JVM ?

Actually, I recently stumbled upon http://grails.codehaus.org/Groovy and would like to use the occasion to ask, if it is comparable to RoR? Has anyone used it in a real project?

So exactly what other languages other than Java can I write in and have it compile into Java byte code? Last I checked it was just one.

How about Jython or JRuby

I use XStream which is very nice xml serialization utility library. XStream has very nice aliasing abilities, so you can trim the xml to very close to absolute minimum ( 2 minute tutorial).

Currently I'm planning on externalizing website validation objects as xml so they can be updated more easily and dynamically. It's basically the same thing you describe and I can easily see how it would help with GUI programming. To get around the "attaching actions to the components" problem you can use the MVC design pattern. Set the gui elements to return an event id and use a central controller class to send the event flow to the proper commands.

The XML-serialization has a few problems though:

• Versioning, what if the classes change and what if the data model changes really radically.
• XML data doesn't get refactored when you refactor your classes.
• XML data might not stay in synch with your codebase.
• The XML becomes easily convoluted and at worst you'll be coding in XML without the help of a friendly IDE.

Anyways, XSLT can be used to convert older XML formats to new format and XStream's aliasing functions helps, but you still have to be careful when making changes.

I use XStream which is very nice xml serialization utility library. XStream has very nice aliasing abilities, so you can trim the xml to very close to absolute minimum ( 2 minute tutorial).

Currently I'm planning on externalizing website validation objects as xml so they can be updated more easily and dynamically. It's basically the same thing you describe and I can easily see how it would help with GUI programming. To get around the "attaching actions to the components" problem you can use the MVC design pattern. Set the gui elements to return an event id and use a central controller class to send the event flow to the proper commands.

The XML-serialization has a few problems though:

• Versioning, what if the classes change and what if the data model changes really radically.
• XML data doesn't get refactored when you refactor your classes.
• XML data might not stay in synch with your codebase.
• The XML becomes easily convoluted and at worst you'll be coding in XML without the help of a friendly IDE.

Anyways, XSLT can be used to convert older XML formats to new format and XStream's aliasing functions helps, but you still have to be careful when making changes.

So take a look at Groovy. Closures(with curry and all) and one have no more excuses for not use java.
While you are at it check out grails.
It is like ruby on rails, only for java.
Hope you find it useful.
Marcolinux

So take a look at Groovy. Closures(with curry and all) and one have no more excuses for not use java.
While you are at it check out grails.
It is like ruby on rails, only for java.
Hope you find it useful.
Marcolinux

Is it possible to at least snapshot the legacy stuff into CVS? I have found that even snapshotting the rolled out tree can help in emergencies.
Also, for the projects you do have in CVS, I found CVS SPAM is a life saver, it was probably the most important coordinating tool we had on a project with 10 or so geographically (and "working hours"-ly) dispersed developers. I did a separate distribution list for each project. It seemed to help team morale during tough times eg, when people would add humorous check in notes at 3 AM, etc.
The problem is if management gets wind of it and wants to be on the notification list and then does stupid shit like trying to infer productivity based on checkins - but they can do that with any CVS stats tool. Used fisheye while it was in beta, but it is $ - I was surprised though, for a Java program it worked well with mercifully near zero conf...

BTW, Damage Control was on its way to becoming a gorgeous thing - A Ruby on Rails of the continuous build/integration world - I wish google would pay them to re-activate the dev on it.
Of course, for you ANT/Maven (the Horror, the Horror) types, there is CruiseControl and others... CB/I Matrix

Is it possible to at least snapshot the legacy stuff into CVS? I have found that even snapshotting the rolled out tree can help in emergencies.
Also, for the projects you do have in CVS, I found CVS SPAM is a life saver, it was probably the most important coordinating tool we had on a project with 10 or so geographically (and "working hours"-ly) dispersed developers. I did a separate distribution list for each project. It seemed to help team morale during tough times eg, when people would add humorous check in notes at 3 AM, etc.
The problem is if management gets wind of it and wants to be on the notification list and then does stupid shit like trying to infer productivity based on checkins - but they can do that with any CVS stats tool. Used fisheye while it was in beta, but it is $ - I was surprised though, for a Java program it worked well with mercifully near zero conf...

BTW, Damage Control was on its way to becoming a gorgeous thing - A Ruby on Rails of the continuous build/integration world - I wish google would pay them to re-activate the dev on it.
Of course, for you ANT/Maven (the Horror, the Horror) types, there is CruiseControl and others... CB/I Matrix

If you're a Java developer, check out Groovy and Grails. It integrates much more tightly with existing Java code rather than redoing everything in Ruby.

See also this post: http://www.infoq.com/news/jruby-groovy-next

If you're a Java developer, check out Groovy and Grails. It integrates much more tightly with existing Java code rather than redoing everything in Ruby.

See also this post: http://www.infoq.com/news/jruby-groovy-next

eventually someone will even port ActiveRecord to JRuby

I was under the impression ActiveRecord already worked under JRuby? After all, Camping apparently works under JRuby and it uses ActiveRecord. The tutorial speaks of something about JDBC.

Okay, so it may not work to really useful extent yet, and I hear Rails definitely won't work yet, but it's probably a start...

Except it clearly states on the homepage - "Distributed under a tri-license (CPL/GPL/LGPL)".
http://jruby.codehaus.org/

I actually find the multi-language of of the CLR to be a negative. I work at a fortune 500 and most of us use C# and/or Java. There are a few groups of "programmers" that have always been VB-only/ASP-Only "programmers". They have really no understanding of programming maintainable code.

I'm not sure I follow your logic... How would forcing your poor programmers to switch languages make them better programmers? I think the best that you could hope for is that they'd still be poor programmers, just in a different language.

Besides, the Java Virtual Machine has just as many, if not more lanugages available for it than the CLR. (Note that I said "available" not "supported.")

IronPython has big shortcomings such as it is unable to blend well with .NET assemblies built with another language.
Also it doesn't use much of the niceties available through the .NET Framework...

If you like Python syntax and want to try .NET (on win32 or on linux with Mono), check out the Boo language, the wrist-friendly language for the CLI.
It is amazing!! => "while using a Python-inspired syntax and a special focus on language and compiler extensibility. Some features of note include type inference, generators, multimethods, optional duck typing, macros, true closures, currying, and first class functions."

And last but not least, Boo's licence is BSD, not a crappy Shared Source something!!

Full description: http://en.wikipedia.org/wiki/Boo_programming_langu age

Official website: http://boo.codehaus.org/

http://boo.codehaus.org/

tell you what..build me a windows forms app with vi and I'll use VS.net

I'm not actually opposed to GUI based forms designers, or to code generation suites where the problem is well understood. I just don't think that this functionality is best provided by embedding it into my favourite text editor. That's the point you see - to have lots of separate tools that can be combined flexibly, rather than a single monolithic tool that embodies the design time assumptions of the lead developer.

...and I'll do it 10 times better in 1/10th the time as you.

You might be surprised. I've recently looked at some of the code that VS2003 generates and it's pretty pedestrian stuff. That's forgivable from generated code, but you don't have to do it like that. I reckon I could write a shell tool to generate equivalent code from user defined text file. There are a couple of framework approaches I think would take the pain out of forms writing as well. I've done it before in other environments.

Give me a fucking break....vi....

Here's a challenge for you: why don't you go and write me a chat server in Boo using VS 2003. I'll have mine written and tested using vi before you're done writing the necessary plug-in. Oh, and I expect it work on Linux under Mono as well as Windows with .NET

Have fun!

I think Sourceforge needs to improve their quality if they are going to remain as central as they have been for open/free software development. There exists many alternatives these days, JForge for instance, or java.net, Codehaus...

I have a collegue who is one of the submittors to JRuby. He told me they had huge problems with Sourceforge last 6 months. Servers were down all the time, which slowed down development. I blieve they almost didn't get the demo finished before Java ONE because of this, and now they have moved to CodeHaus instead. Subversion, JIRA for bug tracking, and so far very stable servers, so they are very pleased.

Agree, that's why I like languages like Boo that uses type inference most of the time, but you also have the option of using duck typing.