[jdom-interest] JDom and Java5
jdom at tuis.net
Tue Feb 26 17:55:41 PST 2008
Mattias Jiderhamn wrote:
> Victor Toni wrote (2008-02-26 19:31):
>> Mattias Jiderhamn wrote:
>>> Rolf Lear wrote (2008-02-26 16:16):
>>>> ... the @suppress would remove the warning like you said.
>>>> Unfortunately, I don't believe that is enough for an API.
>>> (Would you care to explain why compiler warnings must be avoided at
>>> all costs?)
>> "Avoiding warnings at all costs" sounds a bit strong. When writing a
>> new API (library, whatever) it's not alway possible to create
>> warning-less code.
>> In these cases I tend to inspect the code section thoroughly and add
>> such annotations if possible. It gives a warm fuzzy feeling if the
>> counter goes down ;-)
>> And it saves time because 3 months later I don't have to check the
>> same code again to see if it's just a warning or maybe a WARNING.
> Yes, I agree on the @Suppress, but as I read Rolfs comment it is not
> enought to suppress the warning but we should aims to remove the cause
> of it. It almost seems like he is willing to adjust the external
> interface in order to avoid compiler warnings. I am not used to such
> an approach.
> To control your jdom-interest membership:
Hi Mattais, All.
I think for the moment I am content to leave it alone as a path of least
Just to put things in perspective, I have spent some time on this Java5
port but it is really just a 'pilot project' which I used as a 'useful
and real' excercise to learn Generics and other Java5 Constructs. I work
in the finance industry and there has not been a whole lot of drive to
'fix things that aren't broke', but I need to keep current too...
Ideally I think it would be best to fix the XPath foundation. Michael
Kay has made reference to a new XPath version that maybe should be
considered though I know very little about it. This would inevitably be
a long term undertaking though.
On the other hand, I think it would also be a *very good* solution to
leave the method with a return type of List<?> because, as far as I can
tell, it is fully compile-time backward-compatible with existing code,
and it conveys the meaning of the data accurately, i.e. that there is a
list of objects of unknown type returned. The user of the API will
expect to have to figure things out for themselves, and will have to
deal with the compiler warnings, etc. While what I have done with JDom
has been on my own time, my employer uses JDom in some applications, and
like many big employers, I am sure would be far more receptive to
migrate to 'JDom2' if the migration was 'seamless'.
On the other hand, I feel that *IF* we make the return type more
specific using generics, like somehow List<Element> or whatever, then we
have to make 100% sure that we return what we say we do so that people
don't fall in to an unexpected trap.
There is another issue to deal with. I am in no way an 'official'
representative of JDom, just a person who has made contributions in the
past, and took on a Java5 port as a useful excercise. At some point real
soon the official maintainers of JDom (Jason) is/are going to have to
weigh in with his/their opinion on the whole process. Based on previous
postings of Jason's, I get the impression that Jason is somewhat
reluctant to maintain two JDom code bases (the current build compatible
back to Java1.2) and the 'new' build. Whatever happens we will need to
convince Jason to do something with it... but, I imagine that the more
interest people show the more likely we will get his attention on this.
To re-iterate, 'my' port is only supposed to be a proof of concept and a
potential starting point for a possible formal port. Right now we are
just a bunch of interested people with some time on our hands... and we
are kicking around some ideas.
Finally, I am somewhat concerned by the tight focus on essentially a
single method in the API. Has anyone got any feedback on the utility of
the rest of the API? Victor has mentioned concerns with the Filter API,
and I am learning some more based on his suggestions, but, for the most
part, I would find it much easier to work of real working code.... hint
So, is there any more feedback on the port as it is right now?
As an administrative matter, I 'ported' the entire set of JDom CVS
repositories to my home server, and, being somewhat security conscious,
it is read only. This essentially makes me a de-facto gate-keeper of
checkins to this repo (although, git users will have no issue with
that....). I don't want people to think this is a major barrier though
to get to the code. If there is something better than what's there, then
send me or the list the code, and I will check it in.
I am going to give the selectNodes issue a rest for the next short while
and see if I can understand the Filter stuff, but, if anyone wants to
work on the selectNodes then feel free!
P.S. Jason, it's been awfully quiet from your end, everything OK?
More information about the jdom-interest