• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Rob Spoor
  • Bear Bibeault
Saloon Keepers:
  • Jesse Silverman
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • Al Hobbs
  • salvin francis

Sybex CSG 11: Errata in the OCP Java SE 11 Developer Complete Study Guide

 
Ranch Hand
Posts: 113
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The format() and parse() methods of the NumberFormat class are not static methods of this class as suggested on pages 774 and 775 of the study guide. This suggestion is made in the following quoted remarks from the study guide: "The NumberFormat.format() method formats the ..." (on page 774) and "The NumberFormat.parse() method accomplishes this ..." (on page 775).
 
Marshal
Posts: 26912
82
Eclipse IDE Firefox Browser MySQL Database
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It's quite common to describe methods in that way, rather than having to say "The format() method of the NumberFormat class..." Usually that phrasing isn't intended to imply that the methods described in that way are static. (You'll note that the text doesn't explicitly say they are static.)
 
Nyeng Gyang
Ranch Hand
Posts: 113
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for responding to my post.

It is my considered opinion that describing methods in this way, which you say is quite common, is a convention that is both confusing and inefficient. Let me speak for myself, at least, as follows: Before I saw those methods being described, as though they are static methods of the NumberFormat class, using a means you inform is a convention for describing methods, I had already checked the official Java documentation and known that they are instance methods. This confused me, hence the confusion caused by this bizarre convention. Consequently, I had to expend some to ensure that the methods are truly instance and not static methods; this was not a useful utilization of those minutes I spent making this confirmation, hence the inefficiency of the bizarre convention.

Even though I already know the kind of error the Java compiler reports for invoking a non-static method from a static context (including either from a static method or by a class), after reading your response, I nonetheless ran code to confirm that the compiler is going to report the same (or similar) error if I invoked one of these instance methods by the NumberFormat class and obtained the following confirmation of my conjecture:
In short, the convention to describe instance methods the way they have described in the study guide here is not a useful one, but that is my own opinion, of course.
 
Paul Clapham
Marshal
Posts: 26912
82
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Nyeng Gyang wrote:It is my considered opinion that describing methods in this way, which you say is quite common, is a convention that is both confusing and inefficient.



I can certainly agree with that, at least with the "confusing" part. I would agree with you that it would be worthwhile for the authors of the guide to avoid that usage and say "the format() method of the NumberFormat class" instead. However I've described non-static methods in the "confusing" way myself, including here on the forums, so you should expect to see it in casual usage.
 
author & internet detective
Posts: 40798
829
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I stand by how we wrote it. Sometimes being concise makes things more memorable. Also, pages 774/775 have a code snippet showing them used as instance methods. So there is context and you aren't expected to know they are instance from memory. The code examples tell you.
 
Nyeng Gyang
Ranch Hand
Posts: 113
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
While it is true that code snippets show the methods being used as instance methods, the use of the var type makes this fact harder to see, particularly for a learner coming across methods and classes for the first time. Good pedagogy adequately understands that an programmer, who is experienced in a particular programming language, reads and understands code better and quicker than a programmer who is learning the language.
 
Jeanne Boyarsky
author & internet detective
Posts: 40798
829
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree. We used var *all over* on purpose.  I don't use it nearly that much in code at work. The reason being the exam tests var and people are unfamiliar with it. So sprinkling var everywhere avoids unpleasant surprises on the exam.
 
Nyeng Gyang
Ranch Hand
Posts: 113
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I get the good pedagogy you used throughout the book, i.e., your use of varied examples and coding styles. However, kindly do consider the fact that external sources, including my access of the Java documentation and the response provided by Paul Clapham above, provided the clarification that the following notation does not mean that the format() method is a static method of the NumberFormat class: NumberFormat.format(). My own opinion is that this is not one of those pieces of fact that a reader of your book ought to learn from sources external to the book, rather than from the book itself.
 
Saloon Keeper
Posts: 1645
61
Eclipse IDE Postgres Database C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There is, I believe a happy medium that doesn't get long-winded and is less likely to confuse readers:
NumberFormat's .format() method
is shorter than what I would usually write (no surprise, huh?)
NumberFormat's .format() instance method

But is hardly longer than writing the following, which I agree with the OP does yell "Static Method" when one sees it.
NumberFormat.format()
 
Jeanne Boyarsky
author & internet detective
Posts: 40798
829
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Jesse: Oh, that's inviting the publisher to mess up the font

If I had to be wordy, I'd say "the format() method on NumberFormat. But NumberFormat.format() is more concise which will make it easier to remember come test time. I reiterate that there are code examples right by this. So it isn't a surprise the method isn't static. It is also a good idea to write some of your own code so you get some muscle memory with these APIs.

Ultimately, the nice thing about opinions is that there are many of them. Neither of us is right or wrong here.
 
Jesse Silverman
Saloon Keeper
Posts: 1645
61
Eclipse IDE Postgres Database C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It depends on context.  In studying Jeanne (and Scott's) book, the tables where every single entry are all static methods, or other ones where they are all instance methods, saying more repeatedly is just a waste of space, it is good they don't do that.

If there is a summary of a class with a mix of static and instance methods, saying ClassName.methodName() for short when referring to the instance ones (which is never legal syntax to actually type) would only be slightly less confusing than saying instance.staticMethodName() which we also get to see just to make sure we are paying attention, and is syntactically legal tho bad to do.

None as bad as this one, which I can't forget since I saw it when some trivia-obsessed smart-alec somewhere on the internet put it in some mock exam question:
jshell> String s = null;
s ==> null

jshell> s.valueOf("CornerCase")
$28 ==> "CornerCase"
No NullPointerException because we never dereference it, just look at its type.

 
Nyeng Gyang
Ranch Hand
Posts: 113
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What can I say? Different learners have different needs and preferences for learning and remembering learned content. As for me, the use of the notation ClassName.methodName(), when methodName() is an instance, rather than a static, method of ClassName, confused my learning, rather than facilitated it, hence I had to spend some time consulting other sources to resolve this confusion. I recall that, when I stumbled upon this reference to an instance method of the NumberFormat class, which employed a notation that is exactly the same as the syntax for referencing a static method of the class, I didn't even bother to look at the code examples, to which Jeanne refers, before setting off on this inquiry to resolve my confusion (I think I might have already somehow established - I don't now remember how - that this method is an instance and not a static method).

In any case, the use of the var type in the code examples means more cross-studying, just to derive the fact that NumberFormat.format() means format() is an instance, rather than a static, method of the NumberFormat class (for me, this cross-studying included consulting the Java documentation source for method details of the NumberFormat class, including the return types of these methods). My own issue is why a reader, like me, would have to exert this extra effort because of the use of this confusing and even inefficient notation that I only learned from Paul Clapham seems to be well-known by programmers who have already come across the notation's use. While not all those stumbling upon this class for the first time would have this issue, I happened to have had the problematic issue.

Just like Jeanne explained, this is not about someone being right and another being wrong; rather, it is about different people having different opinions and/or learning preferences.

Because I fail to see the benefits advanced for the use of this notation and my seeing only drawbacks for its use, I will not be using the notation, whether in my own teaching (I have worked teaching programming in Higher Ed and possibly will also do so in the future) or any communications I transmit as a practicing programmer.
 
Paul Clapham
Marshal
Posts: 26912
82
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Nyeng Gyang wrote:Because I fail to see the benefits advanced for the use of this notation and my seeing only drawbacks for its use, I will not be using the notation...



Everyone can make their own choices about such things. For example, mostly based on what I've seen in this forum, I do not use the ++ or -- operators if I want to increment or decrement a value. Instead I'll use "a += 1" or "a -= 1", whichever applies. I don't need to use something which may or may not increase my program's execution time by a couple of nanoseconds while providing a possible source of confusion for future readers.

The only exception is for the standard for-loop idiom "for (int i = 0; i < cutoff; i++)" and even that idiom I rarely use any more since streams and functional programming appeared in Java.
 
Nyeng Gyang
Ranch Hand
Posts: 113
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:Kindly don't edit posts after they have been answered; that makes it appear we are answering the wrong question. I am refusing your edits. Please post any new material in a new post.


(1.) In the particular case of the edits I made to my last post above, I did not realize that Paul Clapham had provided a response to the post during the time I made the edits. I was doing those edits on a smart phone (whose GUI for the site is significantly different than that of a PC) and I did not see his response to the post as I made the edits, submitted them and re-read the edited post to see whether or not any more edits were needed. If I am recalling correctly, it was after I already made the final edit that I knew that Paul responded to the post and I got to know this from the e-mail someone gets when their post gets a response; I did not know of his response during the time I made the edits.

(2.) Did the edits I made (i.e., the ones you have informed me you are refusing to allow) alter the post that much, after when Paul responded, to the point that it would appear like his respone to the post is answering the wrong question?

Since you are not allowing the edits I made, I will be much obliged if it is possible for me to access and copy the text of the post in its state after the final edit I made to it (some discussion forums are implemented to allow all participants in a discussion to access/see all edits made to a post by someone in the forum, so I hope yours - i.e., Coderanch - has this feature/functionality as well).

Thanks.
 
Nyeng Gyang
Ranch Hand
Posts: 113
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jeanne Boyarsky wrote:I reiterate that there are code examples right by this. So it isn't a surprise the method isn't static.


Okay, let's consider the following scenario in which I found myself as well as in which some other reader of the study guide could find themselves: A reader of the study guide eventually determines, from cross-studying the code examples in the book that Jeanne mentions as well as content from other sources, that this method is not a static method of the NumberFormat class. Such a reader would find themselves, as I did find myself, asking the question why a method that they know to be an instance method of a class is being referenced with a notation that is the exact same syntax used to reference a static method of the class. Such a reader would not find themselves asking this question ONLY if they know that this notation is used to mean that the method is a static method, not an instance method.

Because I was not aware of this notation, I was sure that the book's use of the syntax, for referencing a static method, to reference an instance method, is an erratum. There cannot be any debate on or disagreement with the fact that ONLY those familiar with this notation would not think that this is not an erratum. After I encountered this confusing use of the notation, the only means that resolved the confusion for me was my being told of the notation's existence and use in Java programming. Furthermore, I may be unlike many, or even most, of those readers of this study guide, who also experience the confusion arising from the use of this notation, in the sense that these other readers may ignore the confusion while I won't, until it gets resolved for me. The time and effort I expended to obtain this resolution, as well as this entire discussion thread, would have been precluded were it not for the use of this notation, hence my characterizing it as inefficient (in addition to it being confusing).
 
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic