Java: Screw the Network Application

O hi, there! Last night I realized that holy shit, this teaches me NOTHING, so I'm moving our day of bullshit up one! Like, seriously, it was useless, and I didn't read more than 1 day ahead, so I only realized this yesterday. Bah, waste of time. I suppose it was a little more practice with Threads and stuff, but eh. So instead, today I'm looking at Texas Hold Em and what classes would be required to get it.

So while I'm doing that, I'm peppering my time with random bouts of LoL and Minecraft (Which I only just got), and I'm more or less addicted to creative mode. Not even got the hang of the circuitry bullshit, I just build mazes galore. Good stuff.
I did try survival mode, but after trying to be a nomad from the spawn area (too many people around) like....8 times, and getting killed each time, I thought fuckit, and made a hovel in the ground. Then went back to creative :D

Anyway, see ya tomorrow for the first of Texas Hold Em (Y) I do think that the graphics will be the more annoying part of it, though.

Java: A Network Application (4)

Aah, had a migraine last night and now I don't. Best feeling ever. So I can happily move on to the NodeListener today, as promised! Meaning tomorrow we have the actual faux-application, then we're done. One day of bullshitting and stuff, then onto actual game stuff.

This is actually a very short class, and it's not ideal, since it uses the Application itself, before it's been created. I just fixed the errors popping up using the automatic stuff Netbeans does. Just created an empty class and method as a placeholder until I actually get around to making the application later tonight.

Java: A Network Application (3)

Somehow, I didn't get enough sleep, still. Oh well, time for more postin'! Today, we're continuing right off the network node from Saturday, and we'll be done with that. Tomorrow, we go to the node listener, then Wednesday we write the actual application. I'll give you until then to throw out any questions or requests about anything before we move on to those (in all probability, shitty) games!

So, diving into it:

Java: A Network Application (2)

Today's an early one, but also short, since I've had no sleep yet! Let's start at...well, the start. We'll want the lowest level of objects first, which is the NetworkNode itself, so we can have a Listener listen for it, and then the application to interact with it. This should be the only class I'm doing in 2 parts, the others look short, at a glance.

We're going to be using Random, which is in the Java libraries. I don't think we've used it yet, but it's fairly straightforward. Create a random object, then use the next...() method, you'll see below:

Java: More Multithreading: A Network Application (1)

This is the last example in the book, and I sure hope it helps me understand multithreading better than the other ones... Also while I remember: Texas Hold 'Em might be easier than I at first imagined, since, like 21 sticks (which I also realized is normally played with 1-4 sticks...oops!), it's (sort of) turn based. Nothing needs to happen simultaneously, so yay!

For now though, one more example on multithreading: A Network Application. From the text:
"The main purpose of this section is not to solve any particular problem but to show what an event is,

Java: Shared Queue 4: Complete Test + Source Code

Gah, late thread, sorry! This one's a bit of a doozy, so bear with me! I'll start off with a brief overview:

Step 1: We need to actually create the thread-safe queue to use.
Step 2: Set up all the producers (don't run them yet, we don't want threads to start running before all are in place)
Step 3: Set up all the consumers. We can start them running now, since both producers and consumers are ready. Since the queues are as of yet, empty, this isn't an issue. Seeing an empty queue, the consumers will yield.
Step 4: Start the producers.
Step 5: Wait for the producers to finish. Once they are, no new values are going to be added to the queue.

Java: Shared Queue's 3: Testing Classes

Apparently, no one did shit, so I guess discussing that is outta the question :P So straight onto how I tested it! I'll put both the consumer and producer classes into an umbrella class just so its all together. I'll leave the actual running of the tests to tomorrow, since I'm a bum (or a tortoise?) and haven't actually like, got there yet. I mean, for your benefit, so we aren't moving too fast. Clearly.

I do have the actual classes to be used in the testing though, and here they are:

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.