How to have more than 1 class?

Discussion in 'Programming' started by ImCenZ, May 3, 2017.

  1. Hey!

    First of all i wanna say that im only starting with java Xd

    Im practicing making a UHCExtras plugin, but i want to have my code more organizated so i want to create a different class for each feature, but i dont know how to call the other classes from the main so the plugin recognize the commands.

    Thanks you :p
  2. I'd highly recommend learning the basics of Java and OOP first.
    • Agree Agree x 3
    • Optimistic Optimistic x 1
  3. Learn java.

    Dont say you know java, because this thread is proof you know nothing about java except how to copy and paste code and hope it works. Check out some of the links in my sig, or get a good book like this, it covers everything you need to know to make any sort of normal java application

    Trying to make plugins without knowing what you are doing will just waste time and produce (at worst) nothing, or (with luck and several years) a pile of useless garbage.
    • Agree Agree x 1
    • Optimistic Optimistic x 1
  4. askjdnkm I love this community Xd
    • Agree Agree x 1
    • Friendly Friendly x 1
  5. Gaxan


    I'm no Java expert, but I used to program in C#.
    I picked up this book,aps,182&crid=FQ9NLNPPPJXJ
    Most of it wasn't of much use to me since C# and Java syntax is similar, but for someone just starting out. It's a good book to start with and it's not very expensive. You won't actually learn Java in a day, but it will teach you about the basics. The book also teaches you the basics of using Netbeans as well.
    #5 Gaxan, May 4, 2017
    Last edited: May 4, 2017
    • Agree Agree x 1
  6. Then show him where he does that? I'll post the link you failed to send - here it is.

    In short, create a new class in your IDE (may be at "File > New Class...") and put code into it. If all you want to do is move utility functions over there (eg. chat utilities, such as sending a message with a blue color to a player), you may just use static methods in the new class as seen below, but be careful; when doing actual object-oriented programming in a class with "new", Objects etc. (as explained in the link above), you should never use static.

    Code (Java):
    public class ChatUtils {
        // The following three lines set the so-called "constructor" to private. This means that if you somehow accidentally use the class in an object-oriented context as explained above, your IDE will show an error instead. Utility classes like this should never have a non-private constructor!
        private ChatUtils() {
            throw new RuntimeException();

        public static void sendBlueMessage(Player player, String msg) {
            player.sendMessage(ChatColor.BLUE + msg);
    Then, to send blue messages in your main class:

    Code (Java):
    ChatUtils.sendBlueMessage(player, "Hey, what's up?");
    #6 StillNoNumber, May 4, 2017
    Last edited: May 4, 2017
    • Like Like x 1
  7. I shouldn't have to, he's fully capable of using Google. If he wants to learn about something he can do the research himself instead of being lazy.

    @ImCenZ , since @StillNoNumber believes you're incapable of using Google, here is a quick guide that I made for you! Be sure to browse the internet responsibly.
    • Agree Agree x 2
    • Optimistic Optimistic x 2
    • Funny Funny x 1
  8. Gaxan


    I'm sorry, the tutorial you posted required too much of my time, can u give links for google results plix plox?

    just kidding.
  9. The exception is pretty useless if you ask me. Isnt important for java newbies
  10. Yeah probably, but maybe it's good practice to already start doing it early.

    In case someone wonders what it does:
    Code (Java):
    private ChatUtils() {
        throw new RuntimeException();
    private ChatUtils(){} will make sure the class can't be instantiated from the outside (by setting the constructor to private). However, it can still be created in its own class file using the new keyword, and there's also a work-around using Reflection. This is why we add throw new RuntimeException();. This line will do nothing but throw an error when ran - which might sound useless, but the developer will notice that he did something he isn't supposed to do. (A much rarer benefit of the line is that if you sub-class a class that does not have a nullary constructor, the code will still compile just fine. Question remains why one would potentially want to do that though, but let's aim for perfection anyways)
    #10 StillNoNumber, May 4, 2017
    Last edited: May 4, 2017
  11. All you're accomplishing is confusing somebody that's just trying to learn the basics.
    • Agree Agree x 1
  12. IMO it is bad/useless practice anywhere. If someone uses reflection to bypass the private constructor, they have a damn good reason for doing it and you should just let them do it, because they know what they want better than you do.

    There are definitely exceptions (mostly related to security - and there are still ways to bypass the exception), but a minecraft plugin (and 99% of other code) is not one of them.

    Dont add bloat that serves no purpose, or just to handle a weird situation that will never happen by accident and only serves to cause frustration for someone else trying to use the code in an unintended way.
    I am sure anyone who has used NMS understands what i mean.
    • Winner Winner x 1
  13. At last! An intelligent reply to this thread!
    • Funny Funny x 1
  14. I get your point, but I still believe it is a lot better to build a perfectly clean API where literally nothing can happen on accident. There's no reason why one would want to instantiate a utility class with Reflection. By that logic, one could just as well make every single field and method public, and just expect the end user to know what he's going to do. One of my main concerns with using Reflection to do such things is that it isn't a fix to anything, instead just a workaround for bad APIs.
  15. "There's no reason why one would want to instantiate a utility class with Reflection."

    Which is why you do not need to add bloat just to prevent a harmless situation that will probably never happen.
  16. Didn't say it wouldn't happen - just saying it shouldn't. Besides, there's literally no downside to it (can't bring the "uuh wasting disk space" argument).

    But it's the same old discussion again, is perfectly clean code better than not-quite-perfectly clean code that does the same thing? I'd always say yes for reasons of forward-compatibility, but if you don't, that's up to you.
    • Creative Creative x 1
  17. If you're referring to your snippet as the "perfectly clean code", then I beg to differ.
  18. For the sake of satisfying your 'bloated code' argument, you can simply make the class a constant less enum, this would protect it from both reflection and serialization attacks. This would definitely mean you have a class, with exactly zero instances at all times.
  19. Where would you improve it? I'm always open for suggestions.
  20. Many thanks for all your links to java tutorials that have nothing to do with what I asked.
    To all this, I solved the problem using a CommadExecutor class.

    Some people are very toxic here Xd