Site Sponsors:
Sunday Learning: GWT 
I don't know about you, but making a week more enjoyable often involves deliberately adding a special day.

For us, we like to be sure to have one day set aside for discovering and / or mastering new ideas.

In as much as a lot of things often need to get done on Saturday, in a like manner, just as many distractions ever seem to disappear the day after.

So by way of celebrating the practice & mastery of cool concepts, today our thoughts returned to Google's GWT.

GWT


By allowing us to "compile" Java into browser-specialized code, GWT can help us maintain tedious labyrinths of JavaScript with object-oriented ease. -Clearly a revolutionary concept in browser-support history, perhaps some day someone will allow us to do the same with PHP?

Historical Pattern


Of course, the pattern of front-ending a nasty set of code with a more manageable set of object, after all, is well known.

Indeed, from a historical prospective, one cannot help but to recollect a little tool called CFRONT.

For us early adapters (pun, pun) of OO for C, CFRONT was used to mitigate between C++ and C. Surely some day 'tech historians will agree that CFRONT brought the object-oriented revolution (let alone the GWT object-to-procedural-code management process?) to the "sunday-learning" masses.

Managing The 'Web


Yet regardless of how one might feel about Object Orientation in general (or Java in particular?), over time everyone agrees that maintaining a rich, browser-aware web presence in PHP - let alone JavaScript - quickly becomes a nightmare.

(How much of a nightmare, you might ask? Well, a few years back I was offered a salary of $250,000 / year to maintain an extensive PHP / JavaScript web-site-n-service 'farm.' Even with their local office, I would be allowed to work pretty much from home. The ideal job? Yet even at 1/4 million dollars a year, they were having trouble finding anyone who wanted to do it... I turned them down, too.)

If you what to learn a little more about how to 'web-in' the GWT, then many find this discussion to be of great interest.

If you already use eclipse + the GWT plug-in, then by way of introduction to what many feel is a great way to save us all from waking, work-place horrors, feel free to click the related link, below.

Note that a supporting command-line tooling for GWT is also available. Note also that debugging requires a browser add-in (I used FireFox on Ubuntu. From AJAX to RPC via XDR: With a single click, the 2.5 release all finally worked great ... the very first time it ran! (i.e. getting it-all to run took some engineering with the previous releases.))



(p.s. The creepy little chesire cat was not included. That was just me 'Gimp-ing around.)

Cheers,

-Rn


[ add comment ] ( 4148 views )   |  permalink  |  related link
New Release of Derby & Eclipse 
Last month was certainly a red-letter celebration! Why? Because - for most of us Java enthusiasts - we were blessed with both a new release of Eclipse (from Indigo to Juno), as well as a new release of Apache's Derby SQL Database.

What-be?


Eclipse Juno is cool enough. Despite the other enhancements, right out of the box I noticed lots of new hints. Suggestions that even made ClassIO (a project I was playing with at the time) a little better.

But then there is Derby: For those of us who like to write stand-alone applications, there is nothing more important than providing reliable data storage.

Indeed, when thoughts turn to SQL and Java, there is little more refreshing than using Apache's Derby Database. No licenses, no hassles, and 100% embeddable ("embeddable" == no nasty database sql server to set up, license, upgrade, integrate, patch-patch-patch, manage, etc.)

Sourcing Derby


Like most things Java, all things Derby begin with the .jar file. For those who do not already have a copy of derby.jar floating about their folders, the first thing to do is to download and ''install'' a copy:

1.) We can download the Derby Database [here].

2.) Once downloaded, open the archive and copy the folder therein to somewhere special.

3.) Finally, locate & associate the enclosed derby.jar with you project. -For both Eclipse and Netbeans, all we have to do is to add that jar to our project.

Thats it! No matter if we are liking either Netbeans or Eclipse, all we need to do is to use that derby.jar.

Using Derby.jar


Okay - I admit that I am not the biggest fan of Eclipse. Why? Because - for those of us who like to manually back-up and manage our source code, handing a copy of the IDE to a new software developer is like handing a loaded gun to a teenager. -While things often work out completely okay (all of our kids are marksmen :), all can go horrifically wrong. Certainly for folks operating under the influence of Hollywood. =)

Yet when it comes to re-using things like derby.jar, both Eclipse and Netbeans have a real simple way to associate a jar with a Project. Once a Project has been created, we can leverage just about any external jar by:

For Eclipse: Simply select "Project" then "Properties" from the main menu. Thereafter, all we need do is to click on "Java Build Path", then click on the "Add External Jars..." Button.

For Netbeans: Merely right-click on your project to select "Properties". Select "Libraries" in the list-box, then click the "Add JAR/Folder" Button.

For Both: Once we see either IDE's JAR Selection Dialog, we merely need to browse to that lib folder in our ''special place'' to locate that derby.jar Archive, and all is well. The archive will be included alongside of any and all related artifacts for our project.

Dedicated Database Connections


While extending Derby capabilities to our project is good, at some point everyone will want to integrate their databases into a production environment.

Derby Sessions


For Netbeans: From the main-menu, simply select "Windows", then "Services." After expansing the "Drivers" entry under the "Services" Tab, we can right click to manage our Derby, Oracle, Postgres, and / or MySQL connections with impunity.

For Eclipse: The first thing to do under Eclipse is to switch into that all-powerful "Database Development" prospective. Once there:

(1) Right-click on Databases Connections to select that New… popup-menu, item.

(2) Within the Connection Profile Dialog, select the Derby set of platters, then click Next.

(3) If the New Derby Connection Profile is stark naked, then we will most probably have to create a New Driver Definition.

(3a) We can create a new driver by pressing the button to the right of the Drivers: text-box.

(3b) When creating a New Driver Definition, the JEE Eclipse - Juno install base I am presently using lists 10 templates. For my stand-alone purposes, I selected the Derby Embedded JDBC Driver. Most folks will want to use the Derby Client.

(3c) Once selected, simply tab-over to the JAR List Page, to press the Edit JAR/Zip Button.

(3d) Once we see the Select the file: Dialog, browse to the lib sub-Folder in that ''special place'' to locate & select that derby.jar (or derby-client.jar) Archive.

(4) Mash on finish, then go set-up your database.

(*) If this is the FIRST TIME to run your driver definition (and even if it ain't!), in order to save everyone some stress in a classroom situation BE SURE to use that TEST CONNECTION Button! The first time 'round, be prepared to wait a handful of seconds for that "Ping Succeeded!" message...

Happy 5th of July!

-Rn

[ add comment ] ( 2162 views )   |  permalink  |  related link
Java Serialization: Understanding the 'Transient' Keyword 
Created for the benefit of a class we are teaching this week.

I thought we might share the results with everyone else.

Of course, the first thing to remember is that - in order to avoid R&D problems when rolling most objects - that most of us will want to explicitly use a serialVersionUID:

private final static long serialVersionUID = 101L;


Disjoint Usage


Next, here is what happens when we use the transient keyword on unrelated classes:


package com.research;

import java.io.BufferedOutputStream;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import java.io.Serializable;

public class Controller {

public static class UserData01
implements Serializable {
private static final long serialVersionUID = 1L;
public String sName = this.getClass().getName();
public String sPassword = "Default_Password";
}

public static class UserData02
implements Serializable {
private static final long serialVersionUID = 2L;
public String sName = this.getClass().getName();
public transient String sPassword = "Default Password";
}

public static String FILE_NAME = "output.ser";

public static void main(String[] args)
throws IOException, ClassNotFoundException {

// STEP: Create stream & save the data
FileOutputStream fos = new FileOutputStream(FILE_NAME);
BufferedOutputStream bos = new BufferedOutputStream(fos);
ObjectOutputStream oos = new ObjectOutputStream(bos);
UserData01 refA = new UserData01();
refA.sPassword = "zPassword";
Report("PRE Solid - 01", refA);
oos.writeObject(refA);
UserData02 refB = new UserData02();
refB.sPassword = "zPassword";
Report("PRE Transient - 02", refB);
oos.writeObject(refB);
oos.flush();
oos.close();

// STEP: Create stream & read the data
FileInputStream fis = new FileInputStream(FILE_NAME);
ObjectInputStream ois = new ObjectInputStream(fis);
UserData01 ref1 = (UserData01) ois.readObject();
Report("POST Solid - 01", ref1);
UserData02 ref2 = (UserData02) ois.readObject();
Report("POST Transient - 02", ref2);
ois.close();
}

private static void Report(String sPrefix, UserData01 ref) {
System.out.printf("=== %s ===\n", sPrefix);
System.out.println(ref.sName);
System.out.println(ref.sPassword);
System.out.println("=====");
}

private static void Report(String sPrefix, UserData02 ref) {
System.out.printf("=== %s ===\n", sPrefix);
System.out.println(ref.sName);
System.out.println(ref.sPassword);
System.out.println("=====");
}
}


The code pretty much says it all - simply focus on where that transient keyword shows-up in the UserData02 class. Note that anything marked as being transient is never saved to the stream:


=== PRE Solid - 01 ===
com.research.UserData01
zPassword
=====
=== PRE Transient - 02 ===
com.research.UserData02
zPassword
=====
=== POST Solid - 01 ===
com.research.UserData01
zPassword
=====
=== POST Transient - 02 ===
com.research.UserData02
null
=====


Witness that a null showed-up where the string would otherwise have been, despite any default assignment. Nothing unexpected there.

Transient Parent


What happens whenever our parent class has a attribute that is marked transient, is just as predictable:


public static class UserData01 implements Serializable {
private static final long serialVersionUID = 1L;
public String sName = this.getClass().getName();
public transient String sPassword = "Default_Password";
}

public static class UserData02
extends UserData01 implements Serializable {
private static final long serialVersionUID = 2L;
public String sPassword = "Default Password";
}


-That null just trades places:


=== PRE Solid - 01 ===
com.research.Controller$UserData01
zPassword
=====
=== PRE Transient - 02 ===
com.research.Controller$UserData02
zPassword
=====
=== POST Solid - 01 ===
com.research.Controller$UserData01
null
=====
=== POST Transient - 02 ===
com.research.Controller$UserData02
zPassword
=====


Transient Children


Finally, and also just as expected, the null migrates when a child starts messin' with transient. The null follows the keyword:


=== PRE Solid - 01 ===
com.research.Controller$UserData01
zPassword
=====
=== PRE Transient - 02 ===
com.research.Controller$UserData02
zPassword
=====
=== POST Solid - 01 ===
com.research.Controller$UserData01
zPassword
=====
=== POST Transient - 02 ===
com.research.Controller$UserData02
null
=====



Polymorphic Surprise!


But here is some fun: If we UPCAST to our base type, something strange happens - thru the miracle of Java Polymorphism (?), than NULL will go-away.

Doubtfull? Then just comment out the child-printer:

/*
private static void Report(String sPrefix, UserData02 ref) {
System.out.printf("=== %s ===\n", sPrefix);
System.out.println(ref.sName);
System.out.println(ref.sPassword);
System.out.println("=====");
}*/


After re-running the previous 'transient child' scenario, the results become a surprising:


=== PRE Solid - 01 ===
com.research.Controller$UserData01
zPassword
=====
=== PRE Transient - 02 ===
com.research.Controller$UserData02
Default_Password
=====
=== POST Solid - 01 ===
com.research.Controller$UserData01
zPassword
=====
=== POST Transient - 02 ===
com.research.Controller$UserData02
Default_Password
=====


Interestingly enough, our newly-missing null has nothing to do with the transient keyword here. To prove it, simply remove the same from the child class, and the result will look the same.

Conclusion


Hence whilst our have member functions operate properly during the UP casting operation, our member ATTRIBUTES will do nothing of the sort. 'Kinda reminds me of the C/C++ VTABLE.

So perhaps the moral of the story is to always protect + wrapper class attributes with 'getters and 'setters. --Either way, this new nano-morphic observation has little to do with the transient parent and / or child attributes. --It is just plain good-'ol OO.

Enjoy,

-Rn

p.s. Just to complete the truth-table, here is what happens when we put that transient keyword into the parent, but have none in the child:


public static class UserData01 implements Serializable {
private static final long serialVersionUID = 1L;
public String sName = this.getClass().getName();
public transient String sPassword = "Default_Password";
}

public static class UserData02
extends UserData01 implements Serializable {
private static final long serialVersionUID = 2L;
public String sPassword = "Default Password";
}

=== PRE Solid - 01 ===
com.research.Controller$UserData01
zPassword
=====
=== PRE Transient - 02 ===
com.research.Controller$UserData02
Default_Password
=====
=== POST Solid - 01 ===
com.research.Controller$UserData01
null
=====
=== POST Transient - 02 ===
com.research.Controller$UserData02
null
=====


Of course, after restoring our polymorphic Report()er for the child, once again we will see:

=== PRE Solid - 01 ===
com.research.Controller$UserData01
zPassword
=====
=== PRE Transient - 02 ===
com.research.Controller$UserData02
zPassword
=====
=== POST Solid - 01 ===
com.research.Controller$UserData01
null
=====
=== POST Transient - 02 ===
com.research.Controller$UserData02
zPassword
=====

-Almost interesting... wot?

=)

[ add comment ] ( 2140 views )   |  permalink

<<First <Back | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | Next> Last>>