Discussions
Categories
- 197K All Categories
- 2.5K Data
- 546 Big Data Appliance
- 1.9K Data Science
- 450.9K Databases
- 221.9K General Database Discussions
- 3.8K Java and JavaScript in the Database
- 31 Multilingual Engine
- 552 MySQL Community Space
- 479 NoSQL Database
- 7.9K Oracle Database Express Edition (XE)
- 3.1K ORDS, SODA & JSON in the Database
- 556 SQLcl
- 4K SQL Developer Data Modeler
- 187.2K SQL & PL/SQL
- 21.4K SQL Developer
- 296.4K Development
- 17 Developer Projects
- 139 Programming Languages
- 293.1K Development Tools
- 111 DevOps
- 3.1K QA/Testing
- 646.1K Java
- 28 Java Learning Subscription
- 37K Database Connectivity
- 161 Java Community Process
- 105 Java 25
- 22.1K Java APIs
- 138.2K Java Development Tools
- 165.3K Java EE (Java Enterprise Edition)
- 19 Java Essentials
- 162 Java 8 Questions
- 86K Java Programming
- 81 Java Puzzle Ball
- 65.1K New To Java
- 1.7K Training / Learning / Certification
- 13.8K Java HotSpot Virtual Machine
- 94.3K Java SE
- 13.8K Java Security
- 205 Java User Groups
- 24 JavaScript - Nashorn
- Programs
- 475 LiveLabs
- 39 Workshops
- 10.2K Software
- 6.7K Berkeley DB Family
- 3.5K JHeadstart
- 5.7K Other Languages
- 2.3K Chinese
- 175 Deutsche Oracle Community
- 1.1K Español
- 1.9K Japanese
- 233 Portuguese
SCJP 6 study guide: error in book?

843789
Member Posts: 46,655 Green Ribbon
Hi,
In the example on page 607 in the box "exam watch"; The pre-java 5 example says:
So I think the example on page 607 contains an error and it should state
In the example on page 607 in the box "exam watch"; The pre-java 5 example says:
List test = new ArrayList(); test.add(43); ...But on page 568 in the section "Autoboxing with Collections" it says in the pre-java 5 example:
List myInts = new ArrayList(); myInts.add(new Integer(42)); ...The issue is the fact that collections can't contain primitives. Java 5 introduced the autoboxing preventing the explicit creation of a wrapper.
So I think the example on page 607 contains an error and it should state
... test.add(new Integer(43)); ...Correct?
Comments
-
Balleke wrote:In pre-Java 5 the original example is indeed incorrect; later Javas do apply autoboxing in the example code. You do get a few warnings about "raw types" though.
So I think the example on page 607 contains an error and it should state... test.add(new Integer(43)); ...
Correct?
kind regards,
Jos -
Perhaps this has been changed in a newer edition of this book, but I think I found a problem as well. On page 583 of my copy there is an example of a class called MapTest.
The text says that a class called Dog() finds the Map entry because Dog overrides equals() and hashCode(). The problem is that Dog's equals method uses '==' rather than .equals() to compare
two strings. I thought that perhaps this was a clever use of a String feature discussed earlier. The JVM putting strings on the heap in case they were referenced again.
This equals method would work, therefore, if I was comparing two string references, both pointing to "baloney". But, if I construct a new String object using "baloney" in the constructor, the '--' comparison
fails.
For example:
import java.util.*;
class Dog
{
public Dog(String n) { name = n; }
public String name;
public boolean equals( Object o )
{
if (( o instanceof Dog ) && (((Dog) o).name == name ))
{
return true;
}
return false;
}
public int hashCode() { return name.length(); }
}
class Cat {}
enum Pets {DOG, CAT, HORSE}
class MapTest
{
public static void main( String argv[] )
{
Map<Object, Object> m = new HashMap<Object, Object> ();
Dog d1 = new Dog( "aiko" );
m.put( d1, new Dog("aiko"));
System.err.println( "found aiko??? " + m.get("k1"));
System.err.println( "found aiko??? " + m.get(d1));
System.err.println( "found aiko??? " + m.get( new Dog( "aiko" )));
System.err.println( "found aiko??? " + m.get( new Dog( new String("aiko") )));
}
}
The last get fails, even though I'd expect it to succeed. It seems to me a better implementation of the
Dog equals method would be
public boolean equals( Object o )
{
if (( o instanceof Dog ) && (((Dog) o).name.equals(name) ))
{
return true;
}
return false;
}
Is this nitpicking. Is this a problem? I am enjoying the book very much and hope to take the exam soon. -
user12283397 wrote:That is indeed an error. It should be equals(). If the author's example works, it's because he happened to use the same string literal in both cases. It will not work in the general case.
Perhaps this has been changed in a newer edition of this book, but I think I found a problem as well. On page 583 of my copy there is an example of a class called MapTest.
The text says that a class called Dog() finds the Map entry because Dog overrides equals() and hashCode(). The problem is that Dog's equals method uses '==' rather than .equals() to compare
two strings.I thought that perhaps this was a clever use of a String feature discussed earlier. The JVM putting strings on the heap in case they were referenced again.All Strings, just like all other objects, are on the heap. What you're thinking of is the constant pool, which is a special area of the heap. All interned Strings goes there (as does some other stuff).
This discussion has been closed.