Instantiation error - java

I am following a beginner's java book and one of the projects is to pick an error from commonly thrown errors and try to do what you can to induce the error.
I picked InstantiationError and am up to the level of knowing you can't instantiate abstract classes or interfaces. The docs says the error is usually caught by the compiler but can be thrown at runtime if the definition of a class has incompatibly changed.
I don't know how a class definition could be changed while the program is running and am looking for some tips on where I should read further.
Thanks!

I don't know how a class definition could be changed while the program is running
It can't change while it's running but it can change after you've compiled.
For example, try this:
// In Test.java
public class Test {
public static void main(String[] args){
System.out.println(new Foo());
}
}
// In Foo.java
public class Foo {
}
Compile:
javac Foo.java Test.java
Run:
java Test
// Some output like this...
Foo#1d6535bf
Now change Foo.java like this:
// No parameterless constructor any more!
public class Foo {
public Foo(int x) {
}
}
Recompile just Foo.java:
javac Foo.java
And rerun Test:
Exception in thread "main" java.lang.NoSuchMethodError: Foo: method <init>()V
not found
at Test.main(Test.java:3)
This is not what I'd call a "commonly thrown error" though.
Note that that's not InstantiationError - but you can change Foo.java again, to:
public interface Foo {
}
Again, just recompile Foo.java and this time you'll get:
Exception in thread "main" java.lang.InstantiationError: Foo
at Test.main(Test.java:3)

Maybe when you instantiate an abstract class at runtime using reflection.
Code sample:
public abstract class MyAbstractClass{
}
public class MyMainClass() {
public void test(String[] args) {
this.getClass().getClassLoader().loadClass("MyAbstractClass").getConstructors()[0].newInstance();
}
}

Have a look at the Reflection API, which offers a way to instantiate a class by name.
public void throwError() {
AbstractType type = this.getClassLoader().newInstance("my.abstract.Type");
}

a simple thing that can cause this type of error is if you try to create an object with the wrong number of parameters. say the constructor takes two parameters, but you have your interface designed in such a way that the user could input 3 or more parameters. normally, the number of parameters would be caught by the compiler, but if it was created "on the fly" then it would get caught at runtime

Related

javac gives no warning when a class with default access contains public members

Regarding the example code below, although the Test() constructor inside the class Test is public, the class Test itself isn't public, and so the Test() constructor can't be called from outside its own package.
Does that make the public keyword redundant? If so, I wonder why javac doesn't issue a warning about the redundant use of public, when used inside a class whose access is implicitly declared as default ("package private")?
Test.java, package test -
package test;
class Test {
public Test() {}
}
Main.java, package main -
package main;
class Main {
public static void main(String[] args) {
new test.Test(); // Expected error
}
}
EDIT:
Just to be clear: it's when I compile Test.java, that I get no warning.
The user comments made to my original post have helped me solve this problem: I now realise that an IDE will give me the information that I was after, and that just using javac on its own will not. Thanks.

Binary compatibility issue - an example?

As far as I understand the source compatibility and how you can easily show an example that would break source compatibility (change name of the method, remove method etc.), I am having a bit of a problem seeing how binary compatibility can be broken in practice. Does anyone have a simple example of preservation of source compatibility that would cause binary compatibility issues i.e. no code changes are required but recompilation is necesssary?
One example (and this is by no means the only one) would be if the signature of a method in a library changes, in a compatible way. For example, consider:
// Library.java v1
public class Library {
public static void print(String foo) {
System.out.println(foo);
}
}
// Client.java v1
public class Client {
public static void main(String[] args) {
Library.print("hello");
}
}
Compile and run:
$ javac Client.java Library.java
$ java Client
hello
Now change Library.java - note the type of the foo parameter:
// Library.java v2
public class Library {
public static void print(Object foo) {
System.out.println(foo);
}
}
Just recompile Library.java and try to rerun Client:
$ javac Library.java
$ java Client
Exception in thread "main" java.lang.NoSuchMethodError: Library.print(Ljava/lang/String;)V
at Client.main(Client.java:3)
First need to understand both compatibility.
Source compatibility - Program is source compatible with new version if Program can be compiled with that new version of code(library or api)
Binary compatibility - Program is binary compatible with new version of code if Program can be linked with that code without recompilation
Following link has more example for "Source compatible but Binary incompatible "
Specialising Return Types
Generalising Parameter Types
Primitive vs Wrapper Types
Read http://praitheesh.blogspot.com.au/2014/09/compatibility-and-api-evolution-in-java.html for more details.
If you import an interface with string constants.
(An anti-pattern in Java.)
Then the importing class copies the constants in the constant table, and uses those constants immediately. The import dependency to the interface then is missing.
When the string value of the constant in the interface is changed, the compiler does not see that it needs to recompile the class that will remain using the old value - as there is no longer an import to the interface.
The running is not broken, but the behaviour is - wrong value.
An example I met :
public class Class1 {
public void do() {
System.out.println("do!");
}
}
Client part :
public class Class2 {
public void callDo() {
Class1 c = new Class1();
c.do();
}
}
Now you change the return of do method :
public class Class1 {
public String do() {
System.out.println("do!");
return "done!";
}
}
If you run the client code without a recompilation you will get a NoSuchMethodError exception because the method signature has changed.

What if main method is inside "non public class" of java file?

I have a java file containing more than one class, out of which one is public. If main method is inside a non-public class. I can't run that java file. Why is that? and there is no compilation error as well. If so, how can I use that main method?
Actually you can execute the main method in a non-public class. if you put this class
class A {
public static void main(String... args) {
System.out.println("This is not a public class!");
}
}
in a file named NonPubClass.java. You can compile this file using javac command but you will not get a NonPubClass.class, you will get a A.class instead. Use java a to invoke that class and you will see the printed string --- This is not a public class!
Have a look at this code:
Super.java
public class Super{ }
class Sub{
public static void main(String[] s){
System.out.println("Hello");
}
}
In order to print Hello you can compile and run the program as:
How this works?
The compiler generates separate .class file for every class in your program. So, instead of calling the main() of non-public class from the public class's main() you can print the output as shown above.
Note: As the convention says, you must put a public class in separate file <class_name>.java. And do not put more than one class in a single file (except if they are inner class) because if you would like to import them or use them with other classes then it will cause problem.
there is something i would like to add although everybody here believes that a public is necessary for the main in a class and that it won't work without main
you can have as many mains in a class as you desire, and you can have them without a public access modifier.
but be careful, only that class which is named after the file can be public
what i mean is if you name your file a.java , then only the class with name a can be public, none other can have this facility
here is a code to show this :
as you can see the name of the file is helping.java
//:initialization/helping.java
class b{
public static void main(){
System.out.println("hello its b");
}
}
class helping {
static void f(float i, Character... c) {
System.out.println("first");
}
static void f(char a, Character... args) {
System.out.println("second");
}
public static void main(String[] args) {
f(1,'a');
f('a','b');
c.main();
}
}
class c{
public static void main(){
System.out.println("hello its b");
}
}
//:~
/*
* output:
* first
* second
* hello its b
* */
Simple Answer. You can't. You need to have main method in a public class and its signature should be public static void main(String... args)
there is no compilation error
Why there would be? You are doing nothing wrong as far as compilation rules are concerned.
Only thing is that your non-public-class-main-method won't work as an entry point of your code.
It is a compile-time error if a top level type declaration contains any one of the following access modifiers: protected, private, or static.This link may be helpful.
It's not a compile time error as u mentioned that top level type declaration shouldn't be protected, static or private.
If u go through the link http://docs.oracle.com/javase/specs/jls/se7/html/jls-7.html#jls-7.6 well that u have shared ,then it's quite clear there that a top-level type declaration refers to only "top level Class and Interface type declarations" and these should not be protected, static or private at top level declarations, but we can use protected, static or private for any methods or variable declaration inside them.
With respect to above code, there is nothing wrong in declaration, and the code will compile and run successfully as all outer top level class are default and there is no violation.
The answer to the question asked at top is exactly as mentioned by few experts at top, that
"for sure we can have a file with main method inside non-public class and it will compile as well as run successfully, but make sure that at the time of running the program we have to pass the class name of "main method" to the java interpreter instead of the class which is public."
If we have 2 classes A(public) and B(non-public containing main method) , then the file will compile with "javac A.java" but while running the code we need to pass the command as "java B" .
You can certainly override main method and it does not violate any compiler rules and hence you will not have any compiler errors.
You check that inspite of the fact that you have more than one class a file that is declared as public is the name of the file you are trying to execute.
This is a convention that the file should be named after the same class which is public in that code.
Hence when you try to execute that class it does not have a main method from which it starts execution.So if you want to execute the main method in the non public class the only way to this is call that main from a main method of the public class.

NoClassDefFoundError

I have an issue where NoClasDefFoundError is being thrown. It puzzles me since I am using interfaces, and no class definition should be available. I have read through some posts which point to Classpath, but I don't believe that to be the issue here (although I may be wrong). I am using NetBeans 6.9.1 IDE.
I have created a sample setup to reproduce the issue. Four projects: Interfaces, Objects, Locator and Consumer. Below you will find the implementations.
At runtime consumer coplains about missing SomeObject implementation, which it should not be aware of since it is accepting interface.
Exception in thread "main"
java.lang.NoClassDefFoundError:
objects/SomeObject
What am I missing?
package interfaces;
public interface ISomeInterface { }
package objects;
import interfaces.ISomeInterface;
public class SomeObject implements ISomeInterface{ }
package locator;
import interfaces.ISomeInterface;
import objects.SomeObject;
public class Locator { public static ISomeInterface LocateImplementation() { return new SomeObject(); }}
package consumer;
import interfaces.ISomeInterface;
import locator.Locator;
public class Main { public static void main(String[] args) { ISomeInterface object = Locator.LocateImplementation(); }}
You can get a NoClassDefFoundError exception with interfaces just as you can with classes. Consider the "Class" in the name of the exception to be the .class file that is generated from compiling a class or interface, not a Java class.
This is saying that the class/interface objects.SomeObject isn't visible on your classpath. Check the location of that .class file and ensure that it's on your classpath - if you're positive it's there, give us some screen shots or something that might help to debug the problem.
Think of NoClassDefFoundError as a runtime linkage problem. JRE loaded one class (or an interface) and it references another class (or an interface), but that referenced class isn't found.
The only way this can happen if you have packaging/classpath issues such that your runtime environment doesn't reflect how things are at build time.
If you are launching this from IDE, make sure that you aren't ignoring any errors and launching anyway. Some classes will not be generated that way.
Usually I run into these problems not when a class is missing, but when there is an error in the static initializers.
Try running your code in a debugger, and set the exception breakpoint to break when any exception is thrown, whether caught or not. I bet you have an uncaught exception in the static initializer for some reason.
In the locateImplementation() method you are returning "new SomeObject()",
JVM needs to have its definition when called. I think it is missing.
You should check if your SomeObject class is in class path because -
Well the JVM will be running the below code -
ISomeInterface object = Locator.LocateImplementation();
and when it does that it will call Locator.LocateImplementation(). This code internally tries to instantiate your SomeObject class which it does not find in the classpath.
So your below understanding
It puzzles me since I am using
interfaces, and no class definition
should be available.
Is not really valid.
Any Interface must be declared inside class
public class Calbacks {
public interface IBaseFragmentInterface {
void NotifyMainActivity();
}
}

Java: Multiple class declarations in one file

In Java, you can define multiple top level classes in a single file, providing that at most one of these is public (see JLS ยง7.6). See below for example.
Is there a tidy name for this technique (analogous to inner, nested, anonymous)?
The JLS says the system may enforce the restriction that these secondary classes can't be referred to by code in other compilation units of the package, e.g., they can't be treated as package-private. Is that really something that changes between Java implementations?
e.g., PublicClass.java:
package com.example.multiple;
public class PublicClass {
PrivateImpl impl = new PrivateImpl();
}
class PrivateImpl {
int implementationData;
}
Javac doesn't actively prohibit this, but it does have a limitation that pretty much means that you'd never want to refer to a top-level class from another file unless it has the same name as the file it's in.
Suppose you have two files, Foo.java and Bar.java.
Foo.java contains:
public class Foo
Bar.java contains:
public class Bar
class Baz
Let's also say that all of the classes are in the same package (and the files are in the same directory).
What happens if Foo refers to Baz but not Bar and we try to compile Foo.java? The compilation fails with an error like this:
Foo.java:2: cannot find symbol
symbol : class Baz
location: class Foo
private Baz baz;
^
1 error
This makes sense if you think about it. If Foo refers to Baz, but there is no Baz.java (or Baz.class), how can javac know what source file to look in?
If you instead tell javac to compile Foo.java and Bar.java at the same time, or if you had previously compiled Bar.java (leaving the Baz.class where javac can find it), or even if Foo happens to refer to Bar in addition to Baz, then this error goes away. This makes your build process feel very unreliable and flaky, however.
Because the actual limitation, which is more like "don't refer to a top-level class from another file unless it either has the same name as the file it's in or you're also referring to another class that's named the same thing as that file that's also in that file" is kind of hard to follow, people usually go with the much more straightforward (though stricter) convention of just putting one top-level class in each file. This is also better if you ever change your mind about whether a class should be public or not.
Newer versions of javac can also produce a warning in this situation with -Xlint:all:
auxiliary class Baz in ./Bar.java should not be accessed from outside its own source file
Sometimes there really is a good reason why everybody does something in a particular way.
My suggested name for this technique (including multiple top-level classes in a single source file) would be "mess". Seriously, I don't think it's a good idea - I'd use a nested type in this situation instead. Then it's still easy to predict which source file it's in. I don't believe there's an official term for this approach though.
As for whether this actually changes between implementations - I highly doubt it, but if you avoid doing it in the first place, you'll never need to care :)
I believe you simply call PrivateImpl what it is: a non-public top-level class. You can also declare non-public top-level interfaces as well.
e.g., elsewhere on SO: Non-public top-level class vs static nested class
As for changes in behavior between versions, there was this discussion about something that "worked perfectly" in 1.2.2. but stopped working in 1.4 in sun's forum: Java Compiler - unable to declare a non public top level classes in a file.
You can have as many classes as you wish like this
public class Fun {
Fun() {
System.out.println("Fun constructor");
}
void fun() {
System.out.println("Fun mathod");
}
public static void main(String[] args) {
Fun fu = new Fun();
fu.fun();
Fen fe = new Fen();
fe.fen();
Fin fi = new Fin();
fi.fin();
Fon fo = new Fon();
fo.fon();
Fan fa = new Fan();
fa.fan();
fa.run();
}
}
class Fen {
Fen() {
System.out.println("fen construuctor");
}
void fen() {
System.out.println("Fen method");
}
}
class Fin {
void fin() {
System.out.println("Fin method");
}
}
class Fon {
void fon() {
System.out.println("Fon method");
}
}
class Fan {
void fan() {
System.out.println("Fan method");
}
public void run() {
System.out.println("run");
}
}
Just FYI, if you are using Java 11+, there is an exception to this rule: if you run your java file directly (without compilation). In this mode, there is no restriction on a single public class per file. However, the class with the main method must be the first one in the file.
1.Is there a tidy name for this technique (analogous to inner, nested, anonymous)?
Multi-class single-file demo.
2.The JLS says the system may enforce the restriction that these secondary classes can't be referred to by code in other compilation units of the package, e.g., they can't be treated as package-private. Is that really something that changes between Java implementations?
I'm not aware of any which don't have that restriction - all the file based compilers won't allow you to refer to source code classes in files which are not named the same as the class name. ( if you compile a multi-class file, and put the classes on the class path, then any compiler will find them )
Yes you can, with public static members on an outer public class, like so:
public class Foo {
public static class FooChild extends Z {
String foo;
}
public static class ZeeChild extends Z {
}
}
and another file that references the above:
public class Bar {
public static void main(String[] args){
Foo.FooChild f = new Foo.FooChild();
System.out.println(f);
}
}
put them in the same folder. Compile with:
javac folder/*.java
and run with:
java -cp folder Bar
According to Effective Java 2nd edition (Item 13):
"If a package-private top-level class (or interface) is used by only
one class, consider making the top-level class a private nested class
of the sole class that uses it (Item 22). This reduces its
accessibility from all the classes in its package to the one class
that uses it. But it is far more important to reduce the accessibility
of a gratuitously public class than a package-private top-level class:
... "
The nested class may be static or non-static based on whether the member class needs access to the enclosing instance (Item 22).
No. You can't. But it is very possible in Scala:
class Foo {val bar = "a"}
class Bar {val foo = "b"}

Categories

Resources