Kamil Hlubek

Thank you very much for your response.

it would probably have been better to use the appropriate Enthuware forum to report the issue.

I looked at the forum, but I simply could not find the appropriate category to post it. I hope Paul will recognize this thread, as you sad he do visit this forum.

I think I have found an error in the question enthuware.ocajp.i.v8.2.834:

Another alternative is to catch this exception in myMethod:

public void myMethod(){     try{       yourMethod();     }     catch(Exception e){ // since you are catching the exception thrown by yourMethod, // there is no need to declare it in the throws clause of myMethod.        e.printStackTrace);    } }

Further, since a call to myMethod cannot throw Exception anymore, main method does not need to declare it either.

and after it:

  public static void main(String[] args) {         TestClass tc = new TestClass();         try{           tc.myMethod();         }        catch(Exception e){  // since you are catching the exception thrown by myMethod, // there is no need to declare it in the throws clause of main.          e.printStackTrace);        }     }

Here is written "e.printStackTrace);", but it should be "e.printStackTrace();". It is a little error, but I think it is better to mention it. ( I hope it is okay, that I quoted a little part of the explanation )

Hi guys,

could you answer me an instruction of how and when to use the super reference with interfaces ( like for example for default-methods ), please. I would be also very thankful if you could explain me when you do not need the super reference if you use it with interfaces.
I am asking you that, because this is one subject of Java 8, but I can not find a good guide to it and I want to understand it completely and not try it only out with a chance that something of my explanation could be false.

So a summary of that topic would be very helpful.

Yours sincerely,

Kamil

Roel De Nijs wrote:

Kamil Hlubek wrote:To be more precisely: The class BlackInk inherits from Ink, but nobody of them implements the Printable interface, so it should not compile in my opinion, because the reference's variable type and the type to cast to are in different hierarchys

The only reason why the above code compiles, is because the BlackInk class is not final. That means somebody can create a subclass which implements the Printable interface, like class SuperDuperBlackInk extends BlackInk implements Printable {}And then it's perfectly valid to change line8 toBlackInk blackInk = new SuperDuperBlackInk();And then the TwistInTaleCasting class will compile successfully and execute without any runtime exceptions.

And as you probably already have understood from this explanation, if you would change the BlackInk class declaration tofinal class BlackInk extends Ink{}you'll get the "incompatible types" compiler error.

For more detailed information have a look at this thread (about exactly the same code snippet), this thread (also similar code snippet and an additional one) and this thread (about casting or using instanceof operator on a class vs an interface).

Hope it helps!
Kind regards,
Roel

Thank you for the good ( and fast ) response !

I am going to read all the threads you have posted and understand everything about the ClassCastException.

Hi guys,

I have a question, because of the ClassCastException and the compiler errors, which occur if you cast a reference's variable type in a type of a complete different hierarchy than the reference's variable type actually is.

Here is the code I do not understand completely:

class Ink{} interface Printable {} class ColorInk extends Ink implements Printable {} class BlackInk extends Ink{} class TwistInTaleCasting { public static void main(String args[]) { Printable printable = null; BlackInk blackInk = new BlackInk(); printable = (Printable)blackInk; } }

My question now is, why the code compiles ( I am awared of that the code throws a ClassCastException at runtime ) generally?
I am asking this question, because if a class should be cast into another class ( or here the interface Printable ), then the class to be casted have to pass the IS-A test with the type to cast and if the reference variable's type and the type to cast to are in different hierachies, then the compiler does not allow it and a compiler error occurs, which sounds like "incompactible types: X cannot be converted to Y".

To be more precisely: The class BlackInk inherits from Ink, but nobody of them implements the Printable interface, so it should not compile in my opinion, because the reference's variable type and the type to cast to are in different hierarchys, but it compiles, what should have to do with that, that the compiler can not check the implemented interfaces or something like that.
I have tried to make of the interface a class and it did not work, so you guys would only have to think about it, where I stopped if you want to help me, wherefore I would thank you very much.

Hi guys,
I would like to inform you, that the new Java magazine (http://www.oracle.com/technetwork/java/javamagazine/index.html )is now available and you can find there a few questions taken from the 1Z0-809 Java Programmer II.

Good look in solving them,

Kamil

Now I know, that it is clearly about the relation of the identifiers Test and test, because this result( the code a the bottom of this reply ) is a completly different error, but if I change only the identifier of the interface or of the class, It works.

Code:

public class Test implements test{ int i = 3; void print(){ System.out.println( i ); } public static void main( String[] args ) { new Test().print(); } } interface test{ int i = 2; }

Error:

Fehler: Hauptklasse Test konnte nicht gefunden oder geladen werden ( this is german and means, that the main class Test could not be found or loaded )


I look forward to the replies of your.

Yes, I actually noticed the compiler does not create the Test.class file, but I forgot to write it in my question.

I compiled the code in a new folder ( you can see the result in the picture above ), but it is the same. I read not long ago, that NoClassDefFoundError has some more point, why it can occur, but if the error does not occur in your testing it is a little thing to thing about.

Hi guys,

I wrote code for myself, as suddenly something strange happened, I got the NoClassDefFound-Error, because the name of a class is false. Here ist the code snippet and the error message from the command line:

interface test{ void print(); } class Class1 implements test{ public void print(){ System.out.println("Class1"); } } class Class2 implements test{ public void print(){ System.out.println("Class2"); } } public class Test{ public static void main( String[] args ) { test T1 = new Class1(); test T2 = new Class2(); T1.print(); T2.print(); } }

This code is int the file "Test.java" and if I execute it with javac and java I get this error from the command line:

C:\Users\Kamil\Desktop>javac Test.java

C:\Users\Kamil\Desktop>java Test
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.NoClassDefFoundError: test (wrong name: Tes
t)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access$100(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Unknown Source)
at java.lang.Class.privateGetMethodRecursive(Unknown Source)
at java.lang.Class.getMethod0(Unknown Source)
at java.lang.Class.getMethod(Unknown Source)
at sun.launcher.LauncherHelper.validateMainClass(Unknown Source)
at sun.launcher.LauncherHelper.checkAndLoadMain(Unknown Source)

C:\Users\Kamil\Desktop>

But if I change only the identifier of the used interface from test to est for example, the code fully compiles and execute:

C:\Users\Kamil\Desktop>javac Test.java

C:\Users\Kamil\Desktop>java Test
Class1
Class2

C:\Users\Kamil\Desktop>

So why this error is comming up, when Java is case-sensitive?

My guess is, that in the JLS is a bottom line and I do not know anything of it, so I would be happy if someone could explain my the previusly mentioned behavior.

Thank you for your help,

Kamil

Thank you, but what is meaning the fifth number in http://docs.oracle.com/javase/specs/jls/se7/html/jls-12.html#jls-12.4.2?

Thank you very much!

Hi everyone,

In the OCAJP 7 Summary by Bagdoury Mohammed Amine ( yes, again ) is written :

An interface’s variables are implicitly public, final & static. They should be assigned at declaration. It’s methods are implicitly public and they can’t be final or static.

My question is now, how you can assign a public final static variable in another statement, because there is written "should be assigned" and not have to, but everytime I ever tried to assign such a variable in different statements I got a compiler error.
It would be also nice if somebody could write me in which extract you can read all the stuff with the constants ( that means, when you have to initialize a constant and when not etc. ) in the JLS.

In the OCAJP 7 Summary from Bagdouri Mohammed Amine is written, that if the JVM finds a null exception in the catch header, a NullPointerException will be thrown, but how you can reach it, that you get a null exception in the catch header?

Could someone describe the ExceptionInIntializerError and the NoClassDefFoundError, please , because I just has been reading about the NoClassDefFound exception and that it is named terribly and it is not explained in the API good enough ( Here is the source ).
I would be also happy if you could explain me when this two exceptions may occur.