Java 5 planning

[jhunter]

First off, I want to thank Rolf for investing his time in exploring the
technical feasibility of a JDOM migration to a Java 5 baseline.  A few
other people have explored the area in the past as well, and it feels
like (especially with JDOM 1.1 now finished) we can look at this in earnest.

What I'd like to do here is take a high level view and ask some
questions of our local Java 5 porting experts -- Rolf, Mattias, Victor,
Gregor, and any others with experience porting widely-adopted projects
to Java 5.

1. I think we can all agree the ideal scenario is to develop a drop-in
replacement, a new JAR which (so long as you're on Java 5+) would let
previously compiled code continue to work.  This would let us continue
development as usual with a new release (call it 1.2 or 1.5 or 2.0)
simply having a higher Java version requirement.  How far can we go down
the road of embracing Java 5 while still maintaining this?

2. A less ideal scenario would require any previously compiled code to
be recompiled against the new JAR, but wouldn't require any code
changes.  This will cause some confusion and effort but to an acceptably
small amount.  Rolf, you say your build requires a recompile and in 99%
of cases doesn't require code changes.  Where are the gaps?  Can they be
filled?

3. The fallback scenario is one where people will need to modify
existing code in order to use the new version.  This will cause some
pain, and should we follow this path I think we should look at what
steps we can take to mitigate it.  Automated upgrade scripts?  A new
package, like org.jdom5, so people can choose to use the old version or
the new?  Other possibilities?

4. Lastly, I'd like to hear from people on what specific advantages
they're looking for in an upgrade to a Java 5 baseline.

My answers:

I'll start with (4) because you need to know why before you know how.  I
think people would most like to improve the return values of methods to
be more specific.  For example, getChild() should return Element,
getChildren() should return List<Element>, text.getParent() should
return Element, doctype.getParent() should return Document, and so on.
Are there other "big ticket" items?

On (1) I suspect that without a source recompile we can't adjust the
method return types which is the core value of the upgrade.

On (2) from Rolf's README it looks like there are two areas likely to
require code changes based on his port: the Filter.filter() change and
the AttributeType enum.  Both seem like things to do if you're already
requiring code changes but aren't things so valuable in and of
themselves that we should require people do a code change.  Are there more?

-jh-

_______________________________________________
To control your jdom-interest membership:
http://www.jdom.org/mailman/options/jdom-interest/youraddr@...

[Victor Toni]

Personally I would like a three stage approach:

Stage 1:
Make Java 5 the baseline and clean up code:
- Currently there is code e.g. in org.jdom.adapters.JAXPDOMAdapter
which has checks for JAXP versions. We could try to get rid off as many
special cases as possible.
- Convert all StringBuffer to StringBuilder.
- Change internal collections to Generics
- Clean up JavaDoc etc.

This should give a good starting point for further modifications.

Stage 2:
Try to implement Generics for "visible" part of the API. There are some
points needing to be clarified on how to apply Generics.
Which interfaces/classes should be generified and how far e.g. what
about Element<A extends Attribute> etc.

Stage 3:
This stage should be used for more radical changes.
One change I would like to see implemented would be transactional
behavior. Currently collections e.g. of Attributes or Content are added
until an error occurs leaving the model in an inconsistent state.
These checks should happen before insertion. Collections of Content are
somehow trivial to validate. Collections of Attribute are more complex.

Adding support for XPath 2.0 / replacing the current XPath
implementation as suggested by Michael Kay.
Maybe he could give some insight since he has written some great
software on this matter.

Kindest regards,
Victor

Jason Hunter wrote:

> First off, I want to thank Rolf for investing his time in exploring
> the technical feasibility of a JDOM migration to a Java 5 baseline.  A
> few other people have explored the area in the past as well, and it
> feels like (especially with JDOM 1.1 now finished) we can look at this
> in earnest.
>
> What I'd like to do here is take a high level view and ask some
> questions of our local Java 5 porting experts -- Rolf, Mattias,
> Victor, Gregor, and any others with experience porting widely-adopted
> projects to Java 5.
>
> 1. I think we can all agree the ideal scenario is to develop a drop-in
> replacement, a new JAR which (so long as you're on Java 5+) would let
> previously compiled code continue to work.  This would let us continue
> development as usual with a new release (call it 1.2 or 1.5 or 2.0)
> simply having a higher Java version requirement.  How far can we go
> down the road of embracing Java 5 while still maintaining this?
>
> 2. A less ideal scenario would require any previously compiled code to
> be recompiled against the new JAR, but wouldn't require any code
> changes.  This will cause some confusion and effort but to an
> acceptably small amount.  Rolf, you say your build requires a
> recompile and in 99% of cases doesn't require code changes.  Where are
> the gaps?  Can they be filled?
>
> 3. The fallback scenario is one where people will need to modify
> existing code in order to use the new version.  This will cause some
> pain, and should we follow this path I think we should look at what
> steps we can take to mitigate it.  Automated upgrade scripts?  A new
> package, like org.jdom5, so people can choose to use the old version
> or the new?  Other possibilities?
>
> 4. Lastly, I'd like to hear from people on what specific advantages
> they're looking for in an upgrade to a Java 5 baseline.
>
> My answers:
>
> I'll start with (4) because you need to know why before you know how.  
> I think people would most like to improve the return values of methods
> to be more specific.  For example, getChild() should return Element,
> getChildren() should return List<Element>, text.getParent() should
> return Element, doctype.getParent() should return Document, and so on.
> Are there other "big ticket" items?
>
> On (1) I suspect that without a source recompile we can't adjust the
> method return types which is the core value of the upgrade.
>
> On (2) from Rolf's README it looks like there are two areas likely to
> require code changes based on his port: the Filter.filter() change and
> the AttributeType enum.  Both seem like things to do if you're already
> requiring code changes but aren't things so valuable in and of
> themselves that we should require people do a code change.  Are there
> more?
>
> -jh-
>

_______________________________________________
To control your jdom-interest membership:
http://www.jdom.org/mailman/options/jdom-interest/youraddr@...

[Rolf Lear-2]

Hi Jason, All.

Jason Hunter wrote:
> First off, I want to thank Rolf for investing his time in exploring
> the technical feasibility of a JDOM migration to a Java 5 baseline.  A
> few other people have explored the area in the past as well, and it
> feels like (especially with JDOM 1.1 now finished) we can look at this
> in earnest.
You're welcome.

> What I'd like to do here is take a high level view and ask some
> questions of our local Java 5 porting experts -- Rolf, Mattias,
> Victor, Gregor, and any others with experience porting widely-adopted
> projects to Java 5.
>
> 1. I think we can all agree the ideal scenario is to develop a drop-in
> replacement, a new JAR which (so long as you're on Java 5+) would let
> previously compiled code continue to work.  This would let us continue
> development as usual with a new release (call it 1.2 or 1.5 or 2.0)
> simply having a higher Java version requirement.  How far can we go
> down the road of embracing Java 5 while still maintaining this?
>
> 2. A less ideal scenario would require any previously compiled code to
> be recompiled against the new JAR, but wouldn't require any code
> changes.  This will cause some confusion and effort but to an
> acceptably small amount.  Rolf, you say your build requires a
> recompile and in 99% of cases doesn't require code changes.  Where are
> the gaps?  Can they be filled?
>
> 3. The fallback scenario is one where people will need to modify
> existing code in order to use the new version.  This will cause some
> pain, and should we follow this path I think we should look at what
> steps we can take to mitigate it.  Automated upgrade scripts?  A new
> package, like org.jdom5, so people can choose to use the old version
> or the new?  Other possibilities?
>
> 4. Lastly, I'd like to hear from people on what specific advantages
> they're looking for in an upgrade to a Java 5 baseline.
>
> My answers:
>
> I'll start with (4) because you need to know why before you know how.  
> I think people would most like to improve the return values of methods
> to be more specific.  For example, getChild() should return Element,
> getChildren() should return List<Element>, text.getParent() should
> return Element, doctype.getParent() should return Document, and so on.
> Are there other "big ticket" items?
>
> On (1) I suspect that without a source recompile we can't adjust the
> method return types which is the core value of the upgrade.
>
> On (2) from Rolf's README it looks like there are two areas likely to
> require code changes based on his port: the Filter.filter() change and
> the AttributeType enum.  Both seem like things to do if you're already
> requiring code changes but aren't things so valuable in and of
> themselves that we should require people do a code change.  Are there
> more?
>
> -jh-
>

My answers, also starting with 4:

4a. For me the biggest advantage of a Java5 baseline is to reduce
"compiler warnings". I rely on strict rules in the Eclipse development
environment that do everything from ensuring that all method parameters
are documented in the JavaDoc tags, ensure that methods that are
overridden have the @Override annotation, etc. This leads to code which
is well structured, and complete. My 'lint checking' in eclipse is more
pedantic than the warnings generated from just the javac compiler. By
porting JDom to Java5 I can *correctly* eliminate many warnings in my
code, and this improves the signal-to-noise ratio in the code problems.
I feel that it is important to be able to compile code without compiler
warnings. Other people have different programming styles, but for me, a
good Java5 port of JDom will make my life 'cleaner'.

4b. The next advantage is to be able to use the generic return types of
methods to 'simplify' the code readability. Let's face it, "for (Element
kid : root.getChildren()) {...}" is just so simple.

1. While I agree that a pure drop-in replacement jar would be ideal, I
think too much would be compromised to get there. Looking at my
prototype port, I imagine it could potentially be done, but then the
AttributeType ENUM would have to be reverted. This is not actually a
"big deal" I guess, using String constants is not bad, and I only used
Enum because it is 'cool'. I think there may be other issues though...
the change I made to 'Filter' class would require a recompile because I
changed a method signature from accepting Object to accepting
Content.... this would not work with a drop-in replacement. So, I think
it *may* be possible, but unlikely. There may be more effort spent
building a compromised product to accomplish a lofty goal which, for me,
seems unnecessary.

2. This is the approach I aimed for... make the migration simple, and a
recompile will do. There are some issues in the prototype that may/will
cause issues:
- I changed a couple of method signatures have parameters that were more
closely typed than JDom 1.1, like the Filter class above, where I take a
Content parameter instead of an Object. In JDom1.1 it would not have
made sense to send in non-Content data anyway, but it would have
complied. With the prototype, it will not compile. As a result of this
same change, it is now no longer possible to build a filter which
returns Document... but, is there anyone out there who has a use case
for that? JDom 1.1 had reference in the JavaDoc for the Filter class
that you could build a filter that matches Document objects, but I could
not think of a use case, and I 'needed' to have a Content input type,
not Object, so I decided to drop support for it. This may cause compile
problems for a small fraction of people.
- Some people may have specific references to Attribute Types that in
JDom1.1 are String values... think along the lines of someone having the
following in their code: String attype = Attribute.ID_TYPE. This will no
longer compile because in the prototype, Attribute types are of the
Enumerated AttributeType, and the code would have to become:
AttributeType attype = Attribute.ID_TYPE. I don't believe AttributeTypes
are used by many people, and the impact would be low.
- people who have chosen to have their own implementations of the Filter
interface will be pretty messed up with the port. Then again, this is a
'major release', and a change of interface is OK, right? Similarly,
people who have extended any of the classes in JDom will have issues
with compile errors...
One issue already encountered is that some people have already modified
their 'legacy' code to be 'generified'. Mattias, for example, has done
the following to his applications:

List<Element> something =
(List<Element>)XPath.newInstance("/some/xpath").selectNodes();

the above will compile with a compiler warning on this line, but, all
the subsequent references to the 'something' list will have the benefits
of generics. Unfortunately, this means that the 'new' version of JDom
will, unless it exactly returns List<Element>, will cause compile
errors.... for example, it is possible that a final version of the
selectNodes() method will return List<? extends Content>, and even this
will cause compile *errors* in Mattias's code.

So, a bigger problem with the 'recompile and it works' situation is
perhaps not the true legacy code, but the code which is ported to Java5
already but will have different generics.... For what it's worth, in my
legacy code ports I just happen to have used the wild-card generics to
access Jdom, like List<?> kids = root.getChildren(), and, as a
consequence, I have no problems.... perhaps other people will be OK too.

When I said 99% of people should get away with recompiles only, I was
not aware of the situations like Mattias's. I need to revise that number
much lower now...

3. Substantially changing the method signatures is something that I
tried to avoid in the prototype, but, based on subsequent discussions,
it appears that there may be places where this would be advantageous.
XPath has generated some interesting challenges, and one solution would
be requiring a second parameter to XPath constructors which would be the
class of the return type... like: List<Element> something =
XPath.newInstance("/some/path", Element.class).selectNodes(); I have
actually built this alternate mechanism in an unpublished version of my
prototype, and it does work quite well, and also conforms to the
standard practices...


Additional Issues...

Based on discussions earlier, it appears that XPath may be a real
problem with Generics. The 'right thing' for XPath to do depends on
Jaxen, and, since that is not 'generified' we are stuck. The reason
Jaxen is not generified is pretty obvious, because it is a whole lot
more complicated to impose generics on a method call like
Xpath.newInstance("//@*")....

Victor has made suggestions for the Filter class which are likely to be
less intrusive than the changes I made in the prototype, but no-one has
actually explored his suggestions yet.

Conclusion...

I don't believe that we can get a good Java5 API without at least
compile-time compatibility. I think to get the best API we will probably
need to resort to having substantially changed API's.

I think there are going to be compile-time errors for some people
regardless of which route we decide to take....

Rolf
_______________________________________________
To control your jdom-interest membership:
http://www.jdom.org/mailman/options/jdom-interest/youraddr@...

[Mattias Jiderhamn-4]

Nice to see you picking up the subject, Jason.

At this point I would just like to recommend some reading of Apache
recommendations considering compatible/non-compatible changes.
  http://commons.apache.org/releases/versioning.html

(I still haven't had time to look at Rolfs sources to see what kind of
changes have actually been made in this case)

 /Mattias Jiderhamn


Jason Hunter wrote (2008-03-04 22:39):

> First off, I want to thank Rolf for investing his time in exploring
> the technical feasibility of a JDOM migration to a Java 5 baseline.  A
> few other people have explored the area in the past as well, and it
> feels like (especially with JDOM 1.1 now finished) we can look at this
> in earnest.
>
> What I'd like to do here is take a high level view and ask some
> questions of our local Java 5 porting experts -- Rolf, Mattias,
> Victor, Gregor, and any others with experience porting widely-adopted
> projects to Java 5.
>
> 1. I think we can all agree the ideal scenario is to develop a drop-in
> replacement, a new JAR which (so long as you're on Java 5+) would let
> previously compiled code continue to work.  This would let us continue
> development as usual with a new release (call it 1.2 or 1.5 or 2.0)
> simply having a higher Java version requirement.  How far can we go
> down the road of embracing Java 5 while still maintaining this?
>
> 2. A less ideal scenario would require any previously compiled code to
> be recompiled against the new JAR, but wouldn't require any code
> changes.  This will cause some confusion and effort but to an
> acceptably small amount.  Rolf, you say your build requires a
> recompile and in 99% of cases doesn't require code changes.  Where are
> the gaps?  Can they be filled?
>
> 3. The fallback scenario is one where people will need to modify
> existing code in order to use the new version.  This will cause some
> pain, and should we follow this path I think we should look at what
> steps we can take to mitigate it.  Automated upgrade scripts?  A new
> package, like org.jdom5, so people can choose to use the old version
> or the new?  Other possibilities?
>
> 4. Lastly, I'd like to hear from people on what specific advantages
> they're looking for in an upgrade to a Java 5 baseline.
>
> My answers:
>
> I'll start with (4) because you need to know why before you know how.  
> I think people would most like to improve the return values of methods
> to be more specific.  For example, getChild() should return Element,
> getChildren() should return List<Element>, text.getParent() should
> return Element, doctype.getParent() should return Document, and so on.
> Are there other "big ticket" items?
>
> On (1) I suspect that without a source recompile we can't adjust the
> method return types which is the core value of the upgrade.
>
> On (2) from Rolf's README it looks like there are two areas likely to
> require code changes based on his port: the Filter.filter() change and
> the AttributeType enum.  Both seem like things to do if you're already
> requiring code changes but aren't things so valuable in and of
> themselves that we should require people do a code change.  Are there
> more?
>
> -jh-
>
> _______________________________________________
> To control your jdom-interest membership:
> http://www.jdom.org/mailman/options/jdom-interest/youraddr@...
>

_______________________________________________
To control your jdom-interest membership:
http://www.jdom.org/mailman/options/jdom-interest/youraddr@...

[Mattias Jiderhamn-4]

B.t.w. I just tried replacing the JAR on one of our test servers,
restarting the application *without* recompiling.
So far it seems to work fine; building from file, creating with code,
XPath, XSLT with JDOMSource/JDOMResult but no Filters.
(Especially note the XPath.selectNodes() - the explicit cast from
List<?> isn't needed until recompilation)

 /MJ


Jason Hunter wrote (2008-03-04 22:39):

> First off, I want to thank Rolf for investing his time in exploring
> the technical feasibility of a JDOM migration to a Java 5 baseline.  A
> few other people have explored the area in the past as well, and it
> feels like (especially with JDOM 1.1 now finished) we can look at this
> in earnest.
>
> What I'd like to do here is take a high level view and ask some
> questions of our local Java 5 porting experts -- Rolf, Mattias,
> Victor, Gregor, and any others with experience porting widely-adopted
> projects to Java 5.
>
> 1. I think we can all agree the ideal scenario is to develop a drop-in
> replacement, a new JAR which (so long as you're on Java 5+) would let
> previously compiled code continue to work.  This would let us continue
> development as usual with a new release (call it 1.2 or 1.5 or 2.0)
> simply having a higher Java version requirement.  How far can we go
> down the road of embracing Java 5 while still maintaining this?
>
> 2. A less ideal scenario would require any previously compiled code to
> be recompiled against the new JAR, but wouldn't require any code
> changes.  This will cause some confusion and effort but to an
> acceptably small amount.  Rolf, you say your build requires a
> recompile and in 99% of cases doesn't require code changes.  Where are
> the gaps?  Can they be filled?
>
> 3. The fallback scenario is one where people will need to modify
> existing code in order to use the new version.  This will cause some
> pain, and should we follow this path I think we should look at what
> steps we can take to mitigate it.  Automated upgrade scripts?  A new
> package, like org.jdom5, so people can choose to use the old version
> or the new?  Other possibilities?
>
> 4. Lastly, I'd like to hear from people on what specific advantages
> they're looking for in an upgrade to a Java 5 baseline.
>
> My answers:
>
> I'll start with (4) because you need to know why before you know how.  
> I think people would most like to improve the return values of methods
> to be more specific.  For example, getChild() should return Element,
> getChildren() should return List<Element>, text.getParent() should
> return Element, doctype.getParent() should return Document, and so on.
> Are there other "big ticket" items?
>
> On (1) I suspect that without a source recompile we can't adjust the
> method return types which is the core value of the upgrade.
>
> On (2) from Rolf's README it looks like there are two areas likely to
> require code changes based on his port: the Filter.filter() change and
> the AttributeType enum.  Both seem like things to do if you're already
> requiring code changes but aren't things so valuable in and of
> themselves that we should require people do a code change.  Are there
> more?
>
> -jh-
>
> _______________________________________________
> To control your jdom-interest membership:
> http://www.jdom.org/mailman/options/jdom-interest/youraddr@...
>

_______________________________________________
To control your jdom-interest membership:
http://www.jdom.org/mailman/options/jdom-interest/youraddr@...

[Michael Kay]

> Based on discussions earlier, it appears that XPath may be a
> real problem with Generics. The 'right thing' for XPath to do
> depends on Jaxen, and, since that is not 'generified' we are
> stuck. The reason Jaxen is not generified is pretty obvious,
> because it is a whole lot more complicated to impose generics
> on a method call like Xpath.newInstance("//@*")....

Also, please don't forget my comments about XPath 2.0. If you're revising
JDOM for Java5, it's surely foolish to do that without thinking about XPath
2.0, with its much richer set of possible return types (and parameter
types). Otherwise you'll have another discontinuity some time over the next
12-18 months.

One approach to doing that is XQJ (JSR 225,
http://jcp.org/en/jsr/detail?id=225) which has just gone out on final
ballot. That's a pretty complex approach, which doesn't fit the JDOM style
very well. However, there's a lot that you can do to make XPath more usable
from Java 5, for example:

(a) introducing a Node class or interface

(b) making a compiled XPath expression Iterable

My own attempt at an XPath 2.0 interface, which also handles XSLT and
XQuery, is s9api,

http://www.saxonica.com/documentation/javadoc/net/sf/saxon/s9api/package-sum
mary.html

Michael Kay
http://www.saxonica.com/


_______________________________________________
To control your jdom-interest membership:
http://www.jdom.org/mailman/options/jdom-interest/youraddr@...

[Joe Bowbeer]

On Tue, Mar 4, 2008 at 2:55 PM, Victor Toni wrote:
>
>  - Convert all StringBuffer to StringBuilder.
>

Are there places where we should "upgrade" to the read-only
CharSequence interface?
_______________________________________________
To control your jdom-interest membership:
http://www.jdom.org/mailman/options/jdom-interest/youraddr@...

[Victor Toni]

Joe Bowbeer wrote:
> On Tue, Mar 4, 2008 at 2:55 PM, Victor Toni wrote:
>  
>>  - Convert all StringBuffer to StringBuilder.
>>
>>    
>
> Are there places where we should "upgrade" to the read-only
> CharSequence interface?
>  
Actually every occurrence of String as a parameter could be changed to
CharSequence allowing the user to pass String, StringBuffer, and
StringBuilder or even CharBuffer.
_______________________________________________
To control your jdom-interest membership:
http://www.jdom.org/mailman/options/jdom-interest/youraddr@...

[Michael Kay]

> Actually every occurrence of String as a parameter could be
> changed to CharSequence allowing the user to pass String,
> StringBuffer, and StringBuilder or even CharBuffer.

The downside is that (a) you can't assume that the supplied value is
immutable; if you need to retain it beyond the call you have to make a copy;
(b) there can be a lot of "instance of" testing to see what kind of
CharSequence you've been given, and (c) you can't compare different kinds of
CharSequence for equality.

Saxon uses CharSequence very extensively despite these drawbacks, but it's
not necessarily the right approach everywhere.

Michael Kay
http://www.saxonica.com/

_______________________________________________
To control your jdom-interest membership:
http://www.jdom.org/mailman/options/jdom-interest/youraddr@...

[Mattias Jiderhamn-4]

Michael Kay wrote (2008-03-05 16:15):

Actually every occurrence of String as a parameter could be 
changed to CharSequence allowing the user to pass String, 
StringBuffer, and StringBuilder or even CharBuffer.
    

The downside is that (a) you can't assume that the supplied value is
immutable; if you need to retain it beyond the call you have to make a copy;
(b) there can be a lot of "instance of" testing to see what kind of
CharSequence you've been given, and (c) you can't compare different kinds of
CharSequence for equality.
  

Another downside is that the API will be less trivial for novice Java programmers. (So there will probably be more traffic on this list...)

 /Mattias

_______________________________________________
To control your jdom-interest membership:
http://www.jdom.org/mailman/options/jdom-interest/youraddr@...

[jhunter]

OK, so let me summarize what I've heard over the last 4 days about my
question on the advantages people see in a jump to Java 5 dependency.

I asked for "big ticket" advantages that would provide benefits
sufficient to justify the cost in making users have to recompile and
possibly rewrite some of their code:

* Myself, I'd like methods to have more specific return types.

* Rolf primarily wants to remove compiler warnings.  Secondarily, he'd
like more specific return types.

(This list doesn't seem very impressive, does it?  Are there more?)


We got some other "while we're at it" advantages:

* Victor would like to clean up the scaffolding classes that wouldn't be
needed with Java 5.


And lastly we had a "cool stuff but probably wouldn't require Java 5"
feature request:

* Michael Kay would like to see some XPath 2.0 support.

(I expect we could add this in a backwards compatible way with new
classes/interfaces like an XPath2.java if we found the right underlying
support libraries.)


Are there other advantages people want added to the list?

Do people think the "big ticket" advantages are worth making people,
probably 100,000 people, have to alter their code to get them?

Do we risk new users going with other XML object models if the other
projects are Java 5 clean on compiles and we're not?

-jh-
_______________________________________________
To control your jdom-interest membership:
http://www.jdom.org/mailman/options/jdom-interest/youraddr@...

[Michael Kay]

> Do we risk new users going with other XML object models if the other
> projects are Java 5 clean on compiles and we're not?

I'm not actually concerned about whether I have to recompile my code to work
with a new JDOM. What I really do care about, however, is that once I have
done so, the code should work regardless which version of JDOM my users have
installed. I don't want 1% of those 100,000 users calling me to say Saxon
doesn't work with JDOM any more...

The DOM incompatibilities introduced in Java 5 caused me no end of grief,
and I downgraded the level of support for DOM as a direct result. I wouldn't
like to see JDOM suffer the same fate.

Michael Kay
http://www.saxonica.com/

_______________________________________________
To control your jdom-interest membership:
http://www.jdom.org/mailman/options/jdom-interest/youraddr@...

[jhunter]

Michael Kay wrote:
>> Do we risk new users going with other XML object models if the other
>> projects are Java 5 clean on compiles and we're not?
>
> I'm not actually concerned about whether I have to recompile my code to work
> with a new JDOM.

What I meant by "Java 5 clean on compiles" was that a compile would
output no warning messages.  That is, if other projects jumped the
bridge to Java 5 compatibility then perhaps over time new users would
view those projects as superior because they didn't get a pile of JDK
warnings on each compile.  Warnings scare people.

> What I really do care about, however, is that once I have
> done so, the code should work regardless which version of JDOM my users have
> installed. I don't want 1% of those 100,000 users calling me to say Saxon
> doesn't work with JDOM any more...

Yes, this is the potential problem if we alter the public API, which
seems to be the "value" as well as the "curse" of a Java 5 jump.  It's
why I ponder an org.jdom2 package if we do that, so the piles of
existing code keep working and new code can be written against the new
package.  That's not ideal, but it's practical.  What do you think, Michael?

-jh-
_______________________________________________
To control your jdom-interest membership:
http://www.jdom.org/mailman/options/jdom-interest/youraddr@...

[Michael Kay]

> Yes, this is the potential problem if we alter the public
> API, which seems to be the "value" as well as the "curse" of
> a Java 5 jump.  It's why I ponder an org.jdom2 package if we
> do that, so the piles of existing code keep working and new
> code can be written against the new package.  That's not
> ideal, but it's practical.  What do you think, Michael?

Well, that has a downside too: I will have to fork the net.sf.saxon.jdom
package to create a net.sf.saxon.jdom2 package, and maintain and test both.
That's an extra 1000 or so tests to run each time I make a release. But it's
probably the lesser evil.

Michael Kay
http://www.saxonica.com/

_______________________________________________
To control your jdom-interest membership:
http://www.jdom.org/mailman/options/jdom-interest/youraddr@...

[timothymarc]

Hi all,

i followed your discussion after my return from the hollidays. IMHO, the
most import thing that had to be noticed under all circumstances is that
a  JDOMv2 must be able to process not only xml documents but xml fragments.

If the public api will be changed anyway, we should take the chance for
adjusting JDOMv2 to the process modell of the new XPath/XQuery datamodel.

I know, this means a lot of conceiving changes, but this will be worthwhile.

So, what did you all say about a XDM-compliant JDOMv2? I've spended some
thoughts about that in a private project, but at least i didn't have had
the time to perform changes in that way.

So long
--timothy

_______________________________________________
To control your jdom-interest membership:
http://www.jdom.org/mailman/options/jdom-interest/youraddr@...

[Mattias Jiderhamn-4]

Jason Hunter wrote (2008-03-08 11:49):

> Michael Kay wrote:
>>> Do we risk new users going with other XML object models if the other
>>> projects are Java 5 clean on compiles and we're not?
>>
>> I'm not actually concerned about whether I have to recompile my code
>> to work with a new JDOM.
>
> What I meant by "Java 5 clean on compiles" was that a compile would
> output no warning messages.  That is, if other projects jumped the
> bridge to Java 5 compatibility then perhaps over time new users would
> view those projects as superior because they didn't get a pile of JDK
> warnings on each compile.  Warnings scare people.

I believe lack of Java 5 support can scare new users off. Not so much
because of the compiler warnings, but because we've had generics for
more than 3 years now. If a user notices the lack of generics support
they may think "Hey, this piece of software probably haven't been
maintained in years, so I better look for something newer that's still
being maintained". (And I believe most people will not bother checking
the mailing list)

 /Mattias

_______________________________________________
To control your jdom-interest membership:
http://www.jdom.org/mailman/options/jdom-interest/youraddr@...