Bug #3982
closed
Raw type Item used in 'XPathExpression.evaluate' method signature
100%
Description
With newer version of the Saxon HE library definition of the class net.sf.saxon.om.Item changed from
9.8.0-14
public interface Item extends Sequence
9.9.0-1 to
public interface Item<T extends Item> extends GroundedValue<T>
Currently, net.sf.saxon.sxpath.XpathExpression.evaluate() method returns List<Item>,
The problem is Item is a raw type, it should be parameterized.
Why raw types should be avoided, can be found here: https://stackoverflow.com/questions/2770321/what-is-a-raw-type-and-why-shouldnt-we-use-it http://www.javapractices.com/topic/TopicAction.do?Id=224
Our CI fails with violations corresponding to this issue, could you please update `XPathExpression.evaluate` method signature to avoid using raw types.
Thank you
Updated by Michael Kay over 5 years ago
- Tracker changed from Patch to Support
- Category set to Internals
- Assignee set to Michael Kay
I've been working hard on using Java generics as extensively as possible, but there are some problems I haven't been able to solve. Classes like Sequence and GroundedValue clearly behave like collection classes and it's nice to parameterize them by the type of Item that they contain, for example Sequence or Sequence. But an Item is itself a sequence of items, and an AtomicValue is a sequence of atomic values, and I haven't found any way to use generics to represent this properly: to avoid all use of "raw" types we end up with infinite regress like Sequence <Item <item <item <Item <....> > > > >
I eventually came to the conclusion that Java generics don't allow complete modelling of the XDM model where an item is itself a sequence. But if you can help me find a way around this, I'll be happy to hear your suggestions.
Updated by Vladimir Nesterovsky over 5 years ago
How about this:
public interface Sequence<T extends Item<?>>
{
public T get(int index);
}
public interface Item<T extends Item<?>> extends Sequence<T>
{
T value();
}
public class Boolean implements Item<Boolean>
{
public Boolean(boolean value)
{
this.value = value;
}
@Override
public Boolean get(int index)
{
return this;
}
@Override
public Boolean value()
{
return this;
}
boolean booleanValue()
{
return value;
}
private boolean value;
}
List can be written as List<Item<?>> to please compiler.
Updated by Vladimir Nesterovsky over 5 years ago
In last sentence I was trying to say:
List<Item> can be written as List<Item<?>>
Updated by Michael Kay over 5 years ago
Thanks for the suggestion, Vladimir. I've been spending the day exploring this approach and it looks promising. It adds quite a bit of noise (Item changing to Item<?> in a lot of places), but it has reduced the number of conversion warnings, and it has even found one or two bugs where impossible conversions were being attempted.
Updated by Michael Kay over 5 years ago
- Tracker changed from Support to Bug
- Subject changed from Saxon HE 9.9: update 'XPathExpression.evaluate' method signature to Raw type Item used in 'XPathExpression.evaluate' method signature
- Status changed from New to In Progress
- Priority changed from Low to Normal
- Fix Committed on Branch 9.9 added
I've committed an (extensive!) fix as suggested by Vladimir, and everything seems to be working.
However, I'm going to experiment with an alternative solution to see if I can come up with something simpler.
Updated by Michael Kay over 5 years ago
- Status changed from In Progress to Resolved
I have managed to convince myself that the only alternatives are
(1) Abandon generics on Sequence (i.e. revert to the 9.8 model)
(2) Make Item no longer implement Sequence (which is effectively back to where we were around 9.4/9.5)
Doing (2) is very unappealing. Doing (1) has a little bit more attraction, because it has to be said that the benefits of generifying Sequence are somewhat modest; the vast majority of places Sequence is used within the Saxon code, there are no compile-time restrictions on the type of items contained in the sequence. However, I think the cases where we subclass it (e.g. to AtomicSequence) are probably sufficient justification on balance, and I certainly don't want to change back.
So we'll go with the Item<?> solution, verbose though it is.
I have made further changes along the same lines to reduce the number of "unchecked assignment" warnings when compiling the code. Still haven't eliminated all of them.
Updated by Michael Kay over 5 years ago
I have committed a further (extensive) set of changes based on careful reviewing of all the warning messages that arise when compiling the product with -Xlint:unchecked. This hasn't eliminated all the warnings, but the vast majority are gone.
I removed type parameters from Converter and StringConverter because they seemed to be achieving nothing.
Updated by O'Neil Delpratt over 5 years ago
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
- Fixed in Maintenance Release 9.9.0.2 added
Bug fix applied to the Saxon 9.9.0.2 maintenance release.
Please register to edit this issue
.