JDBC to the Rescue

I just read a chapter on the JDBC. This allows me to access databases from my Java code. Now I have the power to write CRUD apps. Yeah. So far I have written some code that uses Statements to do basic querying. I have also delved into PreparedStatements to insert and update.

To test out and play with this capability, I downloaded and installed the latest MySQL database. It is taking a while to get used to MySQL database administration. I also got MySQL Connector/J so that my JDBC can talk to the MySQL database. So far it works like a charm.

I have studied and modified a little bit of code that uses an AbstractTableModel and JTable. This seems to be quite the powerful combinatoin. It is also something that will take a while to learn. Now the world of databases it at my fingertips. Perhaps I shall try to connect to an Oracle database with JDBC as well.

Towers of Hanoi

In my Java class this semester, we went over the Towers of Hanoi problem during our study of recusion. The recusrive solution is elegant. It is also simpler than any iterative solution. We did not code a solution. We just studied one intently to understand the recursive nature of it.

Recently I saw one of the sample problems you need to solve during a Facebook interview. One of them is the Towers of Hanoi problem. Nice. Facebook even let's you code the thing in Java. It has to work correctly. And you need to complete the thing in 45 minutes.

Not sure if I can meet that metric. But at least I have seen the problem and solution before. I guess I could google the code. That would be cheating. I feel good about what my Java college class is teaching me.

Multithreading

I am just starting to learn multithreading. My second exercise was to put 20 balls on the screen. Each one is moved using a different thread. On the surface I was surprised what little computer resources the 20 threads used. My machine is dedicating 3 percent of its CPU to the bouncing balls app.

I have some nice and smooth animation too. Every frame update causes the whole screen to be repainted. Right now I am using the basic Thread class to start up and Runnable. My main thread, which I assume is the event dispatch thread, updates the GUI on a timer (which happens to have its own thread).

Next I should try a whole lot more threads. Or I could make the graphics more intense. I need to figure out where the performance bottleneck is, if any.

Eating the Keys

I am learning about the finer points of GUI development with Java this week. It turns out there are some GUI basics in Java that I don't know about. So I am studying them first. One topic of interest is catching events. To practive, I started coding up an event viewer. It is supposed to get and print out events that fire based on a bunch of different GUI components.

For the most part I can knock out the even viewer code. I am setting up listeners that log events to the screen. Then I try to do a KeyListener. But my event handlers are not getting called. What the heck? Initially my text area control was displaying the keys. Okay. I disabled it. Still no keyboard events.

I am a good debugger. I traced the issue down to the presence of a JButton on my GUI. If I remove the JButton, the keyboard events fire and I get the calls. What could be going on here? Is the JButton receiving and eating up the keyboard events? It looks like I am going to have to consult an expert here.

The Need for Wildcards

We are covering generics in my advanced Java community college class. The weak book has a tough time explaining concepts clearly. I get the main idea behind generics. Java gets to keep up with C++ templates. But then we get to something which does not seem right.

Since the Integer class extends Number, you can pass in an Integer object when a function requires a Number parameter. That is clear. But when you use those types with a generic class such as Stack, things get weird. You cannot pass in an object of type Stack when a function requires a Stack parameter. What the heck?

Integer extends Number. The Stack is a Stack. Why can't Stack act as a Stack. Makes no sense on the outside. The book cooked up some example to try to explain it away. I was still not convinced. Later I read about the use of wildcards to solve this problem. You get a Stack argument type that can then receive a Stack. But why do we need this new syntax in the first place. The textbook could not explain it. Time to dig deeper.

Collections and Maps

I have been studying up on the Java Collections Framework for the past week. It was hard to get a grasp on such a huge subject. Initially I had trouble figuring out what were the interfaces and what were the classes. With the help of Wikipedia and the Java API documentation, I think I am starting to understand it a little better.

There are really two main things to get here - collections and maps. Collections is the bigger piece. The grandfather interface is Collection (from java.util.Collection). A couple important interfaces extend Collection. They are List, Queue, and Set. You then get a bunch of classes that implement these interfaces. Do not get confused by some base classes which are then extended to the classes you use on a daily bases.

Maps are their own thing in that they store pairs of keys and values. Like the Collection interface, maps start with the Map interface. Then you have some classes that implement Map. Those classes are often extended to give you convenient classes to do your work.

One thing that is common to all this is that you need to write some code to get a feel for using the collections and maps. When in doubt of the hierarchy, take a look at the UML diagrams from Wikipedia on Collection and Map.

Collections Framework

This week my college class is doing the chapter on the Java Collections Framework. The textbook was very confusing. It looks like there are some interfaces to get familiar with. Then there are multiple classes that implement the interfaces. Other interfaces are involved as well. Initially I was overwhelmed. Now I am trying to focus on a few classes at a time.

I found that Wikipedia has a good overview on the collections. The first class I got familiar with was the HashSet. This thing is a generic class. You need to pass in the type of the items that are stored in the collection. HasSet implements the Set interface. As such, it can only hold unique items in the collection. You add() items to the set. You can also check whether they are already ikn the set with a call to contains().

The second class I played with is HashMap. Do you see a pattern forming here? This class implements the Map interface. You store key/value pairs with this thing. You need to specify the types of the key and value when you create the generic class. Then you put or get key/value pairs.

Most of these collection-related items seems to be in java.util. Let's see if I can figure out all the other classes and interfaces. I am studying it hard.