Win a copy of Bad Programming Practices 101 (e-book) this week in the Beginning Java forum!

Kristian Perkins

Ranch Hand
+ Follow
since Mar 27, 2006
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 Kristian Perkins

Hi,

It looks like your problem is that c.class exists inside the jar file as a/c.class but c does not belong to the a package but exists in that package in the my.jar jar file. Either add the class 'c' to the 'a' package or move c.class out of the a directory in the jar file.

If you do a list of my.jar you get something like this. c is listed as being inside the a package/directory so will not be found.

It is also possible that the method foo could try to modify the contents of the array by trying to insert the wrong object type into it, e.g.



causing an ArrayStoreException to be thrown from method foo.
[ August 26, 2006: Message edited by: Kristian Perkins ]
The dot point in question explains this: "Polymorphic assignments applies only to base type, not the generic type parameter". Go back through the section on Polymorphism and Generics from page 582.
Java keywords are lower case, strictfp not Strictfp
public is the only access modifier allowed for interface methods, so a default access modifier of anything other that public would not make sense.
You access a static inner class through the outer class just as you would any static variable or method. So new Test.inner().show() is creating a new instance of the Test.inner class using its default constructor, then calling the show() method on the newly created Test.inner instance.
[ May 01, 2006: Message edited by: Kristian Perkins ]
Given that java code can be written in unicode, the Lexical Translation is applied to all java code at compile time so you can use unicode identifiers etc using only ASCII characters. So before a file is compiled all '\uxxxx' occurences in the file will be translated into their unicode equivalent. If you check out an ASCII table, you will find that chars 10 (\u000A) and 13 (\u000D) are line feed and carriage return respectively, so a new line will start straight after these tokens (I doubt you will see this in the exam).

The code

will be translated into

which of course won't compile.
[ May 01, 2006: Message edited by: Kristian Perkins ]
Mark,

This is not an error. Table 2.1 refers to the code sample at the top of page 105 where the eat() method does not declare that is throws an exception, not the code in the exam watch on the previous page where the eat() method does declare that is throws an exception.

Kristian
Alberto,

This is not an error. I compiled the code myself, it compiles. They are all instance variables. I would recommend posting a new topic for feedback to this question.




Alberto Cancello wrote:
...but I think is...


For complete certainty in code samples, the best way to learn is to compile and run the samples yourself.

Kristian
[ April 27, 2006: Message edited by: Kristian Perkins ]
This topic has been addressed a few times in this forum, here is one of the latest (which includes back links to even more discussions on it).
There are methods in the NumberFormat API to change the minimum/maximum integer and fraction digits displayed.
faisal usmani pretty much answers your question here.
Compile this code:


If method() was inherited in InnerFinal we would get a compile time error because of an incompatible return type on the inner class method(). But we don't, this code compiles fine because of the (pseudo) implicit final applied to the method() method.

Notice also if you change the access modifier of FinalTest.method() to anything else (protected, public or default) the code will not compile due to the error mentioned in the previous paragraph.

[ April 24, 2006: Message edited by: Kristian Perkins ]
[ April 24, 2006: Message edited by: Kristian Perkins ]
From JLS
8.4.3.3 final Methods:

A private method and all methods declared immediately within a final class (�8.1.1.2) behave as if they are final, since it is impossible to override them.
[ April 24, 2006: Message edited by: Kristian Perkins ]
Eddie,

No it is not legal and is mentioned in the updated errata