Jan 28

Java Needs Properties

OK, this is get­ting ridicu­lous. It’s been, what, 25 years since Java start­ed and we still haven’t fixed one of the sin­gle biggest pain-​points for the language—properties. I mean, just look at this mess:

The amount of boil­er­plate is huge and that’s with­out con­sid­er­ing oth­er boil­er­plate meth­ods like equals():

Ugh, I hate typ­ing all of that. If the object is a bean/​POJO then we can use gen­er­a­tors to help write some of the code at the expense of some weird code: strange inher­i­tance, abstract objects, anno­ta­tions, etc.

Now with prop­er­ties and some com­pil­er mag­ic we could have the same behav­ior that looks more like this:

And this would inter­nal­ly gen­er­ate the sec­ond exam­ple above. If you don’t like adding new key­words we could do it almost as ele­gant­ly with anno­ta­tions:

This could eas­i­ly be extend­ed to sup­port read-​only prop­er­ties as well as over­rid­ing the getter/​setter. Overriding the set­ter is need­ed to val­i­date the val­ue.

This would inter­nal­ly gen­er­ate the equiv­a­lent of this:

Note the assert in the con­struc­tor in the gen­er­at­ed ver­sion. This was added by the @NotNull anno­ta­tion. If the code gen­er­a­tor can guar­an­tee that name is set before the end of the con­struc­tor the it can elide the assert().

Anyway, there is a lot more that can be done. A prop­er­ty could be marked as part of the objec­t’s order­ing and then it would be added to a gen­er­at­ed compareTo() method. The basic idea is to remove the boil­er­plate and to force con­sis­ten­cy in code between pro­gram­mers.

Feb 15

Google phone interview part I

I applied for a job at Google and thought I’d write about my expe­ri­ences with their inter­view process. Many oth­ers have writ­ten about the process and my expe­ri­ence was sim­i­lar to theirs. I sub­mit­ted my resume through their web site and even though the mar­ket isn’t great right now I got a response from one of their recruiters who I’ll call Carol.

Carol informed me that I had passed the first round by sub­mit­ting a resume that was good enough to ring some bells and that she was sched­ul­ing me for a phone inter­view. Right away my heart start­ed pounding—I heard about these myth­i­cal phone inter­views from the web. These minia­ture tort…er…interrogation ses­sions were renown for their abil­i­ty to bring even the might­i­est of us to tears.
 
“How about Wednesday?” she asked. “Wednesday is fine” my finely-​tuned grey mat­ter spit back with­out con­sid­er­ing a) I would be out of the area (oth­er peo­ple would call it a vaca­tion), b) it was only 4 days away (five if you count the day of dri­ving to get to my des­ti­na­tion), and c) I had­n’t talked with my wife about it. So not only did I not ask for more time but I had just com­mit­ted to spend­ing most of my (our) vaca­tion pre­ping for a mini inqui­si­tion. I could hear the con­ver­sa­tion in my head: “Oh hun­ny,” I would say to my wife, “you know those longs walks in the woods you were plan­ning on…well…and, ha ha, this is sooo funny…you see, he he…I just agreed to do a phone inter­view, ha ha, on Wednesday, he he, that, ha ha, I have to spend every (snick­er) hour of every day study­ing for! Isn’t that great? Hunny?” Yeah right. I’m a dead man.

Luckily I’m mar­ried to an under­stand­ing woman who decid­ed to be supportive—so sup­port­ive that she drove (she hates dri­ving on long trips) and had me study on the dri­ve up. She also had me research­ing the web for tips. Does any­one else see the irony of using Google to search for “Google phone inter­views?”

So the big day arrives. I have my phone ful­ly charged (yeah I’ve had the phone dies in the mid­dle of the impor­tant phone call), I have my notes, and most impor­tant­ly I have my pre­ferred caf­feine deliv­ery sys­tem: Coke. In fact I’m on my sec­ond when my wife says “Did you check to make sure the cell recep­tion is good?”

Cue the dramitic music and zoom in on the bars on my cell. At this point one could ask “what bars?” but I’m not sure that my heart could take that. “NO BARS!!” I screech not real­iz­ing that the human voice can actu­al­ly hit that high a tone. My wife looks at me like I’m…well…stupid. “You know it does­n’t work on the first floor. Go upstairs and check.” My wife is very patient. I get upstairs and look at the phone with trep­i­da­tion. One bar…two bars…three bars!…no two bars!..no three!…two…

I’m not sure how long I stood there watch­ing the third bar flick­er in and out until I real­ized that the best recep­tion is in the bed­room and I go in there. Yay! Four Bars!!!

I should men­tion at this point that the place we are stay­ing is out­side of Klamath Falls, OR and that there are hills between us and the cell tow­ers. There is one low spot that seems to line up with the bed­room on the sec­ond floor. I know this as we have been there sev­er­al times. I’m an engi­neer, OK a soft­ware engi­neer, but I under­stand the prici­ples and yet I can’t seem to get my brain wrapped around this and I’m about to take what is reput­ed to be a tough phone inter­view.

My phone rings. I’m doomed.

Jul 23

Java Complexity

Java as a lan­guage is get­ting more com­plex with each ver­sion. From ver­sion 1.0 to 1.4 most of the com­plex­i­ty was added through libraries. Thousands or lines of code were added in hun­dreds of new class­es. But this com­plex­i­ty was contained–if you did­n’t need a fea­ture you could ignore it com­plete­ly. At worst, you might miss out on some new, neat fea­ture. But start­ing with 1.5 the lan­guage itself changed (OK 1.4 added asser­tions but that’s a very small fea­ture that can be read­i­ly ignored).

Version 1.5 added enums and Generics. Enums are a medium-​sized change, main­ly a way of list­ing enu­mer­a­tion val­ues, but there are sub­tleties that make them com­plex (like con­ver­sion to/​from inte­gers, access­ing all the defined val­ues, etc.) Generics are a big change. The fact that all the col­lec­tion class­es were retro­fit­ted to be gener­i­cized1 means that most new code will have to deal with them whether they want to or not. Trying to ignore them just results in streams of warn­ings.

Now with 1.7 or maybe 1.8 we are talk­ing about adding clo­sures and pos­si­bly con­tin­u­a­tions and prop­er­ties. If you think that code with gener­ics is hard to read then just wait for clo­sures. The sub­tleties of where a braces goes to decide if a clo­sure is being defined is guar­an­teed to cre­ate uncer­tain­ty and con­fu­sion.

My ques­tion is “are we adding too much com­plex­i­ty?” The thou­sands of lines writ­ten for the libraries before 1.5 are extreme­ly use­ful and in fact are still used after 1.5 so gener­ics, enums, and clo­sures are not nec­es­sary for use­ful code. So why do we see the need to add this com­plex­i­ty?

When I start­ed using Java I thought it was a nice sim­ple lan­guage for writ­ing web tools but that it was­n’t a “real” lan­guage for use in “real” work. But then I start­ed using it for a real project and I real­ized that it might be a sim­ple lan­guage, but it could do what I need­ed. Granted pre‑1.2 things were a lit­tle coarse but by the time 1.2 came out things real­ly start­ed to smooth out. Then as I used it more I kept think­ing “this is a bor­ing lan­guage; it has no fun fea­tures.” Years lat­er, as I have got­ten old­er, I have begun to recon­sid­er my eval­u­a­tion. Yes, Java is a rather sim­ple lan­guage, but that may be a good thing.

I like func­tion­al lan­guage as I think that func­tion com­po­si­tion is a very pow­er­ful fea­ture that results is small­er code bases. But when I look at what’s com­ing in future releas­es I start to wor­ry. Here where I work we have devel­op­ers of dif­fer­ing lev­els and I have seen them have prob­lems with even the sim­ple things in 1.4. Complex fea­ture like Generics are going to make it hard to keep every­one up to the nec­es­sary lev­el of com­pe­tence.

Even though I was one of those clam­or­ing for Generics I am now not so sure that they should have been added to the lan­guage. I con­sid­er myself a senior devel­op­er and while I am now com­fort­able, but not an expert, with using gener­ics it is such a big change that I would say that Java 1.5 is actu­al­ly a new lan­guage. As a senior devel­op­er I have no prob­lem learn­ing new lan­guages and in fact I learn new ones for fun. But think of the junior and even mid-​level devel­op­ers. May of them are still try­ing to get a han­dle on the base lan­guage.


  1. I know this isn’t a real word yet, but it is becom­ing preva­lent in the busi­ness and it seems to be the right word for this sit­u­a­tion. 
Jul 17

Java Generics III

Last time I talked about using gener­ics to make get­ting val­ues out of col­lec­tions nicer (and a pro­pos­al that would obvi­ate their use) so this time I want to talk about the oth­er half–passing items into a col­lec­tion. This encom­pass­es all meth­ods that take a para­me­ter of the col­lec­tion’s gener­ic typ­ing includ­ing those that add items to the col­lec­tion.

If you look at the byte-​codes gen­er­at­ed for call­ing any of these meth­ods you will see that there is no run­time check­ing of the objects being passed. This is because the meth­ods of the base object are defined as tak­ing Object types. The only check­ing hap­pens at com­pile time. So as long as the sta­t­ic type is cor­rect every­thing is fine but it is easy to over­ride the sta­t­ic type (acci­den­tal­ly or on pur­pose) so what hap­pens? Well, if you attempt to retrieve a val­ue from the col­lec­tion and the type is not assign­ment com­pat­i­ble with the tar­get then you will get a ClassCastException.

Let’s think about that for a moment. The excep­tion is not thrown when the invalid val­ue is added to the col­lec­tion (when track­ing down the error would have the con­text of the sit­u­a­tion) but when it is removed (or exam­ined). This defeats the basic rule of “fail as ear­ly as pos­si­ble”. It also means that a state­ment with no cast oper­a­tor can fail with a class cast excep­tion. This seems counter to the spir­it of the lan­guage and in fact leads to con­fu­sion. You look at the line that the stack trace points to and say to your­self “there is noth­ing there that can throw a class cast excep­tion.” After a this hits you a time or two you will remem­ber but why should you have to make that effort?

I will grant that the gener­ic def­i­n­i­tion does make it hard­er to acci­den­tal­ly put in the wrong thing, but it does­n’t elim­i­nate it entire­ly. If we are going to have a checkcast byte-​code on retriev­ing the val­ue then why don’t we have it on putting the val­ue in as well?

Jul 13

Java Generics II

In Part I I showed how gener­ics have no effect on the byte-​codes gen­er­at­ed by the com­pil­er and that as far as the get­ters of the col­lec­tion class­es the only tan­gi­ble ben­e­fit is that you no longer have to add casts to the get expres­sion. So some­thing like this:

becomes this:

Now don’t get me wrong, I think that this is a good thing. As far as I’m con­cerned, casts are just wast­ed typ­ing that is only for the com­pil­er. So get­ting rid of casts is great. But the prob­lem is that to get this fea­ture you have use an even ugli­er syn­tax (gener­ics) in oth­er places. So the method this line is in might look like this:

Now I will grant you that the casts were in the body which obfus­cates the code you’re try­ing to read but now are in the func­tion def­i­n­i­tion and that if you are using the val­ues more than once you’ve trad­ed _​N_​casts for 1 def­i­n­i­tion. But the flip side of this is that you have now moved an imple­men­ta­tion detail into the pub­lic inter­face. In the old style this method would have said “I take a Map and do some­thing with it” but the new one says “I take a Map of String to String and do some­thing with it.” More on this in a lat­er post.

So I have an idea for a pro­posed lan­guage change that I wish I could have made (and got­ten imple­ment­ed 😉 years ago. It is a sim­ple change but I think it would have made a major pos­i­tive change to the lan­guage.

Why not remove the need for casts for down cast­ing?

If you take the basic assign­ment

The types X and Y are relat­ed in one of four ways (assum­ing nei­ther is a prim­i­tive):

  1. X and Y are the same type.
  2. X is not direct­ly relat­ed to Y.
  3. X is a super­class or inter­face of Y (upcast­ing).
  4. X is a sub­class of Y (down­cast­ing).

In case #1 no cast is nec­es­sary. In case #2 the state­ment is invalid and adding a cast will not change that. In case #3 no cast is nec­es­sary. In case #4 a cast is need­ed to com­pile and a checkcast byte-​code is gen­er­at­ed to val­i­date the assign­ment at run­time. If you look at the casts it turns out that down cast­ing is the only one that we can change and it accounts for most of the casts in a pre-​generics pro­gram.

The inter­est­ing thing about the down­cast case is that the com­pil­er checks to see if a cast could work (are the types relat­ed) but it still emits the checkcast byte-​code. So my ques­tion is if the com­pil­er already checks the assign­ment is valid and gen­er­ates a checkcast byte-​code any­way why can’t we just tell the com­pil­er “if you see a valid down­cast, just emit a checkcast byte-​code with­out requir­ing the cast”?.

To make this con­crete I want to change this

into this:

If the com­pil­er allowed this the sys­tem would be no less safe as the checkcast byte-​code would still be emit­ted to check at run­time but the code is clean­er. As far as I can tell the only rea­son the cast is required (here I’m putting on my Mind Reading Through Time Helmet) is that some­one said some­thing like “If we tell the pro­gram­mer that they are down­cast­ing and that this is a dicey oper­a­tion they will check their code to ver­i­fy that this down­cast is valid at this point and then add a cast to tell the com­pil­er that they val­i­dat­ed the code.” This sounds good but let’s be hon­est, do you real­ly check your code to ver­i­fy the cast in all cas­es or do you most­ly just add the cast because the com­pil­er wants it?

I thought so. But even if you check your code now there is no way to pre­vent a change lat­er doing the wrong thing or if you take a para­me­ter there is no way to pre­vent some­one else from mess­ing you up. This is why the com­pil­er emits the checkcast byte-​code even though you added a cast. It is too easy make mis­takes.

So giv­en that most of the time the cast is just added to shut up the com­pil­er and that the sys­tem still adds a byte-​code to pre­vent mis­takes why not just get rid of the cast require­ment? Just think how sim­ple the col­lec­tion class­es would be to use. They already do not need a cast to put object in and with this change they would not need a cast to get the val­ue out and the gen­er­at­ed code would be iden­ti­cal to the code cur­rent­ly gen­er­at­ed (see Part I).

Casts are intru­sive, ugly, unnec­es­sary for under­stand­ing the code, require dupli­cate typ­ing

and do not make the code any safer. If this change had been made to the lan­guage in any ver­sion before 1.5 I believe that there would have been a lot less demand for Generics.