This week's book giveaway is in the Jobs Discussion forum.
We're giving away four copies of The Career Toolkit and have Mark Herschberg on-line!
See this thread for details.
Win a copy of The Career Toolkit this week in the Jobs Discussion forum!

John Brown

Ranch Hand
+ Follow
since Dec 01, 2004
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by John Brown

Hi all,
I'm trying to output xml with this jsp page:


But the browser complains:

XML Parsing Error: xml declaration not at start of external entity
Location: http://127.0.0.1:8080/bla
Line Number 5, Column 1:
<?xml version="1.0" encoding="UTF-8"?>
^

The source of the page is:

Notice the 4 blank lines in the output? They're cause by the 4 directives I've put in the jsp:



These 4 blank lines are the cause of the xml parse error. So why do I get them in the output?

Thanks.
13 years ago
JSP
Sorry about the modifications, I somehow mis-posted, now it looks right
In the old K&B chapter 5, one can read about constructors the following:


If you do type in a constructor (as opposed to relying on the compiler-generated
default constructor), and you do not type in the call to super(), the compiler
will insert a no-arg call to super() for you
.



I don't know about you, but I always thought that the compiler will insert this call to super() on the first line of the constructor. If the call to super() is the first line of the derived class constructor, then it would mean that the derived class' variables are already initialized - because the constructor is run after the member variables were initialized.
But the following code proves this is a wrong understanding.

From the output I can see that the base class constructor is called after the memory allocated for the two objects (base and derived) is wiped to zero (i.e. all members are initialized with implicit values) and after the base's member init has finished, but before derived class member init begins.
Am I correct?



Output:

BaseClass static init block
DerivedClass static init block
BaseClass init block
base.a=0
DerivedClass' go(), a=0
Out of BaseClass' init block
BaseClass constructor, a= 10
DerivedClass init block
derived.a=0
Out of DerivedClass' init block
DerivedClass constructor, a= 20

[ February 12, 2006: Message edited by: John Brown ]

[ February 12, 2006: Message edited by: John Brown ]
[ February 12, 2006: Message edited by: John Brown ]
Thanks Arthur.
Kiran, 3 would be true if we're talking about final member variables, because if a final variable is used in a constructor before it gets initialized, you have an error.
Edisandro and Anju, you're welcome, I merely posted the link Let's thank Corey McGlone, the author of the article. Thanks Corey!
[ February 09, 2006: Message edited by: John Brown ]
The answer I think is 0.
The short version:

Unlike most objects, String literals always have a reference to them from the String Literal Pool (which is a collection of references to String objects), even if there's no longer any active thread that has a reference to that String literal.



The long version: Strings, Literally - by Corey McGlone, look under the Garbage Collection subtitle.
[ February 09, 2006: Message edited by: John Brown ]
Which 3 statements concerning the value of a member variable are true, when no explicit assignments have been made?

1) The value of an int is undetermined.
2) The value of all numeric types is zero.
3) The compiler may issue an error if the variable is used before it is initialized.
4) The value of a String variable is "" (empty string).
5) The value of all object variables is null.

2 and 5 are true, is there another one which is true? Because the question asks for 3 statements.
If A is not a B, how come the line in bold compiles ok ? True, it does throw a ClassCastException, but why does it compile?

class A {}
class B extends A {}

class ObjectCasting {
public static void main(String[] ajn) {
A a = new A();
B b = new B();
b = (B) a;
}
}
Your welcome And thank you too for finding the additional errata.
Hi Bert, yeah, I have the oldest book, in fact, it's THE first copy printed
But I've searched the errata (http://books.mcgraw-hill.com/downloads/products/0072226846/0072226846_errata.txt) last updated March 3 2003, and couldn't find anything. Is there another newer errata somewhere ?
At page 427 of the SCJP Study Guide (1.4) by Kathy Sierra and Bert Bates, one can read about LinkedHashSet the following:

LinkedHashSet lets you iterate through the elements in the
order in which they were inserted. Optionally, you can construct a LinkedHashSet so that it maintains the order in which elements were last accessed, rather than the order in which elements were inserted.



What are the constructors/methods that let you construct a LinkedHashSet "so that it maintains the order in which elements were last accessed"?, cause I could not find anything in the API. All the API says is:

This linked list defines the iteration ordering, which is the order in which elements were inserted into the set insertion-order).



Its constructors are:

LinkedHashSet() - Constructs a new, empty linked hash set with the default initial capacity (16) and load factor (0.75).

LinkedHashSet(Collection c) - Constructs a new linked hash set with the same elements as the specified collection.

LinkedHashSet(int initialCapacity) - Constructs a new, empty linked hash set with the specified initial capacity and the default load factor (0.75).

LinkedHashSet(int initialCapacity, float loadFactor) - Constructs a new, empty linked hash set with the specified initial capacity and load factor.

I see nothing like LinkedHashMap's contructor that lets you construct the map so that is order by access:

LinkedHashMap(int initialCapacity, float loadFactor, boolean accessOrder) - Constructs an empty LinkedHashMap instance with the specified initial capacity, load factor and ordering mode.
Hi Jim, thanks for your answer.
Yes I agree (always had) that the phrase "calling t.start() won't restart it" is a true statement, I was just confused about the reason the errata was striking the phrase "you'll get a big fat runtime exception", and the errata does that only for the 505 page, and not for the 536 and 508 pages.

So, if I get a question on this topic on the exam, what's the answer? is an exception thrown or not? I would be inclined to answer that with a yes.
[ February 02, 2006: Message edited by: John Bran ]
Page 536:

If start() is called more than once on a Thread object, it will throw a RuntimeException.



This is in agreement with the API. But the errata is not.