Michael Stiefler

Greenhorn
+ Follow
since Sep 25, 2018
Michael likes ...
Eclipse IDE Oracle Java
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
2
In last 30 days
0
Total given
0
Likes
Total received
4
Received in last 30 days
0
Total given
8
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Michael Stiefler

If you need to change something but don't understand what you have already, it's probably the best idea to hire someone who does.


Mike
5 years ago
Congratulations!


Mike
5 years ago
Congratulations on those great scores.


Mike
5 years ago
What Seastik Dey said.

Java API specifies that the "substring" method of the String class with one parameter only specifies the (0-based) start index of the substring to extract from the string: https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#substring-int-
The resulting string will last from that start index to the very end of the String.
Instead you need the overloaded two-parameter version of the same method, specifying the (0-based) end index as second parameter: https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#substring-int-int-

Swastik Dey's code should do the trick so all credits go to him.


Mike
5 years ago
Indeed it looks very well written, quite comprehensive and precise, what more can you ask for?
Enjoy your copies, I'll just buy me one in that case  


Mike
5 years ago
Looks like an awesome book to dive into all the shiny new features of Java 8 and beyond.
Would love to get hands on a copy ;-)

Cheers!
Mike
5 years ago
98 on OCA, welcome to the Club, great score
Good luck for your OCP Exam!


Mike
5 years ago
Of course you can use String methods in another class: On objects of type String.

The compareTo method in DVDInfo returns...

...where both "title" and "d.getTitle()" are strings, so you call the compareTo method of the String class here.


Mike
You declare your dvdlist to hold elements of type dvdInfo here:


Therefore when you add an element, the object's / element's type must be dvdInfo:



Mike
5 years ago

Campbell Ritchie wrote:I didn't notice you have been given an assignment showing public fields; I would regard public fields as a poor design feature in any code.


Correct, I've been quite surprised when I saw that too


Mike
5 years ago
The question indeed looks a bit cryptic.
From what I get, you should write the static method "addStudent" so that it creates a new instance of a "Student" object, and additionally create two new instances of "AssignmentMarks" objects which reflect the "mathsMark<n>" and "englishMark<n>" parameters handed over to your static method, store them in the regarding "mathMarks" and "englishMarks" fields of your newly created "Student" object and then finally add that newly created "Student" object to "the list of students", whatever that is.

It'd probably be something like this:



Mike
5 years ago
That's a matter of taste, isn't it?
In my eyes the code clearly gives away that it's not meant to be real-world "to be distributed" working code of a bigger, new project, but just some made-up thing for testing purpose.
In such case, to a questioner it might be a bit frustrating when you ask a question and all you get back is pointers to each and everything that could be improved on your code, but the answer to your question.
Nothing wrong with giving hints, I guess any reasonable coder will appreciate it, but to me they taste much better when being shipped together with the answer to the question having been asked.

That being said, in order not to leave further questions unanswered...

Campbell Ritchie wrote:

Michael Stiefler wrote:Check your file with a hex editor and you will see your "\n"s.

Please explain more; it is likely that KC doesn't know what linefeed characters look like in hex.


Not much of rocket science here, line breaks ("\n") are ascii 10, mostly displayed as "0A" in hex editors. Carriage returns ("\r") are ascii 13 or "0D" respectively.
The problem is that DOS/Windows expects \r\n, Unix/Linus expects \n, older MACs might expect \r (rule of thumbs, exceptions might exist).
Several ways exist to deal with this, e.g. like CR mentioned we have the formatted "%n" output like in "System.out.printf("I %n am %n a %n new %n line");", we have "System.lineSeparator()", we have "System.getProperty("line.separator")" for older Java versions and eventually on the BufferedWriter we have the "newLine()" method.

Campbell Ritchie wrote:Don't call close() at all. Use try with resources instead. There is no guarantee that a plain simple close() call will succeed, but try with resources is the equivalent of a finally, which can be relied upon to close the resource.


On Java 7 and older you don't have try with resources.

Campbell Ritchie wrote:Never close anything reading from System.in.


Somewhat unrelated, did anyone mention System.in before?

Campbell Ritchie wrote:
If you are going to call close() explicitly, do it on the highest‑level object, e.g. the BufferedReader, not the FileReader.


Of course.
I was only trying to explain what happens technically.
When you call close() on the FileReader which was used to create the BufferedReader, then you technically close the stream that feeds both.


Mike
5 years ago
That line...

...is probably the most confusing thing for beginners when talking about the difference between pre- and post-increment operators.

This is what you get:

...but...


The first part is quite intuitive, we see the pre-increment operator.
When the line "x = ++x;" is being processed, first of all x will get incremented by 1 (so it's 11 now), and then it will get assigned to itself.

In the second part, we use the post-increment operator instead.
When the line "x = x++;" is being processed, what happens is that Java will split the expression in two halfs, one being the term on the right hand side of the assignment operator ("x++;"), the other being the assignment itself ("x =").
The term on the right hand side needs and will be evaluated first.
Java sees "x++" and acts in the post-increment way, thinking "okay, I shall increment x, but for the calculation of this expression I will calculate on a copy of the old value of x instead".
This unrolls to something like this pseudo-code:


Why "x = tmp"? Because in the term "x++" we don't do any other calculations but post-incrementing x (which is done on the 2nd line of our pseudo-code, "x = x + 1"), but to finish the calculation, we proceed on our temporarily stored "old" value, and since there is no other calculation to be done, x gets it's old value reapplied.

Finally, after having evaluated the right-hand side expression that way, eventually Java will do the assignment operator, which now evaluates to nothing more than "x = x".


Mike
5 years ago
You're of course right with everything you say Campbell Ritchie, I have just been trying to answer the OP's questions without going all the way to a perfect world because...

Campbell Ritchie wrote:
Where did you get that code from? It reads like code out of a very old book.



...you happen to meet old code more than you want in real life, and have to deal with less-than-optimal results as much, because not always will you have the time and resources to rebuild everything from scratch "just" in order to do it right, I mean really right.


Mike
5 years ago
Great score Nisam, my regards.
One question: Why does one take the Java SE 7 exam these days when Java SE 8 is around for such a long time?
Not trying to belittle what you've achieved, I'm just wondering what reason might be behind...


Mike