How to learn Java programming

Oct 22, 2019
How to learn Java programming
  • How to learn Java programming



    This thread was stickied here: However in writing this, I sort of ran into the character limit and now have moved it here.

    Learning Java - How do I do it and how do I do it quickly?

    Short answer:

    You can't. Simple as you really can't do it in a time frame that can be considered quick. If you already know a different programming language, like C++ and in an in-depth manner, then yea 1-2 months seems reasonable for being Java competent. However, in regards to someone learning to program from the start, you're aiming at 1-10 years depending on the competency you want. Obviously, nearing the 10-year mark in a single language would mean you should know literally everything about that language, however, 2-5 is what I have found to be a good place to start attempting to code spigot plugins.

    Longer, more detailed answer coupled with resources:
    There are a variety of places to learn how to program in Java. One of the best places to learn is here: This is in my opinion, however, those tutorials are made by Oracle. They go in depth and they are accurate.

    Other notable places to learn Java/Programming:
    I have a bug, where can I ask someone for help?
    Other links:

    In general, as stated above it does take quite a bit of time. There are a couple of things that you should do throughout your Java career.
    1. Ensure that you are following best practices from the beginning. Don't name your variables stupid crap like Pizza, or whatever. If you have a variable is a person's age, name it age!
    2. Try to really, really understand your code. Initially, you will only have a vague idea, and if you follow the right tutorials, they will tell you what to ignore in the short term. Later on, those vague details will become clear.
    3. Talk to people about it! Seriously, no one learns to code by themselves, or rather, very few people do. Others with more experience will absolutely be able to offer insight if they have any manners and the time to do so. That being said, make sure you try to fix the problem yourself first, and try to isolate the code that is causing the issue.
    4. It is okay to be stuck and not know exactly what path you need to follow in order to obtain your solution but this is where methodology like pseudocode and the like comes in handy. The code doesn't just magic onto the screen. You really need to think about what you are doing, the reason why "pseudocode" is so handy is because you can take an English reading of what the program should do and then try to do exactly that, step by step.
    5. Learn to use as soon as you can:
      1. The debugger. Seriously. I am a programmer, I have a debugger, without it, I am useless. Period. You need to know how to use the debugger, add watches to variables.
      2. Read a stack trace. This is one of the most important things on the planet when it comes to programming. There is a good explanation here for this:
      3. Write code that works for more than one use case. It's fine to write something that will work for the one thing that you want it to, however, why not make it work for a bunch of other use cases as well?
      4. Unit tests. These are a later addition to your toolkit, however, they are still quite useful in moderated amounts. Some will argue that Unit tests are very important whereas others, not so much. It's honestly up to you, still quite useful, though.
    6. Programming is NOT easy under any circumstances. Those of you who can program will know that there were certain times during your programming career that you ran into serious trouble and were stuck on a particular bug for hours, days, and for the professionals among us, possibly even weeks. This being said. You will only learn if you keep going back to it. Your brain is literally a muscle, use it or lose it.
    7. Document your code properly. This is very important. If you write a program from start to finish in a week, you should be able to come back to it 6 months later and completely understand what is going on.

    What IDE should I use?
    This is a pretty controversial topic. Everyone will argue "use this, it's better, you are bad if you..."...yea that really doesn't swing in a professional environment. Use the tools that you are comfortable with. If you like NetBeans, use NetBeans. Hell if you like using notepad and cmd, be my guest if that's what works for you! However! It should be noted that features like syntax highlight and the like really make it a lot easier on you, so investing time into downloading and learning how to use an IDE is pretty important.

    Notable IDE's for Java programming
    Try them out one by one, most people use Eclipse based on my sample space. A lot of people on Spigot will argue use Intellij because it's somehow magically better. I mean, fair enough if you like it, but really there are a lot of reasons someone else may want to use Eclipse or maybe personal preference? They're entitled to an opinion, right? If you really want to know my personal favorite IDE, I don't have one. I use them all fairly comfortably. I probably use Eclipse the most, since that's what my University uses.

    General tips
    • Do yourself a HUUUUGGE favor and just forget about other people's opinions for a little while when you first start programming. A lot of people within the developer community (not just Spigot, developers as a whole) tend to have a personal bias one way or the other. Drown those people out. Pick something small and build it. Make something. I mean, then you've made something right, it works, right? So then, post it online, have others tear it apart. See what their criticisms are. If you find that have the worst, most inefficient code ever, that's okay! At least you are learning, research why the way you wrote that program was bad and learn from that. No one writes beautiful, elegant code at first. It takes a long time before you start doing that.
    • Code a lot. The more you code the more the information will stick.
    • Learn another programming language or two, maybe a functional one to burn your brain a little bit. It is good to be stuck, this way you learn to try new things.
    • Learn to use Google. Seriously, good Google search skills are very important, not as important as being able to program, but it's nice to be able to find stuff online quickly. Everything you need to know is already online for the most part. If it's not, post a question on StackOverflow.
    • Read other peoples' code. This is quite important, reading the code of others is really useful, you can learn a lot from someone better than you. If you have someone better than you at programming or with more experience, possibly, try to get them to write the same program as you blind. This way, you can compare what they did versus what you did. Paired programming is also a really useful exercise, but you need a partner of a similar skill level or higher for you to learn anything.
    • It is probably going to be pretty useful to know how to use some kind of source control manager. SCM is a software that you can use to interact with code repositories, at least that's how it works for the likes of git. You are able to see a "change history" and honestly it is an extremely useful tool. Being able to look back and see why you made a change is very, very important. Github and bitbucket are popular websites for hosting your repositories, ensuring that you don't lose your code or commit history. There are other SCMs out there, like mercurial. (Correction added, credit: @mattrick)
    • If you learn better visually, it might be a good idea to attend a class or possibly watch some youtube videos. This guy is someone who, for the very few tutorials of his that I have watched, has appeared to be quite competent and he does follow best practices:

    Question: Should I skip learning Java and instead learn spigot programming?
    Answer: The equivalence here is literally like asking a one-year-old child can you fly a fighter Jet before they can even walk. Spigot programming incorporates a LOT of stuff from the Java programming language, as well as it's own unique API built for interacting with the Minecraft server. Do you want to know why this is the case? Because it's wrote with Java. Spigot is built with Java. Can I read the Harry Potter book before I can even speak English? Can I drive an F1 car before I can even walk? Am I able to swim across the Atlantic with the use of my arms or legs? Same difference. The answer is no, and if you do it any way you are going to end up badly. Get a good start to programming and do it the right way from the start. How many times have you been in class learning a subject and you didn't pay attention for the first lesson or two or three or more. Then a week or two later you wake up, realizing that you actually *need* to know and understand the material. You listen to what your professor or teacher is saying and it sounds like absolute nonsense. The board is covered with hieroglyphics the page you are on in your textbook makes no sense; mentioning concepts as if they are as natural as light day that you have never heard of before. Guess what. That's the same thing, if you attempt to write Spigot plugins prior to learning how Java and programming in general works, you aren't just diving in at the deep end, you are making a huge mistake.

    This means that you simply will not know anything about what is going on if you don't know standard Java. It's possible, sure, but plugins that are written by those of us who really don't know Java programming are likely to:

    • Not work as intended.
    • Break quickly.
    • Be inefficient or slow.
    • Inability to work for every use case.
    • Have undesired side effects(IE server crashes, bugs).
    • Be unreadable, and prevent further usage of code later on.
    • Possibly, depending on the plugin, have security flaws.
    • Probably end up being extraneously simple in terms of functionality, because you really don't have the know how to do anything complex.
    • Produce memory leaks.
    • Aversion of best practices.
    • Possibly even break other plugins. I haven't seen this yet myself but it is for sure possible to write a plugin that can do that, doing it by mistake is quite hard but still, possible if you don't know what you are doing.
    It could be argued that if you wanted to do one, tiny specific task that you could just skip ahead and just write that bit of code. That might work, but even then it'd probably save you a lot of headache just to pay a developer who actually knows what they are doing 10 bucks to do it for you.

    I hope that this has helped provide a little bit of insight for those of you here who do not know where to look. To those of you with programming skills, please feel free to correct me on any point. I will 100% own up to any mistake that I have made and correct it whilst crediting anyone who corrects me. If you feel I have missed something, make a comment below and I will happily append it to this post. If you spot any typos or the like, please feel free to point those out too! Thank you for your reading. If you have any questions regarding any of the resources I have linked or about programming in general, post below.


    So, since there have been a few topics floating around this forum lately regarding "how to learn" this that and the other regarding java programming, I will be adding some stuff here to help people understand a few concepts, particularly how to write clean code(There was a topic on that this week which I briefly touched on) and how to progress properly as a developer.

    Tips for "Clean" code.
    Note: This is not explicitly Java only. This sort of stuff goes for any language. If you want to be a very good developer in any language, these tips hold true.

    So, something that should be important to any developer is how "clean" your code is. This is because a lot of the time in the industry, you will be working on code that you may not have written from the ground up. You might not even be the 2nd, 3rd or 4th or even in some special cases, the 50th and beyond person to work on that bit of code. This means that you need to write code that is easily understandable.

    Now, a big, big, big part of that is designing your application correctly. Use the correct data structures, have a logical flow and make your code follow the single responsibility principle. That, that right there takes time and effort to be able to do. You will write some code once, you other pieces again and again and again. Learning what makes code truly reusable and clear to anyone who wants to use it takes years. However, that being said, here are some nice tips that you can use to improve your "style" that will start helping you right away. Pick one of these topics and implement it into your work flow and I guarantee you, you will be a better developer because of it, so here you go:

    1. Follow the "DRY" principle. Don't repeat yourself.'t_repeat_yourself You can read more about it there. How does one follow the dry principle? Let me give you an example:

      Code (Java):
      public static void testing(int amount)
              int total = 0;
              for(int i = 0; i < amount; i++)
                  total += 5;
              System.out.println("Total: " + total);

              for(int i = 0; i < amount; i++)
                  total += 5;

              System.out.println("Total is now: " + total);
      See how that loop appears twice? What might be nicer is have a method that takes in the amount and then work with that instead. Something that is very important for keeping true to the DRY principle is generic types, found here:

      A lot of the time I see people write stuff that can very easily be templated. If you use generics, you will reduce how much code you write, period.
    2. To cling to what I said last - Write less code. Now, this can be taken the wrong way, but hear me out. Firstly, less lines of code means less errors (source: - This is just the first article I plucked off the net, this should be common sense, and there is a lot of writing on this topic).

      Now, that seems pretty obvious, right? Less code, less errors? What I am getting is be expressive. Try to write what you mean. That means avoid boilerplate where possible ( That means that the correct design from the ground up is critical. That means take a step back and scribble on some paper as to how your program should work. When you're done, go back and look at that paper. The design worked out different? How? This will teach you how to be expressive in programming, or should at least help you to do so a little. Note that being expressive is quite different to having good design down. However, having a good design is often times an enabler for allowing you to be quite expressive.

      You keep talking about being "expressive" and I still don't know what you mean...
      Example of code that isn't really expressive:

      Code (Java):
      Counter example which is more or less expressive:
      Code (Java):
      Now, this really isn't the best example but hopefully you get the idea. In the first example, there is a lot of "gets" of things that don't really make sense. The second example however, reads pretty much like english; get the config and enable swearing, where as I have no idea what the first instance is trying to accomplish at first glance.

      Another way to write very "expressive" code is to use the functional paradigm to your advantage. That can be done quite nicely in a fully functional language, like Haskell. However, Java 8 offers some functional features, which you can learn how to use here:
    3. Moving on, something else that is very important is a uniform style in your code. Here are some tips for that:

      • Focus on what the language that you are writing in uses. If you are writing code in a language that uses new line braces, use new line braces. If it uses camelcase, use camelcase. The trick is be consistent when it comes to pedantic things like underscores vs camelcase. Getting used to the other there is very easy and breaking form and doing "your own thing" reveals how new you are to development. If it really bothers you, write a git hook and when you commit to anything public the git hook will fix your formatting issues for you.

      • USE THE FREAKING ENTER KEY This is something I cannot stress enough. I do not want to see a big block of wharble-gharble. If you do a bunch of things in a row that are slightly different, try grouping the bits that are related together.

        Good example:
        Code (Java):
        public static void printX()
                int x;
                x = 15;
                System.out.println("X has been printed.");
        See how everything is grouped together with new lines? The little bit at the top for stuff relating to x, the stuff in the middle for printing by itself and then the return at the end by itself for clean up (Note: whether or not you return out of a void method is something that I really don't care to discuss here, so leave it out, I am not interested in that pedant topic).

        Now, here is a bad example:
        Code (Java):
        public static void printX()
                int x;
                x = 15;
                System.out.println("new x" + x);
                x--; x--; x--; x--; x++;
                System.out.println("new new x");
                System.out.println("X has been printed.");
        Now, I added some extra lines for affect, however you get what I mean. This code is complete trash and it makes no sense. It has no sense of order and even if it did, I'd have a very hard time telling you what the hell that is because it's all smushed together. Use. The. Enter. Key. Okay?

      • Don't over document stuff. Don't under document stuff. There is a balance. Don't document getters and setters, don't write a comment saying "//start if" and then a trailing one that says "//end if". These are an eyesore. Write documentation that documents what is complex in your program. If something seems a little abstract, document it. Document method params, document what it returns and document when it may throw a particular exception. In general, read this and you'll be fine:

        Another good tip for nice documentation, if something is very complex, write sample inputs and expected outputs. This way, you can literally show someone how to use your code.

      • Refactor. Often. If you originally write a method called "banMember(String reason)" and then later alter the method so that it kicks someone, change the method name, dammit. Sure, it works the way you want it to, but it does not make any sense as to why it does something other than what it's called. Method names should be self-documenting. Live by that.
    4. Another big tip for extensible code: Try to make it so that your code is split up so that you can re-use as much of it as possible. That means, again, having a good design from the ground up is quite important.
    More to come

  • Loading...
  • Loading...