richard rehl

A question: in the following code, taken from SB6 Chapter 8 Self Test, I understand how to access the enclosing class method drive() from the inner class constructor and the initializer block. public class Car { class Engine { //{ Car.this.drive();}// initializer block Engine() { //constructor //Car.this.drive(); } Car c = new Car(); //c.drive(); // here's the question: is there a way to call the enclosing class's method from this reference? } public static void main(String[] args) { new Car().go(); } void go(){ new Engine(); } void drive() { System.out.println("hi"); } }
but if I make a new instance of the enclosing class from within the inner class, I'm confused as to why I can't call the same method using that reference.

Absolutely right! Thank you!

Trying to get a class to compile here, need some help. This is from SB SCJP5, Ch. 10, question 12. Given two files:
package pkg; public class Kit { public String glueIt(String a, String b) {return a + b;} } import pkg; class UseKit { public static void main(String[] args) { String s = new Kit().glueIt(args[1], args[2]); System.out.println(s); } }
and the following sub-directory structure:

test
|--UseKit.class
|
com
|--KitJar.jar

I've compiled Kit.class and made KitJar.jar, confirmed by

jar -tf KitJar.jar
META-INF/
META-INF/MANIFEST.MF
pkg/
pkg/Kit.class

Now, here's the problem... trying to compile UseKit.java. If I'm in directory test, I thought that i would compile with

javac -cp com/KitJar.jar UseKit.java

but get the error

UseKit.java:1: '.' expected
import pkg;
^
1 error

Trying to decipher the error, it looks like the compiler can't search the current directory... so I also tried

javac -cp com/KitJar.jar:. UseKit.java

and get the same error. What am I doing wrong?

narendra bhattacharya wrote:in linux based os... / is the root directory but on OSX i don't know...
in windows we have to with write with full path like c:/pro....

Thanks, figured it out, one thing I hadn't tried - has to start with the tilde "~" character instead of the forward slash, so:
java -cp ~/Documents/Java/myProject/classes MyClass
Is this different than Unix or Linux convention?

Actually, OSX.

Question: if I have a class defined in
mycomputername:/~/Documents/Java/myProject/source/Another.class
and I want to invoke it using an absolute classpath, what should my classpath include? I've tried

java -classpath /Documents/Java/myProject Another

and

java -classpath /Documents/Java/myProject/source Another

and

java -classpath /~/Documents/Java/myProject Another

as well as

java -classpath /~/Documents/Java/myProject/source Another

and keep getting NoClassDefFoundErrors. I would have thought that one of these paths would have worked.

Just want to make sure I understand this. From experimenting with an example in Chapter 10, if you have a class file:
package com.wickedlysmart; public class MyClass { public static void main(String[] args){ } } which is saved in the directory:
MyProject/source/com/wickedlysmart/MyClass.java
and compiled into the directory:
MyProject/classes/com/wickedlysmart/MyClass.class
Invoking java on MyClass.class won't work unless
A. you use the fully qualified name com/wickedlysmart/MyClass
B. you are in a directory at least one level above the package root (com), in this case, at least MyProject/classes.
C. Also, if you're currently in another subdirectory defined off the project root, in this case, MyProject/source, you can't say
java ../classes/com/wickedlysmart/MyClass without getting a compiler error.
edit: invoking
java -classpath ../classes com/wickedlysmart/MyClass
DOES work... so figured that one out

And, although SB say that adding a dot to the classpath will cause java to search the current directory, I find that if I'm currently in the directory:
MyProject/classes/com/wickedlysmart
invoking either "java -classpath . MyClass" or "java -classpath . com/wickedlysmart/MyClass" causes a NoClassDefFoundError, which seems to contradict what they say, which leads me to inference B above.

Ernest Friedman-Hill wrote:Congratulations! Yes, I know the feeling.

Very often, the act of explaining something to someone else is enough for you to figure out the problem. This has been called the "rubber duck effect" -- you can explain your problem to an inanimate object like a rubber duck, and you still receive the benefit.

...except, more often than not, I feel like the rubber duck.

I'm just sayin'... I almost bothered you with questions about casting unknown types and accessing static methods, and figured it out on my own.

Almost makes me think I have a chance at learning this stuff

Thanks everyone, especially Ben. I understood the issues with mixing generics with raw types but didn't get what exactly was the problem with this particular code. Onward!

Jim Hoglund wrote:SelectionSort is defined as accepting a type parameter that is passed
on to Comparable<T> and ArrayList<T>. But when SelectionSort
is initialized, where the errors appear, none is provided. Initialization
should look something like below, where CompClass extends Comparable.

SelectionSort<CompClass> sortArr = new SelectionSort<CompClass>(intArr);

OK, not understanding yet... Is it because ArrayList doesn't implement Comparable?

Exercise 21.4 in Deitel JHTP8 is an assignment to alter a sort program to accept generic types. I've got the code to compile and run but had a question about a compiler warning:

Type safety: The constructor SelectionSort(ArrayList) belongs to the raw type SelectionSort. References to generic type SelectionSort<T> should be parameterized.

And here is the code in question:
import java.util.ArrayList; public class SelectionSort<T extends Comparable<T>> { private ArrayList<T> data; public SelectionSort(ArrayList<T> elements){ data = elements; } } import java.util.Random; import java.util.ArrayList; public class SelectionSortTest { private static final Random generator = new Random(); public static void main(String[] args) { int size = 10; ArrayList<Integer> integerArray = new ArrayList<Integer>(size); ArrayList<Float> floatArray = new ArrayList<Float>(size); for (int i = 0; i<size; i++){ integerArray.add(i, generator.nextInt(100)); floatArray.add(i, generator.nextFloat() * 100); } SelectionSort sortIntegerArray = new SelectionSort(integerArray);//these two lines give the SelectionSort sortFloatArray = new SelectionSort(floatArray);//compiler warnings } }
I'm just getting started understanding generics. What should I do to get rid of these warnings?>

Henry Wong wrote:
Personally, I would find it really annoying if it did that. Exceptions are for exception conditions. Reporting that the file doesn't exist, when the task is to check if the file exist, is hardly an exception condition.

I guess the reason I ask is that there already is a method to do just that, File.exists(). File.isFile(), on the other hand, would seem to be a method that assumes that a file exists and checks to see if it is actually a file. In which case, if the file really wasn't there, it would make sense to throw an exception. Seems logical to me.

Given:
import java.io.*; public class Directories { static String[] dirs = {"dir1", "dir2"}; public static void main(String[] args) { for (String d: dirs){ String path = d; File file = new File(path, args[0]); System.out.print(file.isFile() + " "); } } } and that the invocation java Directories file2.txt is issued from a directory that has two subdirectories, "dir1" and "dir2", and that "dir1" has a file "file1.txt" and "dir2" has a file "file2.txt".

Question: why is the output "false true"? The first time through the for loop, path = "dir1", and file = ("dir1", "file2.txt"), but file2.txt doesn't exist in that directory. So why isn't a FileNotFoundException generated instead?

Update: never mind, just looked in the API and see that it

Returns:
true if and only if the file denoted by this abstract pathname exists and is a normal file; false otherwise
Throws:
SecurityException -

So I guess my question is aimed more at the Java developers - wouldn't it make more sense if this method threw a FileNotFoundException if a file wasn't found? Hm?

OK, so let me get this straight. Even though overridden methods may throw narrower or fewer exceptions, if the superclass method throws a checked exception, and there's a superclass reference to a subclass object, and that reference calls the overridden method, the subclass method then must throw the same exceptions?