Alistair Parler

Hi Jim,

Probably my fault.

Generic stuff -does- make it into executable code in this way:

First, define a generic class with a bounded type parameter:

public class Pair<T extends Comparable & Serializable> { T getFirst() { ... } T getSecond() { ... } void setFirst(T value) { ... } void setSecond(T value) { ... } }

This will be translated into a raw type which, after type erasure, corresponds to this:
public class Pair { Comparable getFirst() { ... } Comparable getSecond() { ... } void setFirst(Comparable value) { ... } void setSecond(Comparable value) { ... } }
Note that the type parameter has been replaced with *the first bounding type* - Comparable. Where the class is used in a "serializable" context and not in a "comparable" context, the bytecode must include casts. It necessarily needs to do this since we've made a compile-time promise that the type parameter is also a Serializable.

Now, if I had exactly the same generic class, but changed the bounding parameter order like this (i.e, changed the order of Comparable and Serializable):

public class Pair<T extends Serializable & Comparable> { // same as before }

then the resultant raw type would look different and become this:

public class Pair { Serializable getFirst() { ... } Serializable getSecond() { ... } void setFirst(Serializable value) { ... } void setSecond(Serializable value) { ... } }

Therefore the bytecode would now include casts to Comparable instead of Serializable (again, depending upon the context and the type inference at that point).

After these examples, my question really is: why is the first raw type more efficient than the second raw type? Why should I put the tag interface last? Why is casting to an interface which houses methods any more 'heavyweight' than casting to Serializable? All these are equivalent for this example so any answer will do.

Hope that clarifies things!

Any help greatly appreciated!


Thanks,
Alistair

Hi,

I read in Core Java: Vol 1 that if you have multiple bounding types for a type parameter, it is less efficient if you were to place a tagging interface as a bound at the head of the list. i.e. if this: <T extends Serializable & Comparable> would be less efficient than this: <T extends Comparable & Serializable>. The reason given is that the JVM during type erasure would replace the type parameter with Serializable everywhere it appeared and would therefor need to cast to Comparable when necessary. This is apparantly less efficient than the reverse.

Could anybody tell me why that is please? Why is it less efficient to cast to an interface with methods as opposed to a tag interface.


Thanks,
Alistair

Thanks - I'll have a read! ;)

NaN is a special value that isn't equal to anything, not even itself.

I 'understand' that (in that I've read it and just accept it as being true).

But I don't see how we can deduce the following from that:

So if we want to know if a double is Nan then we compare it with itself.

Looking at the Javadoc it talks of NaN being defined internally as a sequence of bit patterns:

/** * A constant holding a Not-a-Number (NaN) value of type * <code>double</code>. It is equivalent to the value returned by * <code>Double.longBitsToDouble(0x7ff8000000000000L)</code>. */ public static final double NaN = 0.0d / 0.0;

and

/** * If the argument is any value in the range * <code>0x7ff0000000000001L</code> through * <code>0x7fffffffffffffffL</code> or in the range * <code>0xfff0000000000001L</code> through * <code>0xffffffffffffffffL</code>, the result is a NaN.

(taken from Double.fromLongBitsToDouble)

So maybe the JVM shuffles some things around internally to make these bit comparisons unequal?

I don't need to know this (as many of us don't) but I'm just curious that's all!

If anyone has a more technical answer (put in a big print way ;-)) I'd appreciate it.

Thanks though for your input.

Hi there,

I've been looking through the JDK code and came across this in the Double class:

static public boolean isNaN(double v) { return (v != v); }

Is there some trickery going on here?!?! I can't see how this would work!! In 'normal' Java doesn't this mean that for any double, it would never be 'not a number' (which I agree with) but where is the true case coded for (i.e. for 0.0d / 0.0)
Any help from some Java gurus greatly appreciated in explaining this!


Thanks,
Alistair

Thanks Adam - that clears things up for me!

Just had an idea:

is it because signalAll() will tell all threads in the wait-set to become runnable and therefore it's possible that one of the threads which was signalled has modified the state so that it's possible that it will spoil it for other threads? If that makes sense... Would we therefore not have the problem if we just used signal() to wake one thread (i.e. we could use the 'if' if we only used signal() from the condition-enabling thread)

Hi there,

I'm doing a bit of reading on the new JDK5 concurrency package. My question is:

Why do I have to do:

while ( ! okToProceed ) { someCondition.await(); } // processing to do when condition is fulfilled

why can't I do this in an 'if':

if ( ! okToProceed ) { someCondition.await(); } // processing to do when condition is fulfilled

As far as I can see, when another thread has fulfilled the condition which the blocked thread is waiting in (with signalAll()) then (providing that thread is aware of the okToProceed condition which it could do if both threads were under control of the same programmer) the 'if' construct would be good enough.

Is this just a belt-and-braces "you may aswell retest the expression again just to be on the safe side since you've already got the lock anyhow" test or am I missing something here?


Thanks in advance,
Alistair

Thanks Campbell!

I just wrote this program and tested it by clicking Btn1 and then Btn2 lots of times. After the sleep had completed, the remaining events were pumped, then the program terminated. So they are indeed queued.

package com.alistair.test; import java.awt.FlowLayout; import java.awt.event.ActionEvent; import java.awt.event.ActionListener; import javax.swing.JButton; import javax.swing.JFrame; public class Main { public static void main(String[] args) { JFrame frame = new JFrame(); JButton btn1 = new JButton("Btn1"); btn1.addActionListener(new ActionListener() { @Override public void actionPerformed(ActionEvent e) { System.out.println("Btn 1 clicked"); try { Thread.currentThread().sleep(5000); } catch (InterruptedException e1) { e1.printStackTrace(); } } }); JButton btn2 = new JButton("Btn2"); btn2.addActionListener(new ActionListener() { @Override public void actionPerformed(ActionEvent e) { System.out.println("Btn 2 clicked"); } }); frame.setLayout(new FlowLayout()); frame.add(btn1); frame.add(btn2); frame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE); frame.pack(); frame.setVisible(true); } }

Thanks,
Alistair

From this link:

Threading in Swing

(refer to: "Single Thread Rule")

it seems that the first time you create a JFrame (and make it visible), you are 'allowed' to do this from the main thread. However, once it is "realized" (with show(), setVisible(true), pack()) and you wish to change its state, you must do so from within the AWT event dispatch thread.

Hope that helps (it helped me!).


Thanks,
Alistair

Hi,

This is probably a really dumb question, but I'd appreciate any help: I'm just curious.

If I have an actionlistener which is executing its actionPerformed inside the AWT event dispatch thread (i.e. we haven't done the correct thing of either doing the work in a new thread so it doesn't hog the event dispatch thread, or doing the work in an invokeLater if it manipulates any Swing components), what happens to the peer events from the OS when this is running: do they get queued ready for dispatch when the actionPerformed returns?


Thanks,
Alistair