14

Coming from a C++ environment I got used to splitting up many of the functions that I needed into an funcs.h file and then do #include "funcs.h" and then adding the functions prototypes into the main .cpp file.

Now I am starting to work with Java (mainly with Minecraft ModloeaderMp), and I already made a funcs.java file where there are some premade functions (e.g., some functions for file copying, giving stacks of items, etc.). Since I am already using the statement Public class mod_mine extends BaseModMp, is there a way I can import the functions or do I can I just do another Public class mod_mine extends funcs?

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
MrJackV
  • 547
  • 3
  • 5
  • 12
  • 4
    C++ knowledge doesn't directly transfer to Java even though they are similar. There really are many pitfalls and many things that are done differently. There are a large number of tutorials aimed specifically at people who are used to C++ however, try googling `java for c++ programmers`. – Vala Oct 12 '11 at 09:25
  • All the answers are lacking examples. – Peter Mortensen Nov 18 '22 at 00:14
  • [Related question](https://stackoverflow.com/questions/1417291/no-simple-way-to-include-in-java) (from 2009). And [from 2012](https://stackoverflow.com/questions/10025239/include-include-equivalent-in-java). – Peter Mortensen Nov 18 '22 at 00:17
  • Related: *[How does Java import work?](https://stackoverflow.com/questions/12620369/how-does-java-import-work)* – Peter Mortensen Nov 18 '22 at 00:37

7 Answers7

25

You don't #include in Java; you import package.Class. Since Java 6 (or was it 5?), you can also import static package.Class.staticMethodOfClass, which would achieve some forms of what you're trying to do.

Also, as @duffymo noted, import only saves you from systematically prefixing the imported class names with the package name, or the imported static method names with the package and class name. The actual #include semantics doesn't exist in Java - at all.

That said, having a "funcs.java" file seems to me like you are starting to dip your toes into some anti-patterns... And you should stay away from these.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Romain
  • 12,679
  • 3
  • 41
  • 54
  • Nitpick: it's `import static package.Class.staticMethodOfClass`, if you leave out the static it won't build. – Vala Oct 12 '11 at 09:23
  • 4
    import is not at all the same thing as a #include in C++. All the import does is let you type Baz instead of foo.bar.Baz. It's a keystroke saving device, nothing more. – duffymo Oct 12 '11 at 09:28
  • @duffymo I don't imply it's the same as an include, I probably should have made it clear-er. My core point here was the static import, which appears to be what the OP looks for - somehow. – Romain Oct 12 '11 at 09:29
  • Yes, you should. I read it to say that it's exactly equivalent. Don't worry about what the OP is looking for; make sure the answers are correct. – duffymo Oct 12 '11 at 09:30
  • @duffymo Have added a paragraph specifically about this. – Romain Oct 12 '11 at 09:31
  • @duffymo I certainly didn't read it as "exactly equivalent". It sounds like you're assuming quite a bit from very little text. More like that was his only alternative because there *isn't* an exact equivalent. – Vala Oct 12 '11 at 09:34
  • @Thor84no I believe duffymo downvoted because it was indirectly implying `import` was semantically equivalent to `#include`, which is wrong. Now that it's fixed he should remove the downvote. – Romain Oct 12 '11 at 09:34
  • Done. Your answer changed quite a lot from the first reading. – duffymo Oct 12 '11 at 09:45
  • @Romain Yeah his comment wasn't on here as I was typing that. – Vala Oct 12 '11 at 09:46
9

There's no #include in Java.

I would not like a design that had a funcs.java that stored all the variables. Objects are state and behavior encapsulated into a single component. You aren't designing in an object-oriented way if you do that.

Good names matter. A class named Stuff that extends Stuff2 had better just be a poor example.

That's not good Java. I wouldn't consider it to be good C++, either.

duffymo
  • 305,152
  • 44
  • 369
  • 561
  • Ok, funcs.java just contains FUNCTIONS that I use frequently, not variables. Stuff and Stuff2 are just dummy examples. What I meant is that I am doing already a class extend, so I was wondering if I could do it again. – MrJackV Oct 12 '11 at 09:23
  • If code is common between *similar* Classes it makes sense to make a base Class and placing the methods there. That doesn't mean you should make a library of whatever useful generic methods you may have in a single Class and always extend that. You can extend a Class as many times as you like and you can extend an extended Class, but you can't extend more than a single Class (only interfaces, which you `implement` rather than `extend`). – Vala Oct 12 '11 at 09:30
  • Java only supports single inheritance of implementation, but you can implement as many interfaces as you'd like. I don't know what "could do it again" means. Sounds like you need to read a lot of basic Java. – duffymo Oct 12 '11 at 09:32
3

It sounds like you're putting all your methods in the same class. You should separate them:

Utility classes

These should contain static methods that do things like get the contents of a file, show a dialog screen, or add two numbers together. They don't really belong in an object class, they don't require instances, and they're used widely throughout the program. See java.lang.Math for a good example of this.

Constant class or configuration files

This can be a Constants class that contains static final members, like PI = 3.1415. You can access them using Constants.PI.

Or, you can use configuration files and load them into Configuration and access the configuration variables with something like config.get("database").

Other

If your code doesn't fit into any of these, you will want to put it into some class such that your code fits object-oriented programming concepts. From your question, it sounds like you'll want to read up on this. I would first read Head First Java, then maybe some other books on object-oriented programming in Java. After that, I'd look at some design patterns.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
skyuzo
  • 1,140
  • 7
  • 13
3

Java is an object-oriented programming language, and there is a reason for it.

There isn't any #include in Java, although you can import classes from other packages. Making separate class, func.java, to store variables might not be a good idea, until or unless all of them are constants.

By extending some class, you can reuse the function. But does extending class pass the is a test? If not that, this might be a bad idea.

If moving from C++, going through some good book, for example, Head First Java might help a lot.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Zohaib
  • 7,026
  • 3
  • 26
  • 35
  • 2
    C++ is object-oriented too; this is just bad design in every language. – duffymo Oct 12 '11 at 09:31
  • @dyffymo agreed...just said so because C++ also supports programming without object oriented approach and java does'nt. – Zohaib Oct 12 '11 at 09:35
2

There isn't any #include in Java. You can use the import statement to make classes and interfaces available in your file.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
user496934
  • 3,822
  • 10
  • 45
  • 64
1

You can run the C preprocessor on a Java file, ensuring you use the -P flag to disable line annotations. A quick Google search confirms that this has been attempted at least twice, and is even used in the popular fastutil library:

This works for all directives (#include, #define, #ifdef, and so forth) and is both syntactically and semantically identical to the equivalent statements in C/C++.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Adam P. Goucher
  • 259
  • 2
  • 13
0

Actually... There is a way to have the same semantics as in C's #include (the keyword was later borrowed by C++ for the sake of looking fancy...). It's just not defined with the same words, but it does exactly what you are looking for.

First, let's see what you do with #include in C++ to understand the question:

  • include #defines,
  • "forward" function definitions (their "body" being defined elsewhere, in a class implementation, if you remember Turbo Pascal, you get my point),
  • define structures,

and that's pretty much it.

For the structure definitions, there isn't any point. That's old-school C: in C++ you don't define struct {} anymore for ages; you define class structures with properties and accessor methods. It's the same in Java: no typedef struct {} here either.

For this, you have the "interface" declaration (see Interfaces (The Java™ Tutorials > Learning the Java Language > Interfaces and Inheritance)):

It does exactly what you're looking for:

    public interface MyDefines {
        final CHAR_SPACE : ' ';               // ugly #define
        int detectSpace(FileInputStream fis); // function declaration
        // and so on
    }

Then, to use:

    public class MyClass extends MyAncestor implements MyDefines {
        ...
        // implementation of detectSpace()
        int detectSpace(FileInputStream fis) {
            int ret = 0;
            char Car;
            if((Car = fis.read()) != -1) && (Car == CHAR_SPACE)) ret++;
            ...
        }

Read the link given above; it's full of useful cases.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131