"Module" functionality in Java?

Question

In Vb.net, we have something called a "Module" that provides a global scope whereby static functions in the module is visible throughout the entire project.

Is there such a functionality in Java ? (i.e. adding static methods that are available to multiple packages/files/classes without having the need to import .* )

_{Ok I am aware this is a functionality that would cause alot of debate, but really the point of this thread is not to debate about this functionality.}

There is no such thing. Java IDEs will add imports automatically and hide/fold them in the editor, so we don't mind them :-) — Peter Štibraný, Oct 18 '11 at 13:06
Well, you don't have to import the java.lang package (String is including in this package, you never have to import String) ... but I don't know of any way to create a new "Module" that can be used without imports. — Asaf, Oct 18 '11 at 13:09
@Pacerier You can't, it's part of java. And if you could find a way to hack into it, I would highly recommend against it. You'll run into tons of problems when you actually deploy the application. Plus it should be clarified that none of the methods inside String or any other class inside java.lang can be accessed without referring to String, like String.replace. You can't just go replace() any time you want. All its doing is importing java.lang.* automatically. — Asaf, Oct 18 '11 at 13:50
IMHO, this question would be more useful if it mentioned what makes VB modules especially convenient (at the risk of name conflicts): importing a VB module makes it possible to refer to public functions WITHOUT prepending a class name. So it isn't merely that these functions are visible (public), they are effectively in the global name space (once they are imported). — ToolmakerSteve, Sep 06 '14 at 18:08

score 2 · Accepted Answer · answered Oct 18 '11 at 13:14

2

To answer literally, no, there's no real "global" in Java. But you don't need to import, particularly not import .*.

The code below illustrates that an import is not required but it's only really part of the answer.

package org.example.pkg.foo;
public class Foo {
    public static void doSomething();
}

package org.example.pkg.bar;
public class Bar {
    public void bar() {
        org.example.pkg.foo.Foo.doSomething();
    }
}

In Java, types, such as classes and interfaces, are defined in terms of the ClassLoader which loaded them. You can have multiple class loaders, which implies that multiple copies of the same class can be loaded. The obvious extension of this is that multiple classes with the same qualified name (package + class) can be loaded, and there's no inherent requirement that they are related.

OSGi is an example of this, where each bundle has it's own class loader, and as a result you can have multiple versions of the same class loaded at the same time.

How does this relate to the question? Well, without accurately identifying the class you want to reference it's not possible to accurately identify the method or member you want to reference. The import, or FQN referencing does that.

answered Oct 18 '11 at 13:14

ptomli

11,730
4
40
68

globals *can* be useful at times, dang. – Pacerier Oct 18 '11 at 13:36
btw I was wondering how do we write a class and place it within the java.lang package? – Pacerier Oct 18 '11 at 13:37
You really don't want to go about trying to add code into java.lang, or even java.* or javax.*. It might be possible on some runtimes, but it's such a no-no that Eclipse ignores user created classes in java.lang. – ptomli Oct 18 '11 at 13:44
Ok I understand but I mean are you aware if the specifications have anything to say on this matter? – Pacerier Oct 18 '11 at 13:49
I can't actually find anything in JLS, but there is another question on SO that mentions restrictions; http://stackoverflow.com/questions/727844/javax-vs-java-package/727852#727852 – ptomli Oct 18 '11 at 13:58

score 1 · Answer 2 · answered Oct 18 '11 at 13:06

1

No, don't think so. Static imports can make it a bit less painful/verbose to use such methods, but it's generally advised to be careful with them.

answered Oct 18 '11 at 13:06

G_H

11,739
3
38
82

score 1 · Answer 3 · answered Oct 18 '11 at 13:06

1

Not without the import. You can declare public static methods that are accessible from anywhere in the project, but you still have to either import the class or use fully qualified class path when you use it.

answered Oct 18 '11 at 13:06

John B

32,493
6
77
98

score 1 · Answer 4 · answered Oct 18 '11 at 13:12

1

public methods are visible throughout the project

however if you want to dispense with the imports you can make the path explicit

my.package.UtilClass.methodIWannaCall(someArg);

answered Oct 18 '11 at 13:12

ratchet freak

47,288
5
68
106

score 1 · Answer 5 · answered Oct 18 '11 at 13:17

1

No. Import is needed for any static method to be visible.(which is a good thing).

As others mentioned, Java IDEs do this job for us.

answered Oct 18 '11 at 13:17

java_mouse

2,069
4
21
30

"Module" functionality in Java?

5 Answers5