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:       // My instructor circled this line        // His comment didn't really make sense, it said "no commals -1/4 " ???        // It either says that or "no commats -1/4" ???        // Did he mean "no commands" ? Or? Does anyone have any idea?

Probably "no comments" - you didn't include any documentation on the method or explanation of what you were doing.

Or use varargs: change the declaration of min from
   public static int min(int[] numbers) {
to
   public static int min(int... numbers) {
and then you can use code like
   assertEquals(1, min(4, 1, 10, 99));
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.

If n is negative, % can return a negative number, in this case, -1.  See examples:
   public static void main(String[] args) {        System.out.println("         X          Y      X / Y      X % Y    X MOD Y");        show(3,2);        show(-3,2);        show(5,5);        show(5,7);        show(-5,5);        show(-7,5);    }    private static void show(int x, int y) {        System.out.printf("%10d %10d %10d %10d %10d%n",                x, y, x / y, x % y,                BigInteger.valueOf(x).mod(BigInteger.valueOf(y)).intValue());    }

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.

Well, even if the goal is to identify an odd number, once you put that goal in a method name, which is better?
private boolean isOdd(BigInteger n) {    return n.mod(BigInteger.TWO).equals(BigInteger.ONE); }
or
private boolean isOdd(BigInteger n) {    return n.mod(BigInteger.TWO).intValue() == 1; }
or
private boolean isOdd(BigInteger n) {    return n.testBit(0); }
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...

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
if ((n & 1) == 1) {
would be
if ((n.and(BigInteger.ONE)).equals(BigInteger.ONE)) {
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...

BigInteger.testBit(int) is worth a look here.

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...

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.

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:
int result; if (condition) {    result = 1; } else {    result = 2; }
can be replaced with a ternary:
int result = (condition) ? 1 : 2;

Similarly, a traditional switch like
int result; switch (input) {    case "FOO":        result = 1;        break;    case "BAR":        result = 2;        break;    default:        result = 3; }
can now be replaced with:
int result = switch (input) {    case "FOO" -> 1;    case "BAR" -> 2;    default -> 3; };

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.

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:
int result = switch (s) {    case "Foo":        break 1;    case "Bar":        break 2;    default:        System.out.println("Neither Foo nor Bar, hmmm...");        break 0; };
And the Java 13 version would be
int result = switch (s) {    case "Foo":        yield 1;    case "Bar":        yield 2;    default:        System.out.println("Neither Foo nor Bar, hmmm...");        yield 0; };
Or using arrow notation... Java 12:
int result = switch (s) {    case "Foo" -> 1;    case "Bar" -> 2;    default -> {        System.out.println("Neither Foo nor Bar, hmmm...");        break 0;    } };
or Java 13:
int result = switch (s) {    case "Foo" -> 1;    case "Bar" -> 2;    default -> {        System.out.println("Neither Foo nor Bar, hmmm...");        yield 0;    } };

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:
   default -> {        System.out.println("Neither Foo nor Bar, hmmm...");        0;    }
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.
   default -> {        if (condition) {            System.out.println("first default value...");            0;        } else {            System.out.println("other default value...");            -1;        }    }
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...

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...