Java Threads: Shared Java Queue 2: Queue Harder

Sorry, couldn't help myself with the title.

Anyway, just a short post today, and that's because our Synchronized Queue object basically already conforms to the Queue objects (or rather the interface). Its methods are monitored forwarding methods. That is, they deal with all the necessary object locking (synchronize), but that's it. Beyond that, they just call the methods of the actual Queue.
TL;DR: It's now up to actual Queues to be doing this right. We've already protected everything with our wrapper class.

Java: MultiThreading Example 2: A Shared Queue

In response to one of the comments: Yes. I was either going to go to html after we were done with making a simple game or 2, or to python. Python really should have been done first, its a much nicer language, but...I didn't! So there.

Back to another Java example, until this whole multithreading thing is understood properly, I looked at the dumbass book again, but I found something that looked plausible: A shared queue. I mentioned this when going over potential difficulties you may encounter without synchronizing, so this seems like a great way to learn how to make something thread-safe. On top of that, there'll be flipping between threads, unlike the clock program!

Early Day Off!

I think I'll take my free day early this week. I need to read ahead before I get on the next example, after all!

Java: Text Clock Complete!

Oh god, the pain. I did far too many squats from a huge period of not doing anything, and to add to it, I didn't stretch properly. My legs are in so much pain right now :( You'll also notice that I changed the layout again! Black background is easier on my eyes, I assume it's not a problem for anyone else, either? Let me know if it is.
And Bersercules! Not to worry, for I am a man of my word, I will at least ATTEMPT to make the Texas Hold 'Em game!

Most of the space in these screenies is going to be taken up by comments, because, honestly, I did not understand half of what I was doing at the time. They were largely for my own benefit, but I assume you could learn from them too! As teachers go, I'm terrible, given how little I know of the subject before attempting to teach :D

Continuing with our text clock for now, though, we've just got the frame to go!

Java: Multithread Clock (Cont)

Pfft, overslept. I am not good with that, and reading DWei's blog on his sleeping troubles made me more acutely aware of my own :-(

Anyway, the problem I was mentioning yesterday was in the region of "I need to make my own JFrame for this to work, but the GUI builder is a pile of dicks, and won't let me customize JFrame code.
Unfortunately, I've not found a way around this, so its probably a good thing I manually did the GUI stuff that one time, right? :D

Java: A Clock Example

Well, I may have mentioned before that the book was a load of shit when it came to threads, after all, and it's completely thrown me off how to proceed! The code we have is essentially useless because of this, but I have been looking into it.

It turns out that having a class use "implements Runnable" instead of extends Thread is the preferable way to do things like this. The class is then not an extension of a thread, but can be run by one!

I've actually completed my clock, but it's not very pretty, and annoying to understand. Here's the file if you want to look at it, though. I'll save the actual code and source for when it's not as confusing a mess as it currently is :D

No Java: Brain Problems!

The day's technically not over! I just kinda...passed out at like 4pm and only just came to, with this page still up, so I have a legit reason to skip today's post :D Before you mention, though, I don't find telling you guys more important than going to the doc's to find out wtf is wrong with me, I'm just waiting on someone who can drive me there safely. And there he is now!

SEE YA TOMORROW MAYBE!

Java: Thread Scheduling & an Example (Part 1)

What's up? We're going to go right into the last bit of technical information before an example program, since those are frankly easier to learn from (for me, at least!).

Thread Scheduling
A program that uses many threads needs to be subject to some set of rules to determine which thread should be running at any one time, and how to switch between threads. Without this switching around (scheduling), there's no real reason to use threads in the first place, since some threads will never have a chance to run.
Because of this, threads are given priority levels (higher priority runs before a lower priority thread).
TL;DR: Needs to be a way to flip between threads, and to prioritize them, otherwise, pointless.

Java: Concurrency with Threads: Using Threads

Yay, I have a cold! Luckily, tomorrow is my day off. There's a lot of tech detail I'm getting through before it comes to the examples, but I paraphrase a lot, so hopefully I can squeeze all (or most) of it in today, meaning at the start of the new week, we can delve into actually playing around with stuff again!

Back to threads, a thread of control is just a single path of execution through a program. So, for all the programs we've looked at and fiddled with, we had 1 thread, which started in the main method, and ended with the program.

Every program has 1 thread when it begins running (the main method), but in this method, we can call further threads, and those can make threads of their own etc. as needed by the application. Normally, you'll want your main thread to do all the real work, with other threads sitting there to monitor incoming connections or whatever.

Java, of course, provides full support for threads which are integrated into the language as well as class libraries.

Java: Concurrency with Threads (Intro)

This is a bit late, and short, as I have unexpected company over :/
Hey, at least its the introductory section, so it's naturally short!

Do date, our only programs have done one thing at a time, which is a little limited. It allows us to actually do pretty cool things, perform calculations etc. But the more interesting programs, such as simple games (and actual important things) would need us to do many things at once. As y'know, we've mentioned.

Java: TEXT EDITOR COMPLETE (sorta)

Woop, well we have everything in place, so the only things left to do are "New" and "Close", put them in a menu bar (along with everything else), and give them shortcuts! After today, we'll start work on Threads, which will allow us, hopefully, to work on some of the simpler games.

An issue I don't feel like working on is when you hit new/close/load, an option to save doesn't come up. Also there's no Save vs. Save As. But that's okay, since I wasn't planning on this replacing Notepad anyway, and its more of a matter of building it than learning anything new.

Here's the new and close methods:

Java: Completing the Text Editor Functionality II

As per the comments a couple days ago: Yes, we absolutely can get to simple games, but to do that, we need to learn about threads! So I'll do that right after this text editor is done! I suppose turn based games require it less, but still.

Okay, let's get to finishing this thing. Since load() was just a version of reading files, it follows that save will be a similar version of saving (durr) them. Keep in mind that our finished project will be very rudimentary, and you'll probably still be better off using notepad and stuff, but its still functional, right?
I changed a line in the code for load, when initializing the JFileChooser. It is identical to the initialized JFileChooser in the following:

Java: Completing the Text Editor Functionality I

Well, we have our text editor, which looks like:

Now, we need to add functionality to the buttons, but we want our methods of save/load etc. to be just that, their own methods, which the buttons call, so first, we need to actually make the methods, and have the action listeners come in later!

Let's go in order, starting with Load. This is some new material, so pay attention: JFileChooser is what we're using. This took me a while to figure out, too, so we`ll only be doing Load today, Save will be easier with this knowledge, so I can probably do the remaining 4 tomorrow!

Java: More GUI Stuff!

So it turns out, in discovering and using the Netbeans GUI creator, I skipped like, a bajillion pages in the textbook, which are all about bringing up buttons and setting up events, and the proper way to put things together (A jFrame being the bottom level, to hold everything, then a jPanel for each section on the Frame and so on.). So uh. I'm kinda out of the GUI chapter, save a couple of examples!

I guess we'll do those (its some relatively cool stuff), until someone in the comments section has a specific request, or we can just move on to multi-threading and such, which will be the final thing to learn about.

Anyway, for now, we can have a simple text editor! Let's start off by designing it, visually.

Java: Core GUI Concepts III - Example Program (The easy-ish way: Functionality)

I feel that I should note this GUI builder isn't part of the textbook. I just looked at the generating of code and thought "Fuck this, there's gotta be a better way!" And then there was! Also, post on Sunday since I had that day-off earlier in the week.

Anyway, now that we have the visuals more or less done, we should work on functionality. First off, we want to get out of the design tab, and move into the code tab, like so:

Java: Core GUI Concepts II - Example Program (The easy-ish way: Visuals)

Okay, I think I got this worked out! Let's have a shitload of screenshots!

Let's start off by making a new file in Netbeans. But instead of the regular Java file, scroll down to the Swing GUI Frame, then select JFrame. This will, predictably, give you a JFrame to work with. Fun times.

Java: Core GUI Concepts I - Example Program

Well, good to know that TL;DR is a hit! Moving on, GUIs themselves are complicated to teach beyond "Here's the libraries, get to it", so we'll start off with an example program! This should hopefully give us an idea of how certain aspects are used and whatnot.

The example we'll be using is just a window with a button. The button will toggle between 2 text messages, "Hello" and "Goodbye". It's surprisingly complex, so I'll only be doing this for example purposes, so you can see how the code works. Tomorrow, I'll be recreating the program the easy way (I hope), so don't fret if this is ridiculous. Here is the end result:

Java: GUI Introduction

Well, the voters have spoken! GUIs first it is. Which is good, I didn't have much of a stomach for a day of gaming. Ended up going for a "jog". Turns out I'm much less fit than I remember! So I just played Men of War:Vietnam before a whole bunch of TF2 (Which I also suck at).

Feel free to read the TL;DR: sections at the end of sections to get the gist of it and move on. :D I might do them more often, just 'cause I know my posts are often long and could be summed up more concisely.

Anywho, let's get on with the GUI stuff. As most of you know, the user interface of a program is what the user sees and interacts with when trying to use a program. There are two fundamentally different types of user interface. Thee's the command line interface, which is how we'd be using our programs so far, if they weren't processed in Netbeans:

Boom, poll done!

I actually totally forgot about the poll last night, but it's up now! Place your votes etc.

Man, until I know what to look at next, I dunno what to do :( Maybe play a video game or 2 for the first time in a long-ass while! See ya tomorrow, folks!

Java: Catching Exceptions and the Finally Block

Last post before we move on to the chapter about either more intricate processes (multiple things happening at once, basically) OR we can go right into the GUI material (Graphic User Interfaces, click on buttons to do things etc.). Either way doesn't matter to me, they're both going to get done, but which would you guys like to see first? I'll put up a poll later if I work out how, and I'll spend all of tomorrow either answering questions or bullshitting so you have time to vote on it!

For now, let's get into the material. Catching exceptions, first. Well, we've already done throwing, right, so naturally something needs to catch it. I think we've seen this in the Stack program way earlier, the try-catch block. How this works is, you have a series of statements (the body) that has some chance of triggering an exception throwing, and you stuff that inside a try block, which is just a compound statement preceded by

Java: Representing and Throwing Exceptions

To comments people: Sure I might be able to do all kinds of apps, but I'll look into it more when I like...can.
And no, I don't work as a programmer (yet), I'm barely ahead of what I post, so I still have a way to go :(

Guess how exceptions are represented in Java? Like everything else, pretty much, as objects! This actually allows information about what happened to cause an exception as well as where in the source code it happened, to be transferred easily around a program. A built-in Java class in the libraries contain quite a few exception classes, all of which are subclasses (direct or indirect) of the superclass
Throwable. Most exceptions are a subclass of Exception, itself being a subclass of Throwable (hence the indirect). There is another set of exceptions that you really don't want to come across, and those are of the class Error. These, however, are based more around internal errors, and really really should not happen. If it does, the only way to deal with it tends to be termination of the program.

So what do we do when an exceptional event occurs?

Java: Exceptions: Kinds of Errors

Whoa, this is late, I overslept like crazy! And yes, I suppose with my new found knowledge I could do android apps Y'know, when I'm done with these last 3 chapters. I'll make a whole segment about it, where you vote for what you want made etc. But that's for the (near?) future, not now! :D

So basically, we're on the chapter dealing with exceptions now, and the basic idea is that an exception is an error, and occurs when shit goes bad. I paraphrase, but its much better to "throw" an exception, that is, to stop a program running when it encounters an error, than just simply leave a message and continue as if nothing went wrong. Primarily, this is because we would, without throwing the exception, be covering up the fact that a problem occurred. Further, without throwing an error, you're more than likely going to be forced to return a valid value that will cause problems elsewhere!

For instance, back to our Stack<Car>. Say we popped a value off the stack, but the stack is empty. Normally, in a fully functional program, we'd have safeguards stopping this from being possible, but then again, ideally, no errors would occur either. So we pop a value off an empty stack, using that value to perform some other piece of functionality. We'd get a "null" returned, most likely.
Now, if the stack was to say, create a setup of Cars, like, you only want 8 cars in a room, you're going to end up with an infinite amount of cars that have no object type. The room will never be created, because, while putting in "null", which is basically nothing, takes basically no time, values are going to keep popping off this empty stack, and it'll be such a goddamn mess. BUT, if you had error throwing in place, you'd be fine. The program would stop and tell you to fix your shit. Ideally, it wouldn't end the program unexpectedly, though, but first save all current data and whatnot so as to not lose current progress.

Convinced? Good.

Errors themselves can be put into a few different categories:

Syntax
Type
Logic
Run-Time


Let's go through them briefly, shall we?

Syntax Errors
These are easiest to deal with, I think. They are caused by the non-conformity of your source code with Java rules and regulations. A little order is a good thing in code! Missing brackets or a semicolon could cause this, or keywords in a wrong place etc. Your IDE should spot these as you type, so it's rarely an issue beyond figuring out why you're getting the error.

Type Errors
These tend to be caused by mismatching, you guessed it, types. For example, assigning the value "a" to something initialized as an integer. Or perhaps calling a method that the class of a certain object just doesn't have (calling pop() on a Car).


Logic Errors
These are very different to the first 2. These are errors in your algorithms or implementations of the algorithms in your code. These, unfortunately, cannot be detected by the Java compiler, since they only manifest when the program is running, and noticed when it doesn't end., for instance. Or computes the wrong value. Popping off an empty stack, as above, for instance. Or an infinite loop (while 1 is greater than 0, do...)
This is pretty much up to the programmer to find and deal with. Normally through exceptions, and just generally checking your loops etc.


Run-time Errors
Similar to logic errors, except not caused by the program being constructed poorly. Instead, this is caused by an event that occurred either totally unexpectedly (Why would you divide by 0?) or outside the range of conditions the program was designed to deal with (Write us a program that will give all the Fibonacci sequence until a maximum of the 15th term. User asks for a sequence 16 long). This is normally a question of handling user input well, since your users are idiots, probably, and can't be trusted at all, with anything.


The last 2 are normally the source of exceptions. Unexpected events that suck. Exceptions that aren't handled are the bane of everyone's existence. These normally end up in a not-fun termination of the program. Nothing saved, nothing completed, just all around bad mojo. Very annoying. Ideally, we'll want to recover the situation and soldier on. Failing that, save data before safely terminating.

Now that we got the basic concept, I think I'll get to work, so that's it for now..Questions welcome! Comment, follow, subscribe, share etc, and see you on Monday!

And as part of a shameless plug for a friend, if you're interested in classic movies/books/music, visit his site here (fixed), and feel free to throw loads of criticism at us. 

Java: End of the Chapter

Someone asked in the comments for yesterday's post what my end goal is. I, uh....don't know. I just like learning shit, application can come afterwards. I do have a few ideas for things I want to make, but I'm not sure if Java will be the language I use to make them, or if some other language will be better suited. I suppose time will tell, but basically, I'm doing this whole thing for the sheer fuck of it. Enjoy!


We're more or less done with inheritance. There's more info in the book about overriding methods (If you have a subclass with a different implementation of a method available in the superclass) and hiding names (Same deal, but for variables and how then to access the super-variable), but I seriously doubt they'll be of any use in most cases. Just use a different method/variable name, right? If you feel like I should go over these things anyway (and more, but again, things I think will find very little use), let me know. 


Otherwise, we have 3 more chapters to get through before it gets REALLY technical, or based more on testing units of code and the programming process for large projects and groups. Shit like that. Good to know, but more on a case-by-case basis, I plan on looking them up if I ever need them, but relying on basics otherwise. The 3 chapters we have left are to do with exceptions, concurrency with threads and finally, Graphic Interfaces. I can't wait for that last one, personally.


I'll get on it tomorrow, though, my brother borrowed my textbook, and he won't be back home until late in the evening.


Questions welcome! Comment, follow, subscribe, share etc, and see you tomorrow!

And as part of a shameless plug for a friend, if you're interested in classic movies/books/music, visit his site here (fixed), and feel free to throw loads of criticism at us. 

Java: Inheritance IV

Today, we get to talk about the super keyword, and how static variables work with inheritance!


Super


Remember our Car had an int parameter, for whatever reason. Well if we had a constructor for Vehicle with an integer parameter that we wanted to use, our Car constructor would throw an error.. This is because a default constructor is looked for, but not found (we only have an integer parameter one). What we need to do instead is call the superclass constructor with either a parameter in the Car constructor, or some other value.

The super expression (heh) replaces the automatic call to the superclass constructor so the superclass constructor with the matching parameter is called instead. Just remember that if you are going to use super, it should be the first statement in your subclasses constructor.




Statics


Since static variables and methods are inherited, we should probably know how they work when inherited. Well, pretty much the same as always, 1 variable is shared between all instances of a class, including subclasses. It doesn't work in reverse though. A subclass is an extension of its superclass, but a superclass is not an extension of a subclass. Example:

...would lead to each new instance of Vehicle AND Car to increase the count, since Car uses the Vehicle constructor, but a similar counter inside Car would not increase for a Vehicle being created.




I'm tired now, so that's it for now..Questions welcome! Comment, follow, subscribe, share etc, and see you tomorrow!

And as part of a shameless plug for a friend, if you're interested in classic movies/books/music, visit his site here (fixed), and feel free to throw loads of criticism at us. 

Java: Inheritance III

Since it's hard to work with a bunch of the private variables from Vehicle, when in Car, but we don't want to make them public, in the name of encapsulation, and keeping the program....safe, I guess, there is another way that's supported! Private variables are pretty hard core, they, as we've seen, can't be used by anything but the class they're declared in, even in subclasses, which are just extensions. So instead, we use "protected". Like public and private, protected specifies the degree of encapsulation. Specifically, protected variables are usable by subclasses as well as any other classes within the same package. It's kind of like an in-between level of encapsulation!

Ta-da! No more error! So we have that idea down, I think we can fit in one more today, and that'll be on the constructors. Constructors are fairly straightforward for single classes, but when it comes to inheritance, how is everything coordinated? Java enforces some rules of construction to ensure a deterministic, as well as sensible, initialization:

a) After any parameter variables have been initialized, a call is immediately made to a superclass constructor before any other statements in the constructor body are executed. (This can be done explicitly with with "super" keyword, but we'll get to that tomorrow. Otherwise, it's done automatically).

b) All directly initialized instance variables are initialized and any initializer blocks evaluated, in the order they appear.

c) Statements in the subclass constructor are executed.

So, say with our Car, the class implemented via inheritance from Vehicle, creating a Car using the "new" operator (After giving it's constructor an integer parameter, just for display purposes):

This results in the Car constructor being called, which itself immediately calls the Vehicle constructor. Any directly initialized instance variables declared by Vehicle are now initialized, with statements in the Vehicle constructor body being executed. At this point, control returns to the Car constructor where direct initialization of instance and class variables declared in Car happens, followed by execution of the constructor.

What you want to take from this is less the technical info, but more: "Objects are initialized top down, from superclass to subclass."

Now we've got that in, I think it's time to relax, with the "super" keyword (and more!) coming tomorrow! So that's it for now..Questions welcome! Comment, follow, subscribe, share etc, and see you tomorrow!

And as part of a shameless plug for a friend, if you're interested in classic movies/books/music, visit his site here (fixed), and feel free to throw loads of criticism at us. 

Java: Inheritance II

Sorry for the late update, been sick again, but its passed!

To look at how inheritance is used, how it works and how its supported, we'll continue with the Car example we used yesterday. Since this is just for quick examples, don't expect me to have a fully functioning Car class by any stretch of the imagination, though.

I put the AirFilter and Thermostat classes (empty) inside the vehicles package just so I could show you this without a whole bunch of red lines everywhere! The point to take from this is, we have this Vehicle class, it contains a bunch of private elements that make up a vehicle, as well as an array to hold its location. I figured it would be as coordinates, but that really isn't important! Then, there's a bunch of public methods the class has, one of which is a constructor. Got it? Good.

Say now, we want to make a Car. It`s kind of like a Vehicle, but we have 4 wheels, a paint job, some headlights, whatever else. So we could just make another class from scratch, but if we were to do that (And we aren't), we'd notice a lot of similarities between the 2. Both would need to move, both would have air filters and thermostats and whatever else. The similarities are such that a Car is everything a Vehicle is, but more, as opposed to being just similar in some ways, and different in others, its just an extension. 

To make something a subclass of some other class, which is the superclass, we need to make to add in an "extends SuperClass" to the class declaration. As so:

Let's go through it bit by bit. First off, we have the class declaration. As you see, just a simple "extends Vehicle" is all we need. Car is now a subclass of Vehicle. The main method here is only for demo purposes. First, we create a Car object, and then we apply methods available to Vehicle on it. And that's all fine and dandy. Remember, the methods were all public. However, when we try to do something to one of the private variables in the Vehicle, we get an error message telling us as much.

Well, I could go on, but I'm finding it way easier to absorb information in smaller chunks, since there's more time to mull over each bit before being thrust onward, so that's it for now..Questions welcome! Comment, follow, subscribe, share etc, and see you tomorrow!

And as part of a shameless plug for a friend, if you're interested in classic movies/books/music, visit his site here (fixed), and feel free to throw loads of criticism at us. 

Java: Inheritance

Java has a few possible different relationships between classes, possibly the 2 most important types being packages and inheritance. We`ve already seen packages, where several separate classes in the same package are essentially connected, such as in our Bridge Hand program. The latter, inheritance, is essentially a way to make a class an extension of another. This may not sound like much, but its a pretty key part of object oriented programming.

Inheritance, as the name suggests, allows a class (the subclass, the child) to take on, or inherit, all of the features of another class (the superclass, the parent), often demonstrated with the following simple diagram:

Don`t know why the arrow is pointing up, it seems like it would make more sense the other way around. But hey, doesn`t stop how the whole inheritance thing actually works. The subclass inherits all the variables and methods from the superclass, excepting the constructor. To make this something useful, the subclass can also  declare its own variables and methods, as well as redefining some superclass methods, normally known as overriding. This allows the subclass to specialize to its own needs, while holding the same general structure of the superclass.

Let`s have a couple of examples so its easier to understand. Say we have a very very general class: Vehicle. Then we can have several subclasses to fit the role of vehicle, but be specialized depending on what we want. We can have a Truck, Motorbike or a Car defined as a subclass of vehicle. We can say that our Car is a Vehicle. It`s everything a Vehicle needs to be, but more, its specialized. Size, seating, number of wheels, windshield, whatever. It`s not just the difference between 2 Cars, the difference isn`t only the color or whatever.

Inheritance isn`t limited to one level (When is anything, in coding? Goddamn recursion, man.), you can have a subclass of a subclass. We can now have a SportsCar if we want, as an extension of Car, with it's own specializations. One important limitation to keep in mind, though, is that a subclass can only have 1 superclass. I can't have, say, a Harvester be a subclass of both a Vehicle and FarmEquipment. Yech, think of the insurance rates you'd get on that thing. Worse if your harvester was red, I'd imagine. Anyway, tangent! Moving on.

This is all very awesome, but what does it mean for particular objects? If, say, an object, myCar, is an instance of a subclass, Car, then it'll contain all the variables and methods as available in Car, as well as Vehicle. On top of this, any methods declared by any class can be called for objects of the subclass (myCar), providing they are public. This remains true however far the line you go.

There's apparently quite a few complex rules we'll be subjected to soon, so I think it's time for me to understand the core idea fully before moving on, that's it for now..Questions welcome! Comment, follow, subscribe, share etc, and see you tomorrow!

    And as part of a shameless plug for a friend, if you're interested in classic movies/books/music, visit his site here (fixed), and feel free to throw loads of criticism at us. 

Day Off!

I think 1 day off a week is a good idea, and I'll probably make it Sunday! So no post for you!

Java: A Summary so Far

Quick summary! Java is object oriented. This means it works based on objects, which are just abstract representations of...whatever. Like in our program to deal out a bridge hand. Could have just used a shuffled deck and then randomly split them into 4, but based on how Java works, we needed a table for players, players to play, and a deck made up of cards to play with.

Performing an action in java is done through use of statements. You can add, subtract or use methods on various variables (containers that hold either abstract values, or location in memory of where an object (in terms of its own abstract code) is stored. Each statement ends with a semi-colon so the program knows when to move on, since whitespace does not matter.

There are several special statements you can use, some of which are method creation, conditionals and loops. Methods are a collection of statements that can be called all at once at any point by calling the method name on the object in question. Example: We have a class representing a deck of cards. To shuffle this deck, in terms of programming, we would need to get a random number, and then flip the card at that number with the current card. Instead of requiring this every time you want to shuffle, put it in a method named shuffle, then call Deck.shuffle().

If-statements take the form: if ( condition ) { action }; with any subsequent cases being noted with else if, and the final case being noted with just else.
Loops consist of while loops, and for loops. While loops take the form: while ( condition ) { action }; and repeats until the condition is no longer true. Thus, we need to make sure that within the action body, we modify the condition (often an integer) such that eventually, it'll break the while loop.
For loops have 2 types, there's the for-each loops, taking the form: for ( Type : list ) { action }; which takes every element of the list or array provided with Type's type, and performs the action on it.
The regular for loops takes the form: for ( int i = startingValue ; condition tied to i's value ; how to modify i at the end of each iteration ) { action }; which can be used for a set number of iterations.

Methods in Java can call other methods and even themselves. The latter is known as recursion and often simplifies code, although it is more stressful on the machine to run.

Declaring a variable requires you to place the type of the variable before the variable name. This is because each variable type or object takes up a different amount of space on disk and you want to assign the right amount of space. Similarly, if you want a method to return a value when it's done, such as a method to add 2 numbers that you actually want to use, you need to declare the returned values type when declaring the method.

There's a bunch of stuff on data files, but there's not really a way to easily summarize that, so go back and find it, I guess, as well as anything else I missed! Unless there's a specific question anyone has?


Otherwise, that's it for now..Questions welcome! Comment, follow, subscribe, share etc, and see you tomorrow!

    And as part of a shameless plug for a friend, if you're interested in classic movies/books/music, visit his site here (fixed), and feel free to throw loads of criticism at us.