King Lung Chiu

Hi,

Thanks for the reply.

When rec.c == null, I want to do a wild-card match, ie return Records with any c value, rather than return records where c == null.

So unfortunately that suggestion doesn't work :-(

Any other thoughts?

Hi everyone,

Say I have a Record entity with 3 fields a, b and c, and given a Record instance rec, I use r's fields as criteria for a predefined (named) SELECT query (with AND on all fields).

Does JPQL allow us to write a query that can do wildcard matches on fields that are null?

eg. if rec has all 3 of a, b and c set, then the query would simply be:
select * from Record where a = rec.a AND b = rec.b AND c = rec.c

But if say field c is null, I'd like to do something like this:
select * from Record where a = rec.a AND b = rec.b AND c = *

Which should work effectively as this JPQL query:
select * from Record where a = rec.a AND b = rec.b

I want to do wildcard matches because there are quite a number of fields in my entity, and I don't know in advance how many of them (and in which combination) will be supplied in the search criteria. And I'd like to do the above as a named query if possible to avoid having to dynamically construct SQL by hand.

Any idea how to achieve the above in JPQL?

thanks a lot, regards.

Great, thanks Carey.

cheers.

Hi,

Is there a standard way to extract the default algorithm parameters of a given cryptographic provider? Specifically for a DH KeyPairGenerator?
eg. if I'm generating the keypair to start a DH key agreement, I'd usually go:
KeyPairGenerator kpg = KeyPairGenerator.getInstance("DH"); kpg.initialize(new DHParameterSpec(p, g); KeyPair kp = kpg.generatorKeyPair(); ...
Now, if I leave out the kpg.initialize(...) step, the keyagreement appears to still work fine, which suggests the default (SUN) DH provider has default values for p and g. So is there a standard way to find out what those default values are for p and g, save from going to the source code?

thanks, cheers,

King

Hi Garrett,

Thanks a lot for the reply. And thanks for the interesting examples.

I think I can explain why they're like that (my understanding):

Fruit<Apple> f1 = new Apple(); int compFruitAndApple = f1.compareTo(a1); //Passes compilation

Here, f1 is Fruit<Apple>, so its compareTo() takes an Apple, thus it compiles fine.

int compAppleAndFruit = a1.compareTo(f1); //Compilation error

Here, since f1 is a Fruit<Apple> rather than an Apple, and since a1.compareTo() takes an Apple, compilation fails. Though it's safe to cast f1 back into an Apple, if required, since it references an Apple.

Fruit<Apple> f2 = new Apple(); int compFruits = f1.compareTo(f2); //Compilation error

Here, both f1 and f2 are Fruit<Apple>s, and because of the parameterisation, they both use compareTo(Apple), rather than compareTo(Fruit<Apple>), thus the compilation fails.

And I think you're right that Fruit<E extends Fruit> and Fruit<E extends Fruit<E>> are equivalent ... at least according to the 1.6.0_01 compiler I'm using, they both give the same errors with your examples.

thanks again, cheers,

King

Hi Campbell,

Thanks for the reply.

Why are you parameterising Fruit in the first place? I can see no benefit in writing

public class Apple extends Fruit<Apple>

over

public class Apple extends Fruit

Because:

(1) I only want a specific Fruit subclass to be comparable to themselves, and not to any other different subclass. eg. I don't want to allow an Apple to be comparable to an orange.

(2) I don't want to duplicate the compareTo() code in all Fruit subclasses, so I'm writing it once only in the Fruit superclass, and using generics to bind it to a specific subclass when required. Please look at the compareTo() definition in my first post again, it'll make more sense.

And surely it's
public class Fruit implements Comparable<Fruit>

Yes, if you want to use compareTo(Fruit), ie. allow all Fruits to be comparable to each other, even allow an Apple to be comparable to an Orange.

No, if you don't want to use compareTo(Fruit), but rather compareTo(A-Specific-Fruit-Subclass), ie. only allow a Fruit subclass to be compared to the same Fruit subclass.

And I'm trying to design for the 2nd case.

I appreciate the alternative suggestions, but I've already considered them and they're not suitable for what I need. So please assume that I have good reasons to use Apple extends Fruit<Apple> and [I]Orange extends Fruit<Orange>[I], and that given such case, whether there is any technical or semantic differences between the following Fruit header declarations (both have the exact same class bodies, and both compile and run fine with the same Apple and Orange definitions show above):

abstract class Fruit<E extends Fruit> implements Comparable<E> { ... public int compareTo(E that) { ... } } abstract class Fruit<E extends Fruit<E>> implements Comparable<E> { ... public int compareTo(E that) { ... } }

Thanks again.

King

... and please ignore those winking icons - they're supposed to be closing brackets - not sure how they got there ...

cheers!

Hi everyone,

I was wondering, does anyone know if there's a difference between the following two declarations?

// Subclasses are simple extensions of the raw Fruit class abstract class Fruit<E extends Fruit> implements Comparable<E> { ... public int compareTo(E that) { ... } } // Subclasses are extensions of the parameterized Fruit class abstract class Fruit<E extends Fruit<E>> implements Comparable<E> { ... public int compareTo(E that) { ... } }

Both seem to compile and run fine. But I was wondering, is the 2nd more semantically correct than the 1st?

And what am I trying to do here, I hear you ask? I'm trying to create various types of fruits - Apples, Oranges - that can only compare with themselves. The comparison logic is the same for all fruits, so I'm placing that logic in the superclass Fruit and using generics to bind compareTo() to the correct subclass. This avoids duplicating the same comparison code in all subclasses. The rest of the code looks like this (compiles and runs correctly):

class Apple extends Fruit<Apple> { public Apple(int size) { super("Apple", size); } } class Orange extends Fruit<Orange> { public Orange(int size) { super("Orange", size); } } // inside main List<Apple> apples = Arrays.asList(new Apple(1), new Apple(2)); List<Orange> oranges = Arrays.asList(new Orange(3), new Orange(4)); List<Fruit> fruits = new ArrayList<Fruit>(); fruits.addAll(apples); fruits.addAll(oranges); Collections.max(apples); Collections.max(oranges); // compiler throws unchecked warnings as expected Collections.max(fruits); // compiling fails as expected apples.get(0).compareTo(oranges.get(0));

I'm using the same Apple and Orange definitions for both types of Fruit header declarations.

Since Apple extends Fruit<Apple> and Orange extends Fruit<Orange>, I thought the 2nd Fruit declaration (using <E extends Fruit<E>> would be the correct one. However, the code compiles and runs fine with the 1st Fruit declaration too (using <E extends Fruit> , so that got me wondering if there really is any difference between the two.

All comments are welcome, cheers!

King

PS. Yes, for those eagle eyes, this is a modified example from Naftalin and Wadler's "Java Generics and Collections", combined with ideas from Java 5's Enum implementation :-)