Win a copy of Svelte and Sapper in Action this week in the JavaScript forum!

Keerthi P

Ranch Hand
+ Follow
since Aug 19, 2003
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 Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Keerthi P

I think I was able explain this myself.

Consider the following code:

Page #120 (1Z0-809)

The authors write

List<? extends Bird> could be List<Bird> or List<Sparrow>. Line #7 doesn't compile because we can't add a Sparrow to List<Bird>

The above underlined is factually incorrect. Sparrow can be added to List<Bird>. Or atleast it is not convincingly explained why compilation fails. Could some help me understand why Line #6 not compile?

Pg 308, while the book states that the optional error_message is a String

...the Java documentation states that it is an expression that has a value

assert Expression1 : Expression2 ;

Expression1 is a boolean expression.
Expression2 is an expression that has a value. (It cannot be an invocation of a method that is declared void.)

Particularly the below quote from:

The system passes the value of Expression2 to the appropriate AssertionError constructor, which uses the string representation of the value as the error's detail message.

Expression2 is more "wider and broad" than String and I believe this deserves to be noted (and perhaps added to errata).

The following is a valid assert statement and compiles successfully:

Referring to page #264 on Jeanne's book, i'm a bit confused with the order mentioned. Isn't the following the right order in which the lookup will be made?




A class cannot access the implemented interface's static method using 'this' and should use the type name to get to the method. This makes perfect sense to me - The static method is not bound to an instance and therefore 'this' has no meaning in this case (and is also not inherited to be able to reach via 'this' from the class).

But I'm baffled why did the following compile:

Why is the compiler seeing the interface's static variable differently? Appreciate your replies.
Its been a while since gave Exam #1 (1Z0-808). Now, I'm planning to start preparing for Exam #2 (1Z0-809). Should I read the book for Exam #1 to tackle Exam #2?
It appears the Kindle version of Jeanne's book (link below) is pretty old. I hear the latest reprint of the book contains most of the errata addressed in the print. Where can I buy an ebook (any format works for me) version of the latest reprint?

is same as

10 years ago
You may want to add enctype="multipart/form-data" to your form tag. The standard h:form supports this attribute. Typical usage is as below:

You seem to be using ice faces. Check the documentation of ice:form tag.
10 years ago
I have a custom JSF component that renders navigation links. The following is a typical usage of the component:

And, the rendered content will appear as following, similar to the navigation links at the top of this page:

Primary Data | Principals | Administrators | Custodiams | Accounting Firms | Law Firms | Billing

As you notice, the navigationBar component is bounded to #{testBean.navigationBar} which is defined as below in the Backing bean:

The backing bean has an action method formSubmitted() that adds a child (HtmlNavigationLink) component to the parent (HtmlNavigationBar) dynamically. I thought that this newly added child would be the last child (as it is added to end of the children list). But, when the navigationBar renders its children, the HtmlNavigationLink 'New link' appears as the first child causing the content rendered as below:

New Link | Primary Data | Principals | Administrators | Custodiams | Accounting Firms | Law Firms | Billing

The following is the encodeChildren() method of HtmlNavigationBar

As noted in the comment above, while the link was added to the end of the list in the action method, it appears at index position 0 as the first child? Why is it so?
10 years ago

It (the Business Delegate) is passed to a remote facade.

You may want to reconsider this design.
Why not? Do not confuse JMS with MDBs.
No you don't have to. You can still take SCBCD.