Dienstag Jan 06, 2009

A MySQL GlassFish Application

During my time as a teaching assistant, I used to say to the students, "Imagine, you visit your grandmother and she asks you, 'Now boy, what did you do at the university today?' It's hard, but you have to do your exercises in a way, as if you were talking to a six year old." On the other hand, students are often frustrated, if they don't understand a subject down to its bare bones. It's only natural to have such feelings.

Giving a tech talk, you have to find an interesting sample, but it also has to be simple, for you don't want your audience to fall asleep. I was dreaming of a database-web application without tables full of employees, departments and managers or flight schedules. It had to be something, where the design tools and the web stack stand more in the foreground.

I started a project -- www.mimesy.com, using the NetBeans IDE, JSP, the jMaki framework, the MySQL DBMS and the GlassFish application server. It's some kind of a blog site, but the user cannot actually blog, microblog or nanoblog or upload any media files. The only thing you can tell the world is a color. There is also no history of colors, just a color you have at the moment. Login data and the color information can easily be stored in only one database table.

Donnerstag Jul 24, 2008

The Number of Rows

Last month, I held a presentation where I showed how to create a rich client application for a MySQL 5 database using the NetBeans 6.1 IDE. For a single table we can use the Database Application template (New Project → Java → Java Desktop Application → Database Application). Assuming that the table exists and we have created a connection to it, we get a ready to use GUI by just clicking 'Next' and 'Finish'. One of the funny things we can add in the GUI editor is a slider, whose value is bound to a data field (Properties → Binding tab). Then the data in the form gets updated when the slider is moved.



Suppose we want a label to reflect the number of rows in the table, especially we want the label to change when the number changes. Unfortunately, the bind trick doesn't work in all situations. A bound label doesn't get updated when we add or delete rows. During a demo, you don't want to write to much code and you want the solution to be simple. Without going to much into detail, we get the update functionality by adding an event handler for main frame's propertyChange events.

   private void formPropertyChange(java.beans.PropertyChangeEvent evt) {

Donnerstag Apr 24, 2008

Too Many Return Types

(inspired by a discussion on one of my mailing lists)

The compiler says 'No'

Thank to the overloading feature in the Java programming language, method names within a class have not to be distinct (as long as the signatures differ). Can we overload a method by changing only the return type, i.e. if there is a method, can we define another one with the same name and parameter types and order, but with a different return type? The compiler says 'No'.

   class A {
       S f( p ) { ... }
       T f( p ) { ... }   // ST, p is a parameter list

This behavior is defined in the language specification [1] and, with the return type not being part of the signature, it is not a violation of our definition of overloading. Of course, the language-specification argument is only for the compiler a strong one for treating the situation in this way. For those, who sit on the other side of the code, it's more a fact than a reason.

Who you gonna call

Although we don't hold methods to be objects in the sense that they are instances of OOP classes, in our minds a method still has a type, and the most interesting properties are possessed by its input and output. Thus, if we imagine that a method is something like a function, we can write

P1 × P2 × … × PnS

as the type of the first f from the example above; the type of the second f looks similar, S is replaced by T. Let's now suppose, there is a call to f somewhere in the source, so that it's
  1. a call where the return value is thrown away, or
  2. a call where the return value is passed to a method or an operator (as an argument).
At this point we run into difficulties, for it's not always clear which f should be called (we'll see, that this holds for both cases). Since the difference lies in the method type, we must specify the type of the method we want to be called. The types behind the arrow can be derived from the call itself. This is how an overloaded method is normally chosen, but here we have to specify the return type as well.

The obvious solution is at the same time the behavior we want to have claiming return-type overloading. A call is always within a certain context, and it's the context that shall specify the return type. For a (non-overloaded) method g of the type SR (Svoid), putting a call to f into the argument place, we want the first f to be chosen. If S or T is void, case 1. specifies an f too, otherwise we don't know which f is meant.

However, there remain more situations where the context does not do the job. First of all, return-type overloading collides with parameter-type overloading (and with generic programming). Suppose there are now two methods g, one taking an S and one taking a T as an argument. Then in g(f(...)) we want the call to f to specify the context, on the other hand we want the context to specify an f.

Implicit type conversion can be treated as a kind of parameter-type overloading (e.g. a method that takes a java.lang.Object as an argument does not distinguish between all the subtypes). Sometimes we want to cast a return value. Again, we can think of a cast operator as an overloaded method.

From the existence of such cases it is apparent, that we need a special syntax that resolves ambiguity, and it's not possible to stay within the grammar of the language.



Sun Campus Ambassador,
University of Frankfurt (Germany)


« April 2014