Tom Halligan - Page 5 of 6 -

February 22, 2012

ACTA referred to European Court of Justice

It was announced today that the EU has suspended ratification of ACTA and has referred the agreement to the European Court of Justice. This is an incredibly welcome action and should help to put the minds of those of us who object to ACTA at some ease.

This does not mean that ACTA has gone away forever. All it means is that there is enough concern within the EU about the ramifications of the agreement that it has been referred to the EU’s top court for a ruling. This could potentially take months or even years – although it’s my gut feeling that we’ll be hearing about ACTA again sooner rather than later, given the huge benefits and unprecedented powers it would provide to those who were pushing for it in the first place.

Even with the above in mind, we should celebrate this victory and do whatever we can to assert our rights to freedom of speech and expression in whatever ways we can. Until the people who dream up horrendous ideas like ACTA, SOPA, and PIPA realise that there are enough people out there paying attention, these attacks will continue. There’s also the possibility that once the fuss has died down, ACTA will once again rear it’s ugly head and slip by unnoticed. We can’t take that chance, and should keep the pressure on our politicians to make sure that our concerns are considered and addressed.

February 20, 2012February 22, 2012

UKIP’s Paul Nuttall responds on ACTA

Yesterday I wrote about my concerns with ACTA and urged people to write to their representatives as I have done, to raise awareness among MPs and MEPs that we demand to be included in the discussions about this dangerous agreement. UKIP’s Paul Nuttall, MEP for the North West, has since responded by proxy of his P.A, Nigel Brown.

Before I get on to the response, I’d like to discuss a few points.

Firstly, the response itself was not simply written as part of the e-mail. It was attached as an MS Word document. I don’t own MS Office, and I’m not entirely sure what the policy is with regards to these things, but surely all representatives should be responding to constituents using some kind of open document format? I see no real reason this couldn’t have just been part of an e-mail, anyway. Perhaps it’s because correspondence from Mr Nuttall requires this monstrous header:

Not once, not twice, but thrice we are confronted with Paul leering out at us, smirking like a schoolboy who’s just caught a glimpse of his best mate’s mum’s side-boob. Why do we need three Pauls? Why is one smaller than the others? Why is the UKIP logo itself squashed? Is this some kind of metaphor? I honestly do not understand what would make somebody take a look at the first draft of this document and think “You know what this needs? More Nuttall”.

Dodgy visuals aside, and the fact that the format this response came in made it a pain to copy here, the response itself is…not too terrible:

Dear Enquirer,

The UK Independence Party has confirmed its continued intention to vote against the ACTA directive.

The legislation is being voted on by MEPs and the party, which campaigns for withdrawal from the EU, has pledged to reject the legislation which will create an international legal framework

Deputy Leader Paul Nuttall MEP said: “We don’t want the EU making decisions on behalf of the UK at all but we also oppose ACTA because it’s the kind of legislation which is being pushed through at supranational level because it would never pass through national parliaments.”

“Civil society groups and developing countries were excluded from the discussions when the legislation was being drawn up and consequently there are many concerns about the impact ACTA would have on life saving drugs in the developing world.

“There are also serious concerns about the impact it would have on freedom of speech and expression which people fought and died to preserve.

“The liability of Internet Service Providers is also a reason why UKIP could not support the legislation in much the same way as libel laws in the UK, where newsagents were liable for the sale of newspapers or magazines if they were found to contain defamatory material restricted freedom of speech.”

Claims that UKIP have supported ACTA are grossly misleading. UKIP voted against a ‘motion for resolution’ in the European Parliament which is non legislative and non binding.

Mr Nuttall expressed sympathy with companies such as video games producers who have seen their products copied and shared for free on the internet but stressed that he did not feel that this legislation was the answer.
“UKIP understands the importance for companies to make profits, after all that is why they are in business. But this legislation has consequences which go beyond anti piracy laws and threaten fundamental rights.”

Yours sincerely,
Nigel Brown (P.A. to Paul Nuttall MEP)

I suppose this was more or less what we would expect UKIP’s position to be, given that they oppose the EU anyway. The response does also mention an important point which I neglected in my previous post, that ACTA will actually endanger lives.

All in all I don’t have much argument with what Mr Nuttall’s office has to say. Personally I find phrases like the following to be a little tasteless:

There are also serious concerns about the impact it would have on freedom of speech and expression which people fought and died to preserve.

Everybody knows people have died for freedom of speech and expression – and I’m fairly sure quite a large number of those people wouldn’t want UKIP using their memory as some kind of battering ram to get their points across. Still, that’s politics I suppose – and as somebody who objects to ACTA largely due to the potential impact on free speech and self-expression, I wouldn’t feel right if I were to criticise too harshly those who express the same concerns in a way I don’t much like.

February 19, 2012March 14, 2012

Boxing with Java

A bug was recently identified in a project I’m working on. Check the following code out:

private void addItem(Integer itemCode, Item itemFromDb){
    if(itemCode == itemFromDb.getItemCode()){
        //foo
    } else{
        //bar
    }
}

private void addItem(Integer itemCode, Item itemFromDb){

if(itemCode == itemFromDb.getItemCode()){

//foo

} else{

//bar

}

Naughty naughty. I had done a very silly thing and used == to test equality of Integer objects! As we all know, when comparing equality on objects we should be using .equals(). However, this bug was intermittent. Comparing Integer to Integer like this works. Sometimes.

Let’s see what’s happening here:

First, we need to check what happens when we compare two ints:

public static void main(String[] args) {
    compareInts();
}

private static void compareInts(){
    int a = 10;
    int b = 10;
    checkUnboxed(a, b);
}

private static void checkUnboxed(int a, int b){
    System.out.println("Comparing unboxed " + a + " to " + b);
    System.out.println(a == b);
}

public static void main(String[] args) {

compareInts();

}

private static void compareInts(){

int a = 10;

int b = 10;

checkUnboxed(a, b);

}

private static void checkUnboxed(int a, int b){

System.out.println("Comparing unboxed " + a + " to " + b);

System.out.println(a == b);

}

Output:

Comparing unboxed 10 to 10
true

This makes sense. A is of an equal value to B.

Now let’s compare two Integer objects:

public static void main(String[] args) {
    compareIntegers();
}

public static void compareIntegers() {
    Integer first = 10;
    Integer second = 10;
    checkBoxed(first, second);
}

private static void checkBoxed(Integer a, Integer b) {
    System.out.println("Comparing boxed " + a.toString() + " to "+ b.toString());
    System.out.println(a == b);
}

public static void main(String[] args) {

compareIntegers();

}

public static void compareIntegers() {

Integer first = 10;

Integer second = 10;

checkBoxed(first, second);

}

private static void checkBoxed(Integer a, Integer b) {

System.out.println("Comparing boxed " + a.toString() + " to "+ b.toString());

System.out.println(a == b);

}

Output:

Comparing boxed 10 to 10
true

Great – we have equal values, right? Where’s the problem?

Here:

    Integer first = 10;
    Integer second = 10;

1 2	Integer first = 10; Integer second = 10;

Change the values to some high number. Let’s say 1000:

Comparing boxed 1000 to 1000
false

~~Depending on your particular implementation of Java, the value required to trigger this behaviour may vary, but in my case, the equality result changes when a and b are set to 128.~~

UPDATE: As pointed out by Edwin Nathaniel in the comments, any Java implementation should cache Integer objects according to the following:

“Cache to support the object identity semantics of autoboxing for values between -128 and 127 (inclusive) as required by JLS.
The cache is initialized on first usage. The size of the cache may be controlled by the -XX:AutoBoxCacheMax= option.”

This means that the Integer cache limits are configuration dependent, not implementation dependent. Props to Edwin (who also has a rather delicious looking blog) for schooling me on this subject!

Let’s change the code a little and turn our primitives into objects when we do the comparison (this is what’s already happening, by the way, it’s just a little less obvious the way I’ve illustrated it here):

public static void main(String[] args) {
    compareInts();
}

public static void compareInts() {
    int a = 1000;
    int b = 1000;
    checkBoxed(a, b);
}

private static void checkBoxed(Integer a, Integer b) {
    System.out.println("Comparing boxed " + a.toString() + " to "+ b.toString());
    System.out.println(a == b);
}

public static void main(String[] args) {

compareInts();

}

public static void compareInts() {

int a = 1000;

int b = 1000;

checkBoxed(a, b);

}

private static void checkBoxed(Integer a, Integer b) {

System.out.println("Comparing boxed " + a.toString() + " to "+ b.toString());

System.out.println(a == b);

}

Output:

Comparing boxed 1000 to 1000
false

In case you missed it, the checkBoxed method is expecting Integer objects, not primitives. We pass it primitives, and autoboxing is applied by the compiler, cramming our primitives into objects and giving us a nasty surprise.

Autoboxing allows developers to forget about the tedium of converting between primitives and objects, resulting in tidier code and, in this particular case, more headaches. You don’t gain anything performance-wise as the compiler will still generate the ‘boxing’ code, but it does tend to make life more convenient.

If you want to avoid this problem, you can do the following:

Integer first = new Integer(10);
Integer second = new Integer(10);
checkBoxed(a, b);

Integer first = new Integer(10);

Integer second = new Integer(10);

checkBoxed(a, b);

Comparing these two using the checkBoxed method will always output ‘false’, because you are explicitly creating two different objects. The fact that they represent the same value is irrelevant to the JVM. It sees two different objects and tells you so.

You can also use the following comparison instead:

Integer a = 1000;
Integer b = 1000;
System.out.println(a.intValue() == b.intValue());

Integer a = 1000;

Integer b = 1000;

System.out.println(a.intValue() == b.intValue());

Perhaps the best way to avoid this problem is to be consistent and enforce the rule across your team. Keep in mind that you don’t always know how Bill has implemented his bit of code, and he doesn’t know how you’ve implemented yours – so decide how you’re going to deal with this potential pitfall and make sure you both keep it in mind. Unfortunately for me, I’m the only person working on this project so I can’t blame somebody else.

It’s worth pointing out that autoboxing is applied to all primitive wrapper types, not just Integers, so it is an important feature to keep in mind.

If you use Eclipse, turn on the following handy feature to help you find where autoboxing / unboxing could occur:

This will highlight your code with the following warning:

This is one of those features added to make your life easier. Unfortunately, people new to Java, or idiots like me, may not understand what is happening here and could be writing code laden with boxing issues. Only a good set of coding standards, and a decent code-review process, will help you catch these issues before they become a real problem out in the field.