Win a copy of OCP Oracle Certified Professional Java SE 11 Programmer I Study Guide: Exam 1Z0-815 this week in the Programmer Certification forum!

Mike Simmons

Master Rancher
+ 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

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.
1 week 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.
1 week ago
If n is negative, % can return a negative number, in this case, -1.  See examples:
2 weeks 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.
2 weeks 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...
2 weeks 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...
2 weeks 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:

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...
2 weeks ago

Tim Holloway wrote:and since I'm pretty sure that "int.class" isn't valid

It is valid - it's how we talk about parameter types and return types with reflection, allowing us to distinguish between int.class and Integer.class.  There's even a Void.class just to allow us to know that a method returns void.
2 weeks ago
Is there a reason why you think you need iteration functionality in AtomicLong?  This sounds a bit like asking why the car's steering wheel does not have braking technology.

salvin francis wrote:The only change I love about it was introducing strings to it in Java 7.

Hey, what about switching on enums?  Also a good change, I think.

salvin francis wrote: I am still not able to grasp my mind yet over a switch returning a value instead of just comparing.

I think it's a bit like replacing a traditional if / else with a ternary operator.  Consider how code like this:

can be replaced with a ternary:

Similarly, a traditional switch like

can now be replaced with:

salvin francis wrote:In my head, a switch was a very elegant  way of writing if - else if - else  statements.

It still is - but now, there's a more elegant, more compact form.
3 weeks ago
First, I misremembered earlier when I said earlier (Java 12) used return instead of yield.  Actually, Java 12 used break instead of yield.  So in Java 12 you would have had:

And the Java 13 version would be

Or using arrow notation... Java 12:

or Java 13:

Campbell Ritchie wrote:And it would mean adding another keyword/reserved word You could do the whole thing with -> alone.

I agree they're adding a new reserved word, which can be troubling.  But even when using ->, if the thing after -> is more than one line, we need braces {} around it... and then we also need some keyword for the thing we're returning, or breaking, or yielding. Or whatever.

They could have instituted a rule that makes the last statement/expression in a block into the de facto return value of the block, without needing it explicitly returned.  Like in Scala and other languages.  Then that final default case could be written as:

No need for any keyword then... but that would be confusing for Java programmers not used to that.  And what if there's more than one possible value to return?  E.g.

Those numbers just floating there look wrong to a java programmer... having some keyword there to like return, break or yield does help readability, I think.  Or maybe it's all just a question of what we're used to seeing...
3 weeks ago
Yeah, earlier they were using "return" instead of yield - but that was confusing too, since we're not returning from a method, or a a lambda, just a switch.  Someone thought it would be clearer to use a different term I guess.  "Yield" is used in some other languages like Python and Ruby, so now it's found its way to Java...
3 weeks ago