[jdom-interest] JDOM and memory

[Rolf Lear]

Yes, it is useful.

XOM has nice features, and a lot of that comes from being able to look
back on things with hindsight.... which is a big advantage.

JDOM is not XOM though, and JDOM carries a legacy which is both an
advantage and a disadvantage.

In the past (before I took on JDOM2) I have looked in to XOM, and, having
been a JDOM user I could not personally justify the 'cost' of learning yet
another API that accomplished the same function as JDOM.... it would
require a new jar to deploy, new learning, etc. I can see that someone new
to Java/XML would find XOM appealing... but is it really as good as it
claims? It is hard to tell. What XOM claims to be fluff, others claim to be
useful. What is interesting is reading the list of 'design principles' that
I mostly agree with.... but also some that I don't. 

Now that I know more about JDOM it is interesting to realize that before I
decided to commit myself to JDOM2, one of the considerations I had was
'should I use some other library, or should I make JDOM2 better?' I
investigated XOM then, and decided it was not 'nice', and that I 'prefer'
JDOM. I don't think I am alone in that logical thinking. (I also looked in
to dom4j, DOM, etc.). I did not just 'decide' to do JDOM2, it really is my
belief that all the other libraries are 'behind the curve' when it comes to
usability in the Java5+ world. 

Fundamentally though, I have to change in JDOM what makes sense to change
while taking in to consideration the legacy of JDOM. I think the new
generics application in JDOM2 is very successful from a usability point of
view, and also very compatible with legacy code. It is a 'win'. I don't
think I can agree with Elliotte's comments about the generics
implementation in the Collections API being so broken that it is not worth
using in the XOM API. Not having a List API is one of the big reasons I
didn't try XOM in the past.

So, in the context of this particular mail thread, I strongly believe that
JDOM is doing the right thing by using the List API, and that the
COntentList is a good concept. It is just memeory hungry, and I have make
one failed attempt to make it better. I think the next version will be
right. But removing the List API entirely is a 'bad idea'.

In general I am very happy to borrow good concepts from places, for
example, I specifically looked at how XOM does the XPath implementation,
and was suprised at how minimalist it is. So minimalist that it does not
support the full specification... it simply does not support variables... 

Anyway, I think on the whole that JDOM has a reasonable balance between
being comprehensive and being usable. The API on the whole is well
mannered, and in the JDOM2 work I have done I have changed very little of
the API (other than the XPath stuff). It is all functionally compatible
with 1.x, and while there are small deviations at the technical level they
are all 'replacements' (e.g. using enums instead of int-constants).

Regardless, XOM provides a good comparison of functionality.... and a good
measure of what's right and wrong - at least for the aspects that I have
'checked out'.

I am rambling. If you have any particular concepts in XOM (or any other
library) that you like you should point them out!

Rolf



On Mon, 23 Jan 2012 09:23:36 -0800, Joe Bowbeer <joe.bowbeer at gmail.com>
wrote:
> It may be useful to compare and contrast with XOM?
> 
> http://xom.nu/designprinciples.xhtml#d0e389
> 
> On Mon, Jan 23, 2012 at 9:04 AM, Rolf Lear wrote:
> 
>>
>> Heh... you are right.
>>
>> Element should not be List<Content>, and the getContent() method can
>> create a dynamic implementation as needed. That's the solution...
Element
>> already has rules about synchronization so multiple 'active' dynamic
>> instances should not be a problem....
>>
>> Thanks. I will play with that concept.
>>
>> Rolf
>>