We Keep Coding

Eclipse New Java Class Wizard in VS Code

Is there a way to create Java class in VS Code similar to Eclipse New Java Class Wizard?
I would like VS Code to add package and class declarations automatically like Eclipse does.
Couldn't find relevant info in the docs and relevant functionality in plugins.

I faced a similar issue, coming from Eclipse/IDEA background, you can find it difficult to not have a feature in your java IDE to create a new classes, packages etc.
You can use the below VSCode extension : https://github.com/jiangdequan/vscode-java-saber
It is a very handy extension.It provides support/wizard for:
New: Java files(annotation/class/interface/enum/package/JSP/HTML)
Generate Getters and Setters
Copy Qualified Name
Sort Project By Name
Run Maven Goals
Generate Docs
You can try this extension.Search for vscode-java-saber in the extension search and install it.

Integrating a Java Class into a PyDev Project (Jython) in Eclipse

I have a Java class that i would like to import into my Jython script. Unfortunately, eclipse won't let me create a Java class inside my Jython project.In the window, where you create and name your Java class, I get a message at the top (alongside a red cross) saying, "Source folder is not a Java project" when I type the name of the would be class. How do I rectify this? I need the Java Class to call C code using the JNI (declaring the native method,loading and then calling it). Thank You !!!!!!!

What you can do is to create second module which would be java project. Anyhow, logically it should be that way. Please check out other similar question - PyDev: Jython modules & Java classes in the same project.
Other links that might help - http://pydev.org/manual_101_project_conf2.html

So what nefo_x suggested is correct. You need to create a new Java project that will contain your Java class. Then import the Java package as you would a python module. But there are a few things to watch out for in eclipse to make it work. I list the whole process below:
Your Java class (or classes) should not be in the default package. You need to create a new package and make/put your java class files there.
Export the package as a jar file to some place on your computer.
Add the jar file (located at some place on your computer) to your python path.
Import the package by writing "import PackageName".
The problem for me was that I had my java class in the default package. That does not work due to some naming issues. Anyhow, hope that this helps.

Do I always have to type package name in Java?

Today I started learning Java.
I saw that package automatic gets included in .Java file.
I was wondering if it always need to be included?

Consider specify a common package for all the types within a same project.
In Java is common to start a project with a specific package setting. A package creates a namespace to disambiguate the types that it includes, to play nicelly with other projects that may or may not be in the same classpath. Normally, the package is bound to a URL of the project.
Think of Java packages like C++ namespaces.
A huge project/product written in Java can depend on lots and lots of projects, each described in a different package.
Organizations like Apache have lots of projects, organized under a common package pattern: org.apache.<<name_of_the_project>>.
Consider starting your project with a package named: com.user3552670; or something like your personal site, so persons that will consume your project can relate to the creator.

Yes and no.
It's used to specify the package of the class, read more here.
You could create a class without a package, but your code will look bad..
They exists to avoid conflicts, example between your code and default java package.
If packages doesn't exists, you can't create a class named ArrayList because already exists in Java.
Some IDEs force the fact that, if your .java file is in com/a/b/c folder his package should be com/a/b/c (If i don't remember wrong, IntellIJ IDEA do that)

Yes and no.
It must be there, but the IDE takes care of it (I don't use Netbeans, but I'd bet that it can do it, too). When moving files between packages, it has to be updated, but again, the IDE does it all.

Jars with default package

I found this question -> Import custom libraries in Java
And #Andy Thomas-Cramer said that the classes in "stdlib.jar" from "An introduction to programming in Java" have no packages, so they are in the default package.
Isn't this a bad practice? If you have something with no package the IDEs' auto-completion is quite slower. And also this means that we could not use any of the classes, in that jar, from classes with packages different then the default?
Can someone please tell me how we could deal with this?
EDIT:
I have 2 jars and I put them in Referenced libraries, they both have a bunch of classes in default package. When I create class in different package then the default - lets say org.myquestion I can't access the classes from the jars anymore.
This is something that really bugs me... First I can't create my own package and use anything from the jars. Second my IDE's (I use eclipse) auto-complete goes terrible - I guess it searches to meany classes at once... What I want to do is to put somehow the jars in some namespace... and to be able to access them like org.someones.libs.SomeClass

It certainly is bad practice to use the default package. A package groups classes and provides them with access protection (protected, package private) and functions as a unique namespace.
You can always use classes from every package, them being default or not, you can always mix.

Download the jar source code, And built it to jar by yourself and added the package name whatever your like.That's will solve your problem.
Importing classes inside JAR files that are in the default package

I ran into the exactly same problem as you did. The problem is the jar file "stdln.jar" has no named package, say, only with default package.
You cannot import a class from a default package, basically, since the import operation needs the package name:
import packagename.*;
So there are only two way to fix this problem:
the easier one: Do not create a package in your src folder and use default package two! Every class in stdln.jar would be imported to your src automatically.
Like this:
enter image description here
try to create your own jar file with a named package and copy all the class file into your newly-created jar file.
Since the stdln.jar is only used for education, so which you are gonna choose does not really matter. In real development, we never use default named package since it's not really a good practice, always leading to some confusing stuff.
Hope this would help you!

Do Eclipse's Refactoring Tools Violate The Java Language Specification?

In Eclipse 3.5, say I have a package structure like this:
tom.package1
tom.package1.packageA
tom.package1.packageB
if I right click on an the tom.package1 package and go to Refactor->Rename, an option "Rename subpackages" appears as a checkbox. If I select it, and then rename tom.package1 to tom.red my package structure ends up like this:
tom.red
tom.red.packageA
tom.red.packageB
Yet I hear that Java's packages are not hierarchical. The Java Tutorials back that up (see the section on Apparent Hierarchies of Packages). It certainly seems like Eclipse is treating packages as hierarchical in this case.
I was curious why access specifiers couldn't allow/restrict access to "sub-packages" in a previous question because I KNEW I had seen "sub-packages" referenced somewhere before.
So are Eclipse's refactoring tools intentionally misleading impressionable young minds by furthering the "sub-package" myth? Or am I misinterpreting something here?

Eclipse can't possibly violate the JLS in this case, because it has nothing to do with compiling or running Java source or bytecode.
The refactoring tools behave as they do because that behaviour is useful to developers. The behaviour is useful to developers because, for many intents and purposes, we do treat packages as hierarchal (a.b.c has some kind of relationship with a.b, even if that relationship is not consistent from project to project). That doesn't mean Java treats them as hierarchal intrinsically.
One example where people treat packages as very hierarchal is in configuring a logging framework such as log4j. Again, it's not intrinsic to log4j, but that's how people use it in practice.

Java packages are not hierarchical in the sense that importing everything from package A does not import everything from package A.B.
However, Java packages do correspond directly to the directory structure on the file system, and directories are hierarchical. So Eclipse is doing the correct thing - it is renaming the directory, which automatically changes the name of the parent directory of the renamed directory's children (to state the very obvious).

even java itself has the concept of subpackage:
http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/java.html
java -ea[:<package name>"..." | :<class name> ]
Enable assertions. Assertions are disabled by default.
With no arguments, enableassertions or -ea enables assertions. With one argument ending in "...", the switch enables assertions in the specified package and any subpackages. If the argument is simply "...", the switch enables assertions in the unnamed package in the current working directory. With one argument not ending in "...", the switch enables assertions in the specified class.
If a single command line contains multiple instances of these switches, they are processed in order before loading any classes. So, for example, to run a program with assertions enabled only in package com.wombat.fruitbat (and any subpackages), the following command could be used:
java -ea:com.wombat.fruitbat... <Main Class>

Java's packages are not hierarchical, but Eclipse stores packages on your system's file structure.
tom.package1.packageA is represented on a Windows file system as tom/package1/packageA.
When you ask Eclipse to refactor a package name, you're asking Eclipse to change the name of the file system directory structure.
You can have packages in Eclipse like:
tom.package1.packageA
tom.package2.packageB
tom.package3.packageC
You'll just have different 2nd level file system directories.