Skip to main content

Remove weird up-cast for ternary operators

13 replies [Last post]
tsinger
Offline
Joined: 2003-06-10
Points: 0

Take this example class structure:

public interface InderFace {<br />
}</p>
<p>public class Foo implements InderFace {<br />
}</p>
<p>public class Bar implements InderFace {<br />
}

Why one cannot write

final InderFace inderFace = (a > 10)<br />
  ? new Foo()<br />
  : new Bar();

but needs to write an up-cast
final InderFace inderFace = (a > 10)<br />
  ? (InderFace)new Foo()<br />
  : new Bar();

Tom

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
peterkessler
Offline
Joined: 2004-10-27
Points: 0

JDK-1.5.0 is stable enough. I just took your code: [pre]interface InderFace {
}

class Foo implements InderFace {
}

class Bar implements InderFace {
}

public class Inderface {
void client1(int a) {
final InderFace inderFace = (a > 10)
? new Foo()
: new Bar();
}

void client2(int a) {
final InderFace inderFace = (a > 10)
? (InderFace)new Foo()
: new Bar();
}
}[/pre] and compiled it with my friendly local JDK-1.5.0 compiler [pre]$ java -version
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
Java HotSpot(TM) Client VM (build 1.5.0-b64, mixed mode, sharing)
$ javac Inderface.java[/pre] without any complaints. Does that not work for you with JDK-1.5.0-b64?

tsinger
Offline
Joined: 2003-06-10
Points: 0

Peter, as you might have noticed, the compiler of JDK 1.5.0 contains serious compiler bugs (see http://www.javalobby.org/forums/thread.jspa?forumID=61&threadID=14940 and http://www.javalobby.org/forums/thread.jspa?forumID=61&threadID=15470 ). The other reason, why JDK 1.5.0 is not an option yet, is, it cannot create JDK-1.4.-compliant class files (using generics), which are required to run our application on Mac OS X.

Tom

gafter
Offline
Joined: 2003-08-29
Points: 0

> Peter, as you might have noticed, the compiler of JDK
> 1.5.0 contains serious compiler bugs (see
> http://www.javalobby.org/forums/thread.jspa?forumID=61
> &threadID=14940 and
> http://www.javalobby.org/forums/thread.jspa?forumID=61
> &threadID=15470 ).

Both bugs are already fixed in the public version.

tsinger
Offline
Joined: 2003-06-10
Points: 0

Yes, they are fixed in 1.5.0_01. For our Windows-project we will switch soon, but for our libraries that are used on projects, which also should run on Mac OS X, we need to wait 'til it provides a 1.5-JDK, too.

Tom

peterkessler
Offline
Joined: 2004-10-27
Points: 0

This looks like it was fixed between JDK-1.4.2 and JDK-1.5.0.

I suggest you upgrade.

tsinger
Offline
Joined: 2003-06-10
Points: 0

> This looks like it was fixed between JDK-1.4.2 and
> JDK-1.5.0.

Cool, did not know :)

> I suggest you upgrade.

When JDK (1.)5 is stable enough (when will JDK (1.)5.0_01 be released?) and supported on Mac OS X as well, we'll use it.

Tom

wingetr
Offline
Joined: 2004-01-19
Points: 0

If you read the roadmap, 1.5.0_01 isn't likely to make an appearance.

I believe that J2SE 5.0 will ship with the next version of Mac OS X.

tsinger
Offline
Joined: 2003-06-10
Points: 0

When 1.5.0 came out, the serious ternary-operator compiler-bug was found. On Javalobby it was said, that SUN plans to release 1.5.0_01 in December 04 - which is very late, because of the severity of this bug (if you can't trust the compiler, you cannot use it). Now you tell me, that 1.5.0_01 might still take some time. I guess, this is not the right way of doing professional software development and support. To be honest, I would have expected from SUN, that they release 1.5.0_01 with the above mentioned bug fixed [b]a week[/b] after release of 1.5.0.

Just my 0,02€
Tom

tackline
Offline
Joined: 2003-06-19
Points: 0

It kinds of adds some complication to the type system. Consider cond ? new HashSet

() : new ArrayList(). We are probably after Collection, but there is also the choice of Serializable or Cloneable. A method may appear in different interface with different parameter types, complicating overloading. The clearest way of dealing with arbitrary choices or complex mechanisms is to simply disallow anything awkward. OTOH, generics allow intersections of parameter types. The byte code, IIRC, allows intersection of types on the stack. The question is, do we want to add extra complication to smooth out a rare problem that is trivially worked around? As for ?: working the same as if, it pretty much does. The if variant requires that you specify the type of the variable assigned.
tsinger
Offline
Joined: 2003-06-10
Points: 0

The compiler only needs to check in a = condition ? b : c, whether b can be assigned to a and whether c can be assigned to a. Just like in
[code]final InderFace inderFace;
if (a > 10) {
inderFace = new Foo();
}
else {
inderFace = new Bar();
}[/code]
There is no cast required.

Tom

tackline
Offline
Joined: 2003-06-19
Points: 0

Presumably any reasonable compiler will treat condition ? b : c the same whether it is part of a = ...; or fn(...);.

There is a cast, it's just that its an implicit, up-cast.

dondi_imperial
Offline
Joined: 2004-11-22
Points: 0

+1

I didn't even about this but yes it should work that way.

dgreenbean
Offline
Joined: 2003-12-08
Points: 0

+1

I remember running into the problem for the first time about a year ago. I see no reason that
a ? b : c
should work any differently from
if (a) b; else c;

-David