We Keep Coding

why compile non-static inner class will creation of hidden, package-visible methods on the parent class [duplicate]

This question already has answers here:
What's the penalty for Synthetic methods?
(2 answers)
Closed 4 years ago.
IDEA said
Reports non-static inner classes. Compilation of such classes causes the creation of hidden, package-visible methods on the parent class, which may compromise security.
So I want to know what this meaning.
demo code
public class TaiquShortV2 implements Serializable {
private static final long serialVersionUID = 1L;
class TaiquData implements Serializable {//IDEA report TqiquData Class
private static final long serialVersionUID = 1L;
}
}

We have to distinguish between the source code and the JVM level.
At the source code level, the inner class Inner can access e.g. private fields of the enclosing class Enclosing.
At the JVM level, there is no concept of an inner class: an inner class is just an independent class with a special name (typically containing a $ sign, e.g. Enclosing$Inner), located in the same package as the Enclosing class. Just like any other class, this Enclosing$Inner class can't access Enclosing's private fields. To allow access to the private fields (as source code level demands), the compiler plays a trick: it secretly adds getters and setters to the fields, unter synthetic names (not the classical getField() and setField() names), and has the inner class use these access methods instead of a direct field access. And as both classes are in the same package, the access methods need to allow at least package visibility, and that's how they are created by the compiler.
So, these methods make it possible for any other class declared in the same package, to access private fields of the Enclosing class, breaking the normal encapsulation of private fields.
It's up to you to decide if that risk matters, as from within Java there are other possibilities to break the access rules. So, personally I've always happily created inner classes where appropriate from an architectural point of view.

Inner classes (non static) are like any other attribute or method of the class, they have access to other members. But static classes do not have this access.
So may be IDEA is warning you that if you do not need to access other members inside your nested class then it is better to make it static.
Please provide your code to better analyze it.
you can also look at this thread

Private, Protected, Public and me confused [closed]

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
What is the benefit of using public private protected keywords in method declarations?
I can imagine the benefit of public private protected keywords for variables because it will prevent unnecessary "value change" by objects outside the particular class
but I cannot imagine the benefit of putting the keyword "private" or "public" or "protected" in method declarations.
If there is a method, it is my belief that the only object(s) that can use the method is the object that contains that method anyways?

First of all, let's clarify the meaning of public, protected, package, and private access. In each case, you are correct that an object must exist to use a non-static method. However, these keywords indicate who is allowed to invoke the method on the object:
public methods can be invoked by anyone.
protected methods can be invoked by any class in the same package or subclasses in other packages.
package private methods (without any access modifier) can be only invoked by classes in the same package.
private methods can be invoked only by the same class.
As an example, I often use private methods to factor out code which is otherwise repeated among several different methods. This code isn't part of the public interface for other classes to use. Rather, it is a "worker" method that does some of the calculations internal to the class itself.

public means the method can be override, and is available for use by any code for which the enclosing class is visible.
private means the method is usable only by the enclosing class.
protected means that the method is callable only by the enclosing class, and any class that extends that class.
package (no keyword before the method) means that the method can be called by any code within a class in the same package as the enclosing class.
In Java, difference between default, public, protected, and private
These different keywords are useful in designing how your class will be used. public methods are part of the "contract" you are exposing to the users of your class. private methods are typically implementation code that should not be exposed in any way to the outside world because you want to hide that logic in case you want to replace or modify it in the future without breaking your "contract" with the class' users.
protected methods are available to classes that extend your class. So maybe there's some implementation that you want to make available for overriding -- or perhaps you need an extending class to implement this method in order to make your class work, but it's not part of the "contract" your exposing to callers of your class or those calling the extending class.
Use package to create implementation code that other classes in the package can call, but that you don't want to expose to those using your class (not part of your "contract" with your users.) I use package level methods if I need to test some tricky implementation code from a unit test, but don't want to make the method public.

To understand the benefit of restricting access to a method, consider this : You can safely change or even remove a private method from a class, because you know it's only ever accessed from within that class. If you are publishing an API, and you expose a public method, then its out there for good. If you try to change it, you will break code that relys on it being available. You have to think about how code will evolve over time to fully appreciate this.
If there is a method, it is my belief that the only object(s) that can
use the method is the object that contains that method anyways?
No, not true. Methods can be declared static, which means they do not require an object to be invoked on.

What is the explicit constructor access modifier? [closed]

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
Suppose there is a class A. Which of the following two access modifiers is a default one for a constructor?
public A()
{
private A()
{
//some code....
}
protected A()
{
//some code....
}
}

It means the exact same thing as modifiers to functions and variables, only now it refers to who can CONSTRUCT an instance of the class.
public - any one can call the constructor from anywhere in the code.
private - Unable to construct from outside the class - typically used to enable control over who gets to instanciate the class with the use of a static member factory method. A good example of an appication found here
protected - Like private but now inheritance is involved - any subclass factory method can be used because now they can call this constructor.
As #dasblinkenlight mentions, if you do not specify any modifier, then they default to being package-private, meaning they are only visible to classes within the package.

Best practice for inner/anonymous classes [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
What's the best practise(design and performance wise) for anonymous classes and static inner classes?
Personally I would like to think that static inner classes provide better encapsulation and should give better performance as they dont have access to finalized variables outside their class. But I've never really questioned this.
I found one post about this but I felt it didn't actually answer the question about, just peoples personal thought about it.

Inner classes (static or not) have exactly the same access to their enclosing class' fields and methods as anonymous classes, the difference between static inner classes (actually called nested classes) and (regular, non-static) inner classes being that the static one need an explicit reference to an instance of the enclosing class to access something. Of course, when you need to do that, it's usually on the instance of the enclosing class that created the inner class, so it's easier and clearer to use a non-static inner class.
Examples:
Inner class (non-static)
class A {
private int field;
private class B {
public void doSomething() {
field++; // Valid
}
}
}
Nested class (i.e. "static inner class")
class A {
private int field;
private static class B {
public void doSomething(A a) {
a.field++; // Valid
}
}
}
Anonymous class
class A {
private int field;
public void doSomething() {
new Runnable() {
#Override
public void run() {
field++; // Valid
}
}
}
}
Whether you use that accessibility is another question. If you do access private fields of the enclosing class, there'll be an accessor generated, so it could impact the performance as the cost of calling a method is not the same as accessing a field, but it will probably be negligible in most cases. You should always write correct code first (both in terms of design and functionality) before doing micro-optimizations not based on any measurement. The JIT compiler does a lot of things for you anyway.

Have look in Java source code Collections and Pattern to have sample (they are in the src.zip in the JDK directory. In Eclipse, you can read the code with inline help
Read a book Effective Java, look for inner class to understand how works static, inner and other useful interface, enum and other classes

Importing Classes and Inheriting a Class [closed]

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
This is just a small one but i just need more clarity on these two.

By import you tell the compiler that my program is going to use imported classes so please make them available.
import java.util
By inheriting class you are going to use class properties and functions (which are being inherited) in child class.
class Maruti extends Car{
}

import allows you to use the imported class in the class you're currently writing.
Inheriting, or using the extends keyword allows you to implement the current class with the functionality of the class you are inheriting from.
For instance:
public class Animal
{
public void walk()
{
System.out.println("i am walking");
}
}
public class Cat extends Animal
{
public void meow()
{
System.out.println("Meow!");
}
public static void main(String[] args)
{
Cat catAnimal = new Cat();
cat.walk();
cat.meow();
}
}
So as you can see in the above example, because Cat extends Animal the Cat class can do everything the Animal class can.

import lets you see the class so you can inherit (aka extend) it.

Importing classes are simply allowing your class to have access to these classes without using their fully qualified names.
For example, if you have the following:
import javax.swing.JFrame;
public class Main{
//this class has ACCESS to the JFrame class, but it isn't a JFrame because it doesn't inherit (extend) from one
}
Your Main class would have access to the methods and variables in the class javax.swing.JFrame without having to call it with that full name, it allows you to simply use JFrame.
Inheriting a class is extending your own class to gain access to a classes methods and variables because your class "is a" inherited class.
Here is some code that doesn't "import" JFrame, it uses its fully qualified name to extend itself so that it has access to every method/variable inside the JFrame class (as long as the modifier is public or protected).
public class MyFrame extends javax.swing.JFrame {
//this class IS a JFrame, and is not importing one, it's instead using the fully qualified name to extend itself and make it a JFrame.
}