Faz Ali

Ok, I've confirmed the CLASSPATH environment variable is set to C:\Program Files\QuickTime\QTSystem\QTJava.zip;
I've confirmed this by using "set CLASSPATH" in CMD which prints the following:

C:\Users\FaZ>set CLASSPATH
CLASSPATH=C:\Program Files\QuickTime\QTSystem\QTJava.zip;

C:\Users\FaZ>

For testing purposes, I've put both the Book and Student .java files in the same directory at the path C:\Users\FaZ\Desktop\Code. I've since browsed to this directory via CMD and then run the following command which works absolutely fine:
C:\Users\FaZ\Desktop\Code>javac Student.java && java Student C:\Users\FaZ\Desktop\Code>

Regarding putting code into C:\Program Files, this was just for quick testing purposes. I absolutely do not put code in there, I just used that directory with this specific example.

The next thing I've tried is the following, which I expected to fail since I am explicity defining a classpath in my javac invocation which does not contain the current directory:

C:\Users\FaZ\Desktop\Code>javac -cp "C:\Program Files" Student.java
Student.java:5: cannot find symbol
symbol : class Book
location: class Student
Book book = new Book();
^
Student.java:5: cannot find symbol
symbol : class Book
location: class Student
Book book = new Book();
^
2 errors

C:\Users\FaZ\Desktop\Code>

Since I can confirm that I have a CLASSPATH environment variable which is set to something, can I also then confirm that the books statements about java and javac not looking in the current directory is erroneous? - It seems the only time it doesn't look in the current directory is when a classpath is defined in the command line. I'm running Windows 7 with Java version "1.6.0_24" - Java(TM) SE Runtime Environment (build 1.6.0_24-b07) - Java HotSpot(TM) Client VM (build 19.1-b02, mixed mode, sharing) if that makes a difference?

Hi All,

I'm just reviewing chapter 10 of the SCJP Java 6 study guide by Kathy Sierra and Bert Bates in which a paragraph highlights:

A very common situation occurs in which java or javac complains that it can't find a class file, and yet you see that the file is IN the current directory! When searching for class files, the java and javac commands don't search the current directory by default. You must tell them to search there.

Now I tested this, using the following simple classes, both of which are in the same folder (C:\Java Code)

public class Book{} public class Student { public static void main(String[] args) { Book book = new Book(); } }

browing to this directory in CMD and then using the command 'javac Student.java && java Student' both classes compiled fine and class Student ran. - Why hasn't it complained that it can't find the Book class?

I have a CLASSPATH environment variable but it is set to the following C:\Program Files\QuickTime\QTSystem\QTJava.zip;
Since I don't have a . present in the classpath environment variable and I haven't used the -classpath or -cp option when compiling and running the Student class, how is it that java and javac were able to find the Book class?
To test this more thoroughly, the next thing I did was delete the CLASSPATH environment variable altogether and retried the java and javac commands which again worked fine.
Lastly, I recreated the CLASSPATH environment variable and set it to C:\Program Files\QuickTime\QTSystem\QTJava.zip;C:\Program Files i.e. adding another directory but not onewhere my source files are. - Compilation and running of class Student worked this time also.
Any explanation would be welcome as the only thing I can think of at the moment is that this paragraph is erroneous? - It seems that these commands always look at the current directory by default irrespective of what is set in the CLASSPATH environment variable. The only time they don't is when you explicitly set a classpath using the java and javac commands via the -classpath/-cp options? I.e. something alongs the lines of the following:

C:\Java Code>javac -cp C:\Program Files Student.java
error: Class names, 'Files', are only accepted if annotation processing is expli
citly requested
Student.java:5: cannot find symbol
symbol : class Book
location: class Student
Book book = new Book();
^
Student.java:5: cannot find symbol
symbol : class Book
location: class Student
Book book = new Book();
^
3 errors[/code]

If someone could clarify the above, I would be very grateful.

Rob Spoor wrote:

Faz Ali wrote:

Rob Spoor wrote:And you forgot to call super.paintComponent(g) in your paintComponent method.

Why may I ask. - I haven't read that far ahead so maybe it's something that will come up but if you could explain it now, that would be great

super.paintComponent(g) makes sure the panel is drawn with a clean slate - all custom drawings will be removed. Currently, if the values in your locations array would change the repainting would only add the new locations, not remove the old ones.

Hmm, that doesn't seem true. If you run the program you will see, it adds a new line whilst simultaneously removing the old line?

Rob Spoor wrote:And you forgot to call super.paintComponent(g) in your paintComponent method.

Why may I ask. - I haven't read that far ahead so maybe it's something that will come up but if you could explain it now, that would be great

Ulf Dittmer wrote:Seems to work fine for me. What, exactly, are you experiencing?

Sometimes the mouse clicks just do not register. I added System.out.println(clickCounter); in the code to detect when they are registered and sometimes I am definitely clicking the panel but it just doesn't register. There's no other way for we to describe what's happening.

Hi all,

I've just had my first dab in Java 2d graphics and have created a quick and rather crude program which draws a line between two points. The problem I am experiencing is that a lot of the mouse clicks just do not register on the JPanel. Any idea how to fix this? My code is below:

import javax.swing.*; import java.awt.*; import java.awt.event.*; public class HangmanLabel extends JLabel implements MouseListener { int[] locations = new int[4]; int clickCounter = 0; public void paintComponent(Graphics g) { //Graphics2D graphics = (Graphics2D)g; g.setColor(Color.RED); g.drawLine(locations[0], locations[1], locations[2], locations[3]); } public void mouseClicked(MouseEvent e) { clickCounter++; System.out.println(clickCounter); if(clickCounter == 1) { locations[0] = e.getX(); locations[1] = e.getY(); } if(clickCounter == 2) { locations[2] = e.getX(); locations[3] = e.getY(); clickCounter = 0; this.repaint(); this.validate(); } } public void mouseEntered(MouseEvent e) {} public void mouseExited(MouseEvent e) {} public void mousePressed(MouseEvent e) {} public void mouseReleased(MouseEvent e) {} public static void main(String[] args) { HangmanLabel canvas = new HangmanLabel(); canvas.addMouseListener(canvas); JFrame frame = new JFrame("Testing"); frame.setSize(400,400); frame.getContentPane().add(canvas); frame.setVisible(true); } }

Stephan van Hulst wrote:Well, I don't really want to be a party pooper, but my point is that CardList really doesn't add anything that LinkedList doesn't already have. The only difference is that you check for null elements, and you don't allow duplicates. The former is good, but you shouldn't restrict duplicates from being added to your class (some card games, like Canasta, shuffle two or even three standard decks together).

So really, all that your class does is check for null elements. Your design would be a lot cleaner if you just dropped the class completely, and let specific card games keep track of their own LinkedList<Card>, and make them responsible for not adding any null elements to it.

Here's an example of what I mean. Here, the game is responsible for maintaining all the cards: public final class Canasta implements CardGame { private final LinkedList<Card> stack, discard; ... public Canasta(int players) { stack = new LinkedList<Card>(); discard = new LinkedList<Card>(); for (int i = 0; i < 2; i++) stack.addAll(Card.newDeck()); if (players > 4) stack.addAll(Card.newDeck()); Collections.shuffle(stack); ... } public void draw() { Card draw = stack.remove(); if (draw == null) { stack.addAll(discard); discard.clear(); Collections.shuffle(stack); draw = stack.remove(); } player.deal(draw); } ... }

To be honest with you, when I was creating that class, I was wondering the same thing; I'm not really doing anything thats not already in the LinkedList class and it just feels wrong. What you've highlighted makes perfect sense and I'm already making the changes. Sometimes OO really gets to me because I find it hard when to decide if I need to create a class myself or if I should use an already existing class which should have a limited interface than one offered by another class. - Such is the case with this example whereby a deck in my game will not use every method implemented by linkedlist but therefore I ask myself if I usually ask myself should I still use it.

Stephan van Hulst wrote:Well, the Deque interface really already specifies most of this behaviour. You could just use the LinkedList class, which implements both the List and the Deque interfaces.
What you could do is define a static method in your Card class that returns a LinkedList<Card> containing the standard 52 cards.

If you're really looking to get the exercise, you can declare your CardHolder class to implement java.util.List<Card> and java.util.Deque<Card>, and implement all the methods yourself. You can also extend AbstractList<Card> to get you started.

This way, you will only have one class (CardHolder), and let the card games that use CardHolders (for instance, as decks, discard piles or hands) be responsible for using them correctly.

Thanks for the input Stephan. I have taken it on board and what I've come up with is below. Essentially it is a wrapper around a linkedList collection which implements all the methods a 'card list' minimally needs to have. The card games which use them will be responsible for implementing them and this class can therefore be used as a deck, discard pile, hand etc. Please let me know if this is what you meant:

import java.util.*; import java.io.*; public class CardList implements Serializable { private LinkedList<Card> cardList; public CardList() { cardList = new LinkedList<Card>(); } public CardList(boolean createDeck) { if(createDeck) { cardList = new LinkedList<Card>(); Card.PlayingCardSuit suit = null; for(int x=0; x<4; x++) { switch(x) { case 0: suit = Card.PlayingCardSuit.CLUBS; break; case 1: suit = Card.PlayingCardSuit.DIAMONDS; break; case 2: suit = Card.PlayingCardSuit.HEARTS; break; case 3: suit = Card.PlayingCardSuit.SPADES; break; } cardList.add(new Card(Card.PlayingCardValue.ACE, suit)); cardList.add(new Card(Card.PlayingCardValue.TWO, suit)); cardList.add(new Card(Card.PlayingCardValue.THREE, suit)); cardList.add(new Card(Card.PlayingCardValue.FOUR, suit)); cardList.add(new Card(Card.PlayingCardValue.FIVE, suit)); cardList.add(new Card(Card.PlayingCardValue.SIX, suit)); cardList.add(new Card(Card.PlayingCardValue.SEVEN, suit)); cardList.add(new Card(Card.PlayingCardValue.EIGHT, suit)); cardList.add(new Card(Card.PlayingCardValue.NINE, suit)); cardList.add(new Card(Card.PlayingCardValue.TEN, suit)); cardList.add(new Card(Card.PlayingCardValue.JACK, suit)); cardList.add(new Card(Card.PlayingCardValue.QUEEN, suit)); cardList.add(new Card(Card.PlayingCardValue.KING, suit)); } } else { cardList = new LinkedList<Card>(); } } public boolean addCardToEnd(Card c) throws NullPointerException { return this.addCardAt(cardList.size(), c); } public boolean addCardToStart(Card c) throws NullPointerException { return this.addCardAt(0, c); } public boolean addCardAt(int index, Card c) throws NullPointerException, IndexOutOfBoundsException { if(c != null) { if(cardList.contains(c)) { return false; } else { cardList.add(index, c); return true; } } else { throw new NullPointerException(); } } public boolean contains(Card c) { return cardList.contains(c); } public Card getCardAtEnd() throws NoSuchElementException { return cardList.getLast(); } public Card getCardAtStart() throws NoSuchElementException { return cardList.getFirst(); } public Card getCardAt(int index) throws IndexOutOfBoundsException { return cardList.get(index); } public int indexOf(Card c) { return cardList.indexOf(c); } public Card removeCardAtEnd() { return cardList.removeLast(); } public Card removeCardAtStart() { return cardList.removeFirst(); } public Card removeCardAt(int index) throws IndexOutOfBoundsException { return cardList.remove(index); } public void shuffle() { Collections.shuffle(cardList); } public int getCardCount() { return cardList.size(); } public void sort() { Collections.sort(cardList); } public void sort(Comparator<Card> comparator) { Collections.sort(cardList, comparator); } }

Stephan van Hulst wrote:Well, why do you need a base class (I'm assuming it's Cardholder?) and what functionality are your other classes going to add to it? It's not very clear from your example.

Can you explain what CardHolder does that wouldn't be available in a List<PlayingCard>?

It's best if I explain the problem with the classes I have written (without any use of interfaces, abstract classes, inheritance etc)

First, I have a regular deck which is instantiated with 52 standard deck, adds cards to the end of the deck, deals cards from the top of the deck, can be shuffled and lastly returns its size:

import java.util.*; public class PlayingDeck { private List<Card> deck = new ArrayList<Card>(); //Constructor creating a standard 52 Card deck public PlayingDeck() { Card.PlayingCardSuit suit = null; for(int x=0; x<4; x++) { switch(x) { case 0: suit = Card.PlayingCardSuit.CLUBS; break; case 1: suit = Card.PlayingCardSuit.DIAMONDS; break; case 2: suit = Card.PlayingCardSuit.HEARTS; break; case 3: suit = Card.PlayingCardSuit.SPADES; break; } deck.add(new Card(Card.PlayingCardValue.ACE, suit)); deck.add(new Card(Card.PlayingCardValue.TWO, suit)); deck.add(new Card(Card.PlayingCardValue.THREE, suit)); deck.add(new Card(Card.PlayingCardValue.FOUR, suit)); deck.add(new Card(Card.PlayingCardValue.FIVE, suit)); deck.add(new Card(Card.PlayingCardValue.SIX, suit)); deck.add(new Card(Card.PlayingCardValue.SEVEN, suit)); deck.add(new Card(Card.PlayingCardValue.EIGHT, suit)); deck.add(new Card(Card.PlayingCardValue.NINE, suit)); deck.add(new Card(Card.PlayingCardValue.TEN, suit)); deck.add(new Card(Card.PlayingCardValue.JACK, suit)); deck.add(new Card(Card.PlayingCardValue.QUEEN, suit)); deck.add(new Card(Card.PlayingCardValue.KING, suit)); } } public boolean addCard(Card c) throws NullPointerException //Adds cards to end of list and does not allow the addition of null cards { if(c != null) { if(deck.contains(c)) { return false; } else { deck.add(c); //Adds the card to the end of the List return true; } } else { throw new NullPointerException(); } } public Card dealCard() throws IndexOutOfBoundsException { if(deck.isEmpty()) { throw new IndexOutOfBoundsException("Deck is empty"); } else { return deck.remove(0); //Always returns a card from the top (start) of the deck } } public int getCardCount() { return deck.size(); } public void shuffle() //Shuffles the deck { for(int x=0; x<deck.size(); x++) { Random generator = new Random(); int rand = generator.nextInt(deck.size()-1); //generates a random number between zero and the deck size. Card tempCard = deck.get(x); deck.set(x, deck.get(rand)); deck.set(rand, tempCard); } } }

Next up we have a shreddedDeck which is very similar to a PlayingDeck with some slight variations. It adds cards to the beginning of the list and removes from the end of the list. The exact opposite of the PlayingDeck. Also, it cannot be shuffled. It shares several method names with PlayingDeck but only has the same implementation for getSize(). Also it has an extra method which returns the faceCard without removing it from the deck:

import java.util.*; public class ShreddedDeck { private List><Card> deck = new ArrayList<Card>(); public boolean addCard(Card c) throws NullPointerException //Adds cards to end of list and does not allow the addition of null cards { if(c != null) { if(deck.contains(c)) { return false; } else { deck.add(0, c); //Adds the card to the beginning of the List return true; } } else { throw new NullPointerException(); } } public Card getFaceCard(Card c) { if(deck.isEmpty()) { throw new IndexOutOfBoundsException("Deck is empty"); } else { return deck.get(0); } } public Card dealCard() throws IndexOutOfBoundsException { if(deck.isEmpty()) { throw new IndexOutOfBoundsException("Deck is empty"); } else { return deck.remove(deck.size() - 1); //Always returns a card from the bottom (end) of the deck } } public int getCardCount() { return deck.size(); } }

Lastly I have a hand class which is also similar to the PlayingDeck and ShreddedDeck classes but with slight variations and the addition of methods for sorting and adding cards in certain indices. It has an addCard() and getSize() method which are exactly the same as the PlayingDeck implementations but all other methods are unique:

import java.util.*; public class Hand { private List<Card> hand = new ArrayList<Card>(); public boolean addCard(Card c) throws NullPointerException //Adds cards to end of list and does not allow the addition of null cards { if(c != null) { if(hand.contains(c)) { return false; } else { hand.add(0, c); //Adds the card to the beginning of the List return true; } } else { throw new NullPointerException(); } } public boolean void addCardAt(int index, Card c) throws IndexOutOfBoundsException, NullPointerException { if(c != null) { if(index < 0 || index > hand.size()) { throw new IndexOutOfBoundsException(); } if(hand.contains(c)) { return false; } else { hand.add(index, c); } } else { throw new NullPointerException(); } } public Card getCardAt(int position) throws IndexOutOfBoundsException { if(index < 0 || index > hand.size()) { throw new IndexOutOfBoundsException(); } else { return hand.get(index, c); } } public Card removeCardAt(int position) throws IndexOutOfBoundsException { if(index < 0 || index > hand.size()) { throw new IndexOutOfBoundsException(); } else { return hand.remove(index, c); } } public int getCardCount() { return hand.size(); } public void sort() { Collections.sort(holder); } public void sort(Comparator<Card> comparator) { Collections.sort(holder, comparator); } }

Looking at these 3 classes, there have some shared method names and some shared implementations. The are also unique methods between the classes but in essense, they are all 'Card Holders'. My aim is to design these classes with OO in mind. I must admit, I am only beginning thinking of OO so any guidance as to what I can do with these 3 classes is appreciated.
By the way, very sorry for the very long post but I thought actual code would better illustrate my dilemma.

I am creating a base class called Deck which will hold cards and will consist of an ArrayList instance variable. Obviously this variable will be private for encapsulation reasons but then how will any class extending the Deck class be able to make changes to methods such as addCard(), removeCard() without access to the ArrayList?
The only thing I can think of is an accessor method to the ArrayList but then that exposes the entire implementation of the class and really makes encapsulation go down the toilet no? - It's the same as making the ArrayList public

The reason I mention this is because I am making a set of interfaces and classes for a card game which will consist of the following:
Interface CardList abstract class CardHolder implements CardList PlayingDeck extends CardHolder //Will add a shuffle() method but needs access to the ArrayList for this ShreddedDeck extends CardHolder //Will override addCard() by adding cards to the end of the list Hand extends CardHolder // Will add sorting methods and other methods requiring access to the ArrayList

Some guidance on the best approach will be appreciated, thanks.

Jimmy Clark wrote:public abstract interface PlayingCardDeck { public void addCard(); public void removeCard(); public int size(); public void shuffle(); } public abstract class BasePlayingCardDeckImpl implements PlayingCardDeck { public void addCard() { } public void removeCard() { } public int size() { } public void shuffle() { } } public final class ShuffledPlayingCardDeckImpl extends BasePlayingCardDeck { ... } public final class ShreddedPlayingCardDeckImpl extends BasePlayingCardDeck { ... }

This is a similar design I came up with but the problem is the shuffle() method which is not something that a ShreddedPlayingCardDeck should have therefore should not be a part of its API which it will be when implementing that interface.

Hi All,

I've decided to go over some old code I wrote to make it a lot more OO friendly but am having trouble with two classes in particular which are extremely similar but also quite different:

public class PlayingDeck { List<Card> deck = new ArrayList<Card>(); PlayingDeck() { //Instantiate and populate list with 52 card objects } public void addCard() { //Adds cards to the end of the ArrayList } public void removeCard() { //Removes cards from the beginning of the ArrayList } public int size() { //return the size } public void shuffle() { //Shuffle the deck } } public class ShreddedDeck { List<Card> deck = new ArrayList<Card>(); ShreddedDeck() { //Instantiated empty, no cards at start } public void addCard() { //Adds cards to the beginning of the ArrayList } public void removeCard() { //Removes cards from the end of the ArrayList } public int size() { //return the size } public Card getFaceCard() { //Returns without removing the card at index(0) } }

The problem I have is that PlayingDeck is the standard deck we all know and love when playing card games such as Poker etc. ShreddedDeck is a deck which will be populated with cards which have been discarded from the PlayingDeck. That is why the implementation of the addCard() and removeCard() is different, the constructor is also different between these classes. Nevertheless, these classes are quite similar so should I add/is there scope for say an interface or an abstract class somewhere?
I was thinking about a Deck Interface with the methods add(), remove(), size() but decks are also shuffled but the shreddedDeck() should never be shuffled.
Any advice/input would be welcome.

Mike Simmons wrote:Unlike other Set implementations, TreeSet doesn't actually use equals() at all. It uses compareTo() instead - if compareTo() returns zero, that means the two objects are "equal" as far as the TreeSet is concerned. Right now, both your Lamborghinis have the same age, and compareTo says they are therefore equal to each other, and the TreeSet allows only one of the Lamborghinis to remain in the set as a result.

If you want to test your hashCode() and equals() methods, use a HashSet, not a TreeSet.

If you want to use a TreeSet and still see all three cars, you need to modify compareTo() so that two different Lamborghinis are not equal. Perhaps after you compare the ages, if the ages are equal, don't return 0 (yet) but instead compare something else, like vehicleID.

Very quick reply! tyvm
I didn't write the code to test the hashCode and equals() methods, I just wrote the Car class primarily to test the TreeSet which is the reason for it being so very basic and implementing Comparable. I wish this book (Kathy & Bert SCJP6 study guide) made clear that TreeSet uses compareTo() rather than equals(); it doesn't mention this fact at all
Again, tyvm

The SCJP6 study guide I am using states that "Your good friend the equals() method determines wheter two objects are identical (in which case only one can be in the set)"
The code I've written below is not following the above statement as far as I can see. There must be something obviously wrong with my code but I can't see it. I cannot figure out why the code is not allowing car3 to be added to the set since equality between cars is based solely on the vehicleID which is unique between my 3 instances. I'm pretty sure I've overidden the equals() method correctly yet whenever I run this code, the System.out.println line in the equals() method does not run when the cars are added to the set and only 2 of the 3 are being added.

import java.util.TreeSet; import java.util.Iterator; public class TreeSetTesting { public static void main(String[] args) { Car car1 = new Car("Lamborghini LP640", 2, 343465734); Car car2 = new Car("Aston Martin DBS", 1, 29086335); Car car3 = new Car("Lamborghini LP640", 2, 297853624); TreeSet<Car> set = new TreeSet<Car>(); set.add(car1); set.add(car2); set.add(car3); System.out.println(set.size()); Iterator it = set.iterator(); while(it.hasNext()) { System.out.println(it.next()); } } } class Car implements Comparable<Car> { String make; int age; int vehicleID; Car(String make, int age, int vehicleID) { this.make = make; this.age = age; this.vehicleID = vehicleID; } public String toString() { return make + " " + vehicleID; } public boolean equals(Object obj) { System.out.println("Reaching here"); if(obj instanceof Car) { if(this.vehicleID == ((Car)obj).vehicleID) { return true; } } return false; } public int hashCode() { return vehicleID; } public int compareTo(Car c) { if(this.age < c.age) { return -1; } if(this.age > c.age) { return 1; } return 0; } }

The output from the above code is:

2
Aston Martin DBS 29086335
Lamborghini LP640 343465734

It should be:

3
Aston Martin DBS 29086335
Lamborghini LP640 343465734
Lamborghini LP640 297853624

Can anyone point me in the right direction?

Thanks

Wouter Oet wrote:Couple of remarks:

Try to "Program against an interface": Set<Card> set = new HashSet<Card>();
Use an enum/boolean for declaring ascending/descending instead of an int.
Some code of the constructor is the same as the setter for cardSuitOrder. Try to eliminate that.

Rename some variables e.g. in compare() you have
int x = 0; //Card c1 suit index
Why not use
int firstCardSuitIndex = 0;

In compare() I would use LinkedHashSet.toArray(T[]) instead of LinkedHashSet.toArray() which makes the casting redundant.
I would create 2 more Comparators, one for Value (with asc/desc) and one for Suit (also with asc/desc) and then delegate the compare method to them.
The compare method contains a lot of duplicate code and the method is long. Try to split it up into methods which can be reused.

Great feedback Wouter, thanks.
I'm implementing all your changes apart from having multiple Comparators. - Having the single one seems logical to me since the code is not too complex and accommodates any values provided via the setters. If I split it up into multiple Comparators based on the diferent sort orders, I would end up with either duplicate code (constructors) or more classes/interfaces to prevent the duplicates code which I think would be overkill for this situation.