Junilu Lacar

+ Follow
since Feb 26, 2001
Junilu likes ...
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
Columbus OH
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 Junilu Lacar

Ilona Kot wrote:the naming of the method was from a tutorial off Udemy

Then I would seriously question the quality of that course. This is such a basic thing in Java and if you are misled in this regard, what other things does it mislead you on? On the other hand, you may have misinterpreted the content. Did the tutorial instruct you to make the method return a String and make it private or was that your own decision?
17 hours ago
And welcome to the Ranch!
20 hours ago
Quite a few problems with this code.

First, it doesn't follow convention for a method with a name that starts with "set" -- such a method will be expected to take a parameter which is the value that you want to set the named attribute to. As such, these methods are normally declared with a void return type. Also, they are usually public. That is, something like this:

Second, the method sets the value of a local variable. The scope of this action and value is limited to the method itself. That is, nothing outside of this method will know anything even happened with the departmentChoice. This is the reason you have to return it from the method, breaking semantic convention for a setter method.

Third, you are mixing in user interaction. A setter method's purpose is to set an attribute. User interaction should be done separately. That is, interact with user to get the value, then call the setter method to set the attribute value. These are kept separate to facilitate code maintenance, testing, and debugging. Combining the two actions violates a basic design principle: Single Responsibility.
20 hours ago

fred rosenberger wrote:Shouldn't you add in a check for year > 1752?

If you're looking to tackle scope creep, sure. But why stop at 1752? You'd have to add locale, too, since moving to Gregorian calendar didn't happen universally at the same time, at least not according to this: https://en.wikipedia.org/wiki/Old_Style_and_New_Style_dates
3 days ago

Sarah Jay wrote:For Integers, I couldn't  execute the below code

You're right, that should be
4 days ago
Not quite there. You can use either, actually. It's not about + for String and , for numbers. These work, too:

The difference really is that , adds a space. Look at the output of these two print statements carefully:
4 days ago
It's a demonstration of the extent to which generics can help the compiler guard against type mismatch errors.

If you added this:

and tried to write this:

you'd get a compile-time error on line 4. The example shows that even though the liquid field in Glass<T> does not say exactly what type T is, the compiler has enough information from the Glass<Beer> declaration to figure out that the Juice j = mug.liquid assignment statement is not valid. Again, that determination is made from the Glass<Beer> declaration; the field declaration T liquid in the Glass class doesn't provide enough information.
1 week ago
You may not have been taught how but my answer to "Does this looks good?" is "Does it pass all its tests?"
1 week ago
Welcome to the Ranch!

Why would this be urgent? Please note that this site is manned by unpaid volunteers (is there any other kind?) so anything marked "Urgent" may or may not translate to a speedy response.
1 week ago
Experimented with some more tweaks and I got it to compile and run but I don't know if I'm fully understanding the mechanics yet.

Here's my experiment: https://repl.it/repls/SpecificLightblueMiddleware

It does appear that Stephan is correct though.
1 week ago
I tried it just now and you're right about the generics having nothing to do with it.
1 week ago
It seems the difference comes down to the use of generic type arguments but I'm not sure yet. It seems to me that the crux of the matter is around resolving the target reference:

JLS wrote: The target reference of an instance method (§ may be provided by the method reference expression using an ExpressionName, a Primary, or super, or it may be provided later when the method is invoked.  ... Evaluation of a method reference expression produces an instance of a functional interface type (§9.8).

1 week ago
i'm not convinced that's what's happening though. I've been going through the JLS section on Method Reference Expressions https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.13 to see which rules apply here but haven't been able to find anything yet. This is a good question.
1 week ago
Try looking in "Method Invocation Expressions" https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.12

'the first bullet point under section 15.12.1 explains the "comb rule," which is what applies in this case.
1 week ago
There are actually better ways to create a histogram with steams than what I showed above though. Just search for java streams histogram
2 weeks ago