21

EDIT: I changed a bit the example for getting the idea:

Like 

 <Integer or Float>

...without having to create a common interface and make a subclass for Integer and Float to implement it

If not, something like this would maybe have more sense and be useful

 <E extends Number> <E = (Integer|Float)>

If ? is a wildcard why should not we allowed to restrict certain types?

Whimusical
  • 6,401
  • 11
  • 62
  • 105
  • 1
    Why would you want to do that? – Pshemo Jul 24 '12 at 14:45
  • They seem like chalk and cheese. The requirement makes no sense to me at all. Are Strings mathematical entities like Numbers, closed over certain operations? I thought not. – duffymo Jul 24 '12 at 14:46
  • Precisely because String is final, an or solution would be needed even more, because we could not solve it with the alternative I propose – Whimusical Jul 24 '12 at 14:48
  • I think it sounds like you need a real object instead of collection. There's some encapsulation missing here. – duffymo Jul 24 '12 at 17:30

3 Answers3

15

It's not possible and I hardly see any value in it. You use generics to restrict type, e.g. in collections. With or operator you know as much about the type as much you know about the most specific supertype of both of them, Object in this case. So why not just use Object?

Hypothetical:

List<E extends String or Number> list = //...

What is the type of list.get(0)? Is it String or Number? But you cannot have a variable of such type. It cannot be String, it cannot be Number - it can only be... Object.

UPDATE: Since you changed your example in question to:

<Integer or Float>

why won't you just say:

<Number>

? Note that Number has methods that allow you to easily extract floatValue() and intValue(). Do you really need the exact type?

Note that you can use and operator:

<E extends Serializable & Closeable>

And that makes perfect sense - you can use variable of type E where either Serializable or Closeable is needed. In other words E must extend both Serializable and Closeable. See also: Java Generics Wildcarding With Multiple Classes.

Community
  • 1
  • 1
Tomasz Nurkiewicz
  • 334,321
  • 69
  • 703
  • 674
  • Ok for list is stupid, but for other uses it could be not like this. Even that you could have a String a = list.get(0) or either a Integer a= list.get(0), ugly but not impossible or impracticle. It could throw a CastExeption if error – Whimusical Jul 24 '12 at 14:51
  • 3
    @user1352530: avoiding `ClassCastException` and compile time type checking was one of the reasons to include generics in the first place. – Tomasz Nurkiewicz Jul 24 '12 at 14:53
  • I updated the question with a new approah which makes the same for me – Whimusical Jul 24 '12 at 14:55
  • 1
    @User1352530: I feel OR is always confusing and error prone. May be time to re-architect requirement? Specially in Java with casting, I try to avoid OR as much as possible. As Tomasz said in answer AND is supported. – kosa Jul 24 '12 at 14:56
  • `I hardly see any value in it` I want to overload a method, and have version of `flatMap(Function1> mapper)` and `flatMap(Function1> mapper)`, but I cannot do it as I get error that their both erasure is the same. When I was searching for OR in generics, I hoped I could use it to ducktape fix this issue – Coderino Javarino Jul 09 '20 at 12:12
12

In very extreme cases (pre-Java 7 without AutoCloseable), I would have liked to be able to do that, too. E.g. 

<E extends Connection or Statement or ResultSet>

That would've allowed me to call E.close(), no matter what the actual type was. In other words, E would contain the "API intersection" of all supplied types. In this case it would contain close(), and all methods from java.sql.Wrapper and java.lang.Object.

But unfortunately, you cannot do that. Instead, use method overloading, e.g.

void close(Connection c);
void close(Statement s);
void close(ResultSet r);

Or plain old instanceof

if (obj instanceof Connection) {
    ((Connection) obj).close();
}
else if (obj instanceof Statement) { //...

Or fix your design, as you probably shouldn't have to intersect APIs of arbitrary types anyway

Lukas Eder
  • 211,314
  • 129
  • 689
  • 1,509
  • 1
    In Java 7 all these classes implement [`AutoCloseable`](http://docs.oracle.com/javase/7/docs/api/java/lang/AutoCloseable.html) so `` is now enough. – Tomasz Nurkiewicz Jul 24 '12 at 15:02
  • @TomaszNurkiewicz: I know. It's just an illustration. @GriffeyDog: See Tomasz' answer. JDBC types extend `AutoCloseable`, not `Closeable` (which also extends `AutoCloseable`) – Lukas Eder Jul 24 '12 at 15:05
  • Another similar case swhere it would be useful is Number interface, DOuble, Integer ... have valueOf but Number, the super, does not. Also: when you need T = concrete subtypes but not the super-OR is handy – Whimusical Dec 16 '15 at 16:49
1

I don't see a real use for it... But anyways, I believe the closest you'd get to it is extending common interfaces for the possible implementations.

everton
  • 7,579
  • 2
  • 29
  • 42