torkell: (Default)
[personal profile] torkell

Bonus extra post, to avoid [livejournal.com profile] talismancer mocking the lack of content today. That said, he hasn't updated yet today...

There's been a few guesses at monday's Java puzzler. [livejournal.com profile] talismancer is right in that the code won't work. [livejournal.com profile] olego and [livejournal.com profile] pteppic took this a bit further, and correctly guessed that it'd throw an exception of some sort. Specifically, you get the following output:

Adding java.lang.Object@addbf1 at index 0
Adding java.lang.Object@42e816 at index 1
Adding java.lang.Object@9304b1 at index 2
Adding java.lang.Object@190d11 at index 3
Adding java.lang.Object@a90653 at index 4
Adding java.lang.Object@de6ced at index 5
Adding java.lang.Object@c17164 at index 6
Adding java.lang.Object@1fb8ee3 at index 7
Adding java.lang.Object@61de33 at index 8
Adding java.lang.Object@14318bb at index 9
Removing java.lang.Object@addbf1
Exception in thread "main" java.util.ConcurrentModificationException
	at java.util.AbstractList$Itr.checkForComodification(Unknown Source)
	at java.util.AbstractList$Itr.next(Unknown Source)
	at Foo.emptyBarList(Foo.java:15)
	at Foo.main(Foo.java:24)

Line 15 is for (Object o : barList) {

At first this seems like an odd place to get an exception - there's no obvious code in this line. But it makes sense when you realise that the Java compiler rewrites that line into something like:

Iterator<Object> it = barList.iterator(); while (it.hasNext) {Object o = it.next();

Most of the standard Java collections explicitly state that structural modifications to the collection will generally cause any iterators to throw a ConcurrentModificationException. Fortuantly there is a way round this: you're permitted to modify the list via methods on the iterator object (like Iterator.remove()). The concurrent collections also won't throw an exception, as the iterators in those are designed to be fully thread-safe and cope with (but don't necessarily show the result of) structual changes.

The fix in this case is easy enough: rewrite the loop to explicitly create an Iterator object and call the remove() method on that. And then add a unit test so that the method is actually tested, rather than being left as a hidden bug until someone does a completely unrelated change and actually adds code to call it!

???

Date: 2011-11-12 05:45 pm (UTC)
From: [identity profile] allegramente.livejournal.com
I always thought Java was a hot tropical island with lots of coffee, not a hot topical topic with lots of code. The Java that I know is words like selamat datang (hello) . I am taking up the blog-a-day challenge; if I post twice a day I should have caught up by selamat hari natal and you can send me an extra present

January 2026

S M T W T F S
     123
45678910
11121314151617
18192021222324
25262728293031

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated May. 7th, 2026 05:28 pm
Powered by Dreamwidth Studios