[jdom-interest] JDom and Java5

[Rolf]

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.
>
> /Mattias
>
> _______________________________________________
> To control your jdom-interest membership:
> http://www.jdom.org/mailman/options/jdom-interest/youraddr@yourhost.com
>


Hi Mattais, All.

I think for the moment I am content to leave it alone as a path of least 
resistance.

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 
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!

Thanks

Rolf

P.S. Jason, it's been awfully quiet from your end, everything OK?