Mike Simmons

+ Follow
since Mar 05, 2008
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Rancher Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Mike Simmons

Day 3 was the most fun so far.  I had a slightly over-engineered solution to part 1 with a subtle off-by-one error that was hard to catch because I obfuscated it... but once I fixed that, the solution also worked pretty well for part 2 as well with minor adaption.  @Tim, thanks for reminding us about Advent.
The ResultSet is capable of containing more than one row... but you have to call next() more than once to access the other rows.  Usually this is done with a while statement.  Simply change your code here:

to this:

Tim Moores wrote:The compiler isn't as smart as you :-) If the return statements are hidden in the midst of "if" statements, it's not clear during a static compilation that one will ever be executed.

Well... the compiler can follow that.  The problem is, any time you have a return inside an if statement, it's only guaranteed to return if there's a return in the if and in the else.  And if there's no else, then there's no guarantee of a return.

In that first method, there is a return in the if, and in the else.  That's fine.  But the real problem is, the whole thing is inside a for statement.  And as far as the compiler is concerned, that for statement is not guaranteed to execute even once.  What if the array length is zero?  Then there's no return.  Even if you can prove to yourself that a for statement will execute at least once... the compiler will always assume that a for loop, or while loop, may not execute at all.  And therefore returns in the loop are not guaranteed to execute.

Tim Moores wrote:(The indexOf method looks fishy, by the way. It'll never go beyond index 0, because it returns no matter what.)

Agreed, this is another problem.

Tim Moores wrote:In the second method it's even less clear that a return will be executed before execution reaches the end of the method. What happens if "continue" is executed at the end of the loop?

Here too, the real problem is that the whole thing is in a while loop, which may never execute.  So we need a return after the while, to ensure there's a return.
1 week ago
As a fellow Hybris developer, I'm not sure what's going on here, because FlexibleSearchService.search() should support this.  Here's the method declaration (from the interface):

So yes, T is a type variable declared in the method, not elsewhere, so basically the compiler should be free to infer any type you declare here.  You can say

and the compiler will be happy with that (assuming necessary imports) even if the actual return type is not a SearchResult<Foo> but a SearchResult<Bar> - that will be discovered only at runtime, not compilation time.  And the part that errors out will not be this line, but the code that implements it, probably DefaultFlexibleSearchService.convert(SearchResult) and convertRow(Object), which insert casts to T.

At least, that's the way it should work.  Is it possible there was another version of this code recently, that used a SearchResult<Object> instead?  Is it possible there's still an old class file lying around somewhere?  I would do an ant clean all to make sure it's all built fresh.  Also, are you using an IDE?  IntelliJ with a suitable plugin like Integration for SAP Commerce?  That may help if you're not getting a clear view of the classes and methods you're working with.  If problems persist, what version of Hybris are you using?
2 weeks ago

Campbell Ritchie wrote:We see this sort of question every now and again and I am starting to wonder whether Strings have natural orderings or not.
but all that sort of thing makes me think there isn't one total ordering for Strings at all.

Right, there is no single ordering for strings that makes sense for everyone, and Collators are probably the best way to get locale-specific orderings that make sense for various purposes.  However, the term natural ordering is defined in Java to mean the ordering determined by the compareTo() method, if implemented.  String implements Comparable and so has a compareTo() method, therefore it has a natural ordering, which is the ordering determined by that method.  Whether that order really makes sense or not, in various contexts, is another question.  But it is the natural ordering, by definition.
2 weeks ago
Yeah, the actual compiler warning from raw types is pretty ignorable anyway if you want to ignore.  I'm talking about me being personally offended that anyone would still use raw types.  

I'm happy with the constructor deprecations.  Will be very surprised if they actually get *removed*.  But deprecated?  Sounds good to me.

And @Campbell, yes your reminiscences are cause for concern.
Well, you don't *have* to.  You just get warned if you use new Integer().  Personally I'd be more disturbed by the use of a raw type.

Jon Fil wrote:

Probably "no comments" - you didn't include any documentation on the method or explanation of what you were doing.
3 weeks ago
Or use varargs: change the declaration of min from


and then you can use code like

Note that using varargs like this, you don't need {} at all to declare an array - you just provide the list of arguments, and the JVM wraps them in an array for you.
4 weeks ago
If n is negative, % can return a negative number, in this case, -1.  See examples:
1 month ago

Campbell Ritchie wrote:

Mike Simmons wrote:. . . the % operator on ints . .

Remembering that n % 2 == 1 doesn't reliably find odd numbers.

True - not that anyone had written n % 2 == 1, of course.

This does remind me why I thought testBit(0) was much more readable in the first place.

Campbell Ritchie wrote:Has BigInteger got a mod() method? Yes, it has, though I confused myself by looking for BigDecimal at first. I notice that the BigInteger#mod() method doesn't have the problem you would get with n % 2 == 1

Yes it exists, and has all along; that's why I used it.
1 month ago
Well, even if the goal is to identify an odd number, once you put that goal in a method name, which is better?



Maybe more people will be familiar with using the % operator on ints... but here for BigInteger, I'm not sure those techniques are any more readable than testBit().  Either way, we still need your interpretation step, to understand what (n & 1) == 1 is doing.  Whether we call it testing for oddness, or testing a bit, eh... six of one, half a dozen of the other...
1 month ago
I would also note that, if for some reason we were to translate the code to BigInteger without understanding the intent, a more correct translation of

would be

That would work if needed, though it would be nicer to do as Junilu suggests and understand the intent first, to get a clearer version...
1 month ago
I think int.class and the like have been around since JDK 1.1, when Class.getMethod() and the Method class (with getReturnType()) first came out.  Because that's the point at which they had to decide how or whether to distinguish between an int and an Integer... and since it was Sun, whatever they decided then would have stuck with us for ages afterwards.  I don't think JLS first edition had any class literals, but here's a link to the second edition: http://titanium.cs.berkeley.edu/doc/java-langspec-2.0.pdf

15.8.2 Class Literals

A class literal is an expression consisting of the name of a class, interface, array,
or primitive type followed by a ‘.’ and the token class. The type of a class literal
is Class. It evaluates to the Class object for the named type (or for void) as
defined by the defining class loader of the class of the current instance

Seems like "or primitive type" was there early on...
1 month ago