Win a copy of Secure Financial Transactions with Ansible, Terraform, and OpenSCAP this week in the Cloud/Virtualization 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

I use JDK 16 for hobbies, now that it's available, and JDK 11 at work.  We will not upgrade that until (a) JDK 17 comes out, (b) SAP Commerce (formerly Hybris) includes JDK 17 as their JDK, and (c) we get around to upgrading our SAP Commerce installation again.  Which I will be pushing to happen as soon as possible, but it may be a while.
1 week ago
No methods in that code are overriding anything.  There are two constructors, where the Sub1() constructor is implicitly calling its superclass constructor Super1().  But that's not overriding, and the rule about exceptions in the throws clause when overriding has no effect here.

Note that if Super1() had been declared to throw a checked exception, Sub1() would have to throw it too, because of the implicit invocation of the superclass constructor (and the fact that there's no way to wrap that in a try/catch).  But that wasn't in the question as asked.
I think for records they wanted to make sure that the definition of what's in the class was clean and concise, and all in one place.  Both for simplicity when reading it, and to be able to make guarantees about how to serialize it or deserialize it.  They didn't want to be able to pollute the class definition by extending some other class, or by having an implicit "this" reference to another class.  So they wanted it to behave like a static class, and yet they also wanted to make it easy to declare a record at whatever level you need to - e.g. just before a stream operation where you want to operate on some sort of tuple-like structure, you just declare your new tuple with names for the fields, and run with it.  

Prior to this, there was no real use case for mixing static classes and local classes, so they disallowed it, ostensibly to keep things simple.  Now they do have a use case, so they allow it, with some limitations.
1 week ago
@Campbell, yes the ">" were all supposed to be ">=";not sure how I overlooked that.

I like the idea of lining things up vertically like you show, and I used to do that.  But in practice, I found I was always fighting with automatic code reformatting.  I haven't seen a formatting tool that can tell the difference between extra spaces that someone put in accidentally, and those that were put there intentionally for aesthetic effect.  So I've generally abandoned such attempts.

Cay Horstmann's own style guide puts his style nicely: "Opening and closing braces must line up, either horizontally or vertically."  He also manages to not use any more lines than K&R style, letting the opening brace share a line with the next line... which is weird in its own way.  But I like the consistency and simplicity of "either vertically or horizontally"
@Miles, I tend to prefer that style.  Not sure I like it as a requirement.  But personally, I would probably make that change whenever I notice it's possible.

@Paul, yes that's a good counterexample.  But, it's also very possible that as those two if/else branches grow, they will move apart in ways where they shouldn't have, because of unnecessary code duplication that goes unnoticed by future maintainers.  Someone will fix a NullPointerException in one branch, not noticing that the same fix should be applied to the other branch as well... that sort of thing.  I prefer to minimize duplication in the first place (and/or minimize it later, when I notice it's possible) - if we need to expand it later because of changing requirements, we can.    

Clemonte Johnstone wrote:1) Why throws Exception is not allowed if supplemented below?

Because when you override a method, the new method may not add any new checked exception types.  

In your example, throwing ArrayIndexOutOfBoundsException is OK, because (a) it's unchecked, and (b) it's a subtype of IndexOutOfBoundsException.  You're not throwing a new checked exception; you're saying you won't throw any IndexOutOfBoundsException other than the more specific subtype ArrayIndexOutOfBoundsException.  That's allowed, even if these were checked exceptions (which they are not).

But throws Exception is definitely a new type of checked exception.  It includes the unchecked IndexOutOfBoundsException and ArrayIndexOutOfBoundsException, but also may include many other things like IOException.  It could be anything.  Definitely not allowed by the super method declaration.

Clemonte Johnstone wrote:2) Can we say that we are overriding the method declaration in the Subclass?

Yes.  You are overriding it, providing a method with the same signature.  You are not implementing it, since it's still abstract, no implementation, but you are overriding it.  This can be done to modify the method in a few allowed ways, including (a) making the method more accessible (not less), (b) changing the return type to a more specific subtype, if applicable, (c) changing the throws clause to a more restrictive (not less) list of checked types (plus any unchecked types you like), and (d) adding a new JavaDoc comment (which hopefully modifies but does not violate the contract of the super method -- that's up to you though, the compiler doesn't care)
To be fair, strict adherence to "always use curly braces" would mean that this:

should become this:

Now that seems a bit excessive; we generally agree on making an exception for else if:

While this is fairly standard Java style, I personally would like to make it more compact.  If we insist on always using braces (except of course for else if) then we could still do:

(I would note that the introduction of lambdas has made me much more tempted to put braces on the same line for short statements.)
Then too, I am a big fan of using ternary operators like this:

Which may be less "readable"  to people not used to seeing it.  But I find readability is often subjective, and based on what you are used to seeing.  I encourage people to expand their notion of readability to include chained ternary operators, mimicking the else if structure we already accept.
I second Rob regarding using the command line.  Focus your efforts there first... different people will have different IDEs configured different ways, and it will be harder for us to understand what's going on in your IDE.  But if you show us the command you run and the error message(s) you receive, we can give better feedback.

As for documentation, I would say that open-source projects in general often have very poor or bare-bones documentation.  Maven is pretty good in comparison to many.  But yeah, there's still plenty of room for improvement I think.
1 week ago
I'm not sure why the formatting of this post is getting messed up... I didn't put in any < br > tags, and it loks fine in the editor before I submit.  But something happens after that.  Anyway...

Miles Jiang wrote:We all know the standard if-else structure is like if -> else if -> else:

<br /> Well no, I don't know that one.  The final "else" can't have any condition: <br /> <br /> I'm not sure what would make it a bad coding practice.  Well, people will be happier if you use braces around each "then" section.  But that's not what you're asking about. <br /> <br /> The compiler speed won't be an issue, really.  More relevant are readability, minimizing possible programmer error, and execution speed.   <br /> <br /> In a case like this, two things that jump out to me about the list of conditions are that it's  exclusive (we can't have  more than one condition true) and exhaustive (there must always be one true).  In such cases, I see no reason not to use a simple else for the last case, since there's nothing new to test.  If you've already tested for a > 0 and a < 0, the only remaining possibility (for int at least) is a == 0, no need to actually test it.  But some people may find it more readably to say it explicitly.  I would usually comment it: <br /> <br /> On the other hand, sometimes you may think you have an exhaustive list of the possibilities, but you don't.  If variable a had been a double, then it could possibly be NaN, not a number.  In which case a > 0, a < 0, a==0 are all false.  So it may be best to explicitly state the condition each time, just in case one of your assumptions is faulty.
Have you learned about the equals() method, and the difference between equals() and == ?
w00t!   Thanks, Ranch, and thanks, Yehonathan!
Assuming you've spelled the filenames correctly, most likely there is an issue with what directory you're in.  I suggest replacing this:


This should tell you where the file is expected to be found, and you can compare that with where it is actually located.
2 weeks ago
Yes, modifying as needed.  The current plan is to do this both with records and map-of-maps, and see how it can look.  Though the timeframe is TBD, depending on other real-world intrusions like my day job.
2 weeks ago
Hey, don't be bad-mouthing our holy wars!    I am ready to fight about curly braces any time, anywhere!  (I'm more flexible on OO principles, however.)

These look fun.  I'm going to have to look into these from the perspective of what's the best way to do this in Java.  And/or Kotlin.

Perhaps a moderator will add this thread to the OO forum as well?
2 weeks ago
That's correct.  The exception isn't just for anonymous classes though - more generally, the compile doesn't figure out everything simultaneously; it figures things out in steps.  Because assignment operators are lowest in precedence, the compiler will figure out what the assignment operator does (and if any type conversion needs to happen) only after it figures out the type of the left side and the type of the right side.  Usually we don't need to isolate the individual steps when we think and talk about this, unless something complex is happening in one of the operands.

Put another way, rule A shouldn't mean, take out the generic and re-evaluate the whole expression without it.  It just means, pretend the generic isn't there, for purposes of deciding what the assignment operator does.  Your right-hand side was a Predicate<String> and the left was a Predicate, OK, so the resulting variable is a Predicate, OK.  But that does't force re-evaluation of the right hand side as a Predicate.

The other general rule is, when you mix raw types with generics, weird and confusing things happen, and so you should avoid mixing raw types with generics.  Or just avoid using raw types at all.