wood burning stoves 2.0
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes collecions Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Building Microservices this week in the Design forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "collecions" Watch "collecions" New topic


vinod n.s

Joined: Sep 24, 2003
Posts: 2
What should I study about collections for scjp1.4?
Jessica Sant

Joined: Oct 17, 2001
Posts: 4313

Here are some quotes from replies by Kathy Sierra in other threads:
(Check out our handy dandy search utility to find other threads on this topic)
About Collections
Originally posted by Kathy Sierra (here):
Howdy... just wanted to say, as the "K" part of "K & B", you definitely will NOT have extensive collection code to analyze. Just make sure you know what iterator code looks like.
The objectives ask ONLY that you "make appropriate selections..." based on the specified requirements (like, "You need a class that guarantees every name is unique, and you also need...")
You won't be able to choose a suitable collection unless you know it's fundamental behavior (allow duplicates? Use keys? Ordered?, etc.).
But really, that's it. The only other objective involving collections is the one about hashCode and equals, and that doesn't even necessarily belong in the Collections objective, and most hashCode and equals questions will not involve Collections.
So here's what you definitely do NOT have to know:
-the specific algorithms used by ANY of the collections, or the O-notation, etc.
-the method signatures for all the methods in the collections interfaces and classes. If you know the basic methods you're OK, and most of *those* you can infer IF you know the way the various Collections behave. For example, you won't have an iterator() method in a HashMap, because you can't iterate over a map, only over the VALUES in the set. So it wouldn't make sense to see code using the iterator method directly on a reference to a HashMap. And you would not, for example, expect to see a method in ArrayList that lets you add something with two objects as the arguments (like you would with a HashMap). You'd probably expect to see one that takes an int (for the index) along with the object to add, but not one with two objects. So even if I had never laid eyes on the API for either of those classes, if I understood how they worked, I could figure out whether those methods made sense. I guess I'm saying that you do NOT have to memorize the API for these classes, for the exam. But I would spend a fair amount of time getting clear about the difference between Set, Map, and List, and knowing which implementation classes fall under each of those, and of course, the difference between sorted, ordered, etc.
(think of me as a stress-reduction therapist... I consider it my job to tell you when you can just relax. You have enough to study as it is )

About Collections (and some bonus stuff on Assertions)
Originally posted by Kathy Sierra (here):
Here are a few tips on what you do and don't need to know for the exam. I agree that it's hard to know what to study and what not to study.
Sun has an assertions document and EVERYTHING you need on assertions, for the exam, is in that paper. I would become familiar with all of it. Know how to enable and disable assertions, and the syntax for using them. Pretty easy stuff, except for memorizing some of the rules for the enabling/disabling flags. There's a strange little gotcha about package hierarchies in there, so pay close attention to the ways in which you can enable and disable packages and sub-packages. Sub-packages is a phrase that's brand new to Java, and used mainly just for assertions.
You know how import statements don't include supackages?
(like, import java.awt.*; will NOT import java.awt.event.; In other words, packages that happened to share parts of their directory tree were not programmatically related in any way.)
But with assertions, you *can* take advantage of subpackages, like saying, "Take everything in this package, and in any package that's further down this directory/package structure."
From the docs:
For example, the following command runs a program, BatTutor, with assertions enabled in only package com.wombat.fruitbat and its subpackages:
java -ea:com.wombat.fruitbat... BatTutor

For Collections, you need to know:
* The interface and class structure for Collection and Map
* The difference between Set, List, and Map
* The implementation classes of Set, List, and Map
* very basic understanding of iterators
*Have a good idea of what each of the implementations (and interfaces) are good for. In most questions, as long as you know exactly *what* the classes do, you should be able to figure it out.
* Know the difference between unsorted, unordered, ordered and sorted, and how they relate. Be sure you know which classes are sorted and which are not, and which classes are ordered and which are not.
* Understand the contract for hashcode and equals, but this is ALL in the J2SE API docs for class Object.
You do NOT need to know:
* The implementation algorithms for the collections.
* Most of the method signatures for the collections
(although you should know the fundamental ones that come from the highest places in the inheritance/implementation hierarchy)
* Details about the Collections class
You *can* learn what you need if you study the API docs for the Collection classes. I would spend some time drawing charts of how the classes fit together, and organize and sort them according to how they behave.
Have fun

[ October 07, 2003: Message edited by: Jessica Sant ]

- Jess
Blog:KnitClimbJava | Twitter: jsant | Ravelry: wingedsheep
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com
subject: collecions
It's not a secret anymore!