Smart Matchboxes before Smart Dust
Went to a seminar today in the ICT building titled 'Java on Wireless Sensor Devices' given by Cristina Cifuentes (of Sun Labs), and now an Adjunct Professor at The University of Queensland. It was about the new 'SunSPOT' technology that Sun Microsystems has just released in a retail kit form, in the US. See the Sun SPOT (Small Programmable Object Technology) in figure 1 - they are about 10% larger than a matchbox.
Image #1 : Anatomy of a SunSPOT Device (courtesy of www.sunspotworld.com).
These things are really aimed for somebody like me - i.e. I don't want to have to dabble in low level C code just to do things between the DigitalFriend and wireless sensors, I want to be able to do it in Java, in object-oriented programming at the very least, but probably in agent-oriented programming. Its not that I don't know C, I used to do training courses for it in the late 80's, it just feels like such a retrograde step - it would be like going back to riding an old bicycle in the rain after driving an Ford XR6 in the sun.
Cristina talked about 'programmable things', about 'programming the world', about earlier (non-Java) sensor projects, including: the Smart Dust project - where they eventually aim to do this stuff on a device the size of a grain of sand (i.e. currently hyperthetical, see: en.wikipedia.org/wiki/Smartdust); Berkley Mote (8-bit processor); and the Intel Mote technology. SUN saw a market for mid level programmer-friendly devices based on 32bit processors for WSNs (wireless sensor networks) capable of running their Java technology - "for research and development purposes", before the smaller devices are widely available. Hence the matchbox-sized 'bit of dust' in figure 1, rather than the cubic millimeter version. The SunSPOT has built-in radio/wireless 802.15.4 antenna, 3-axis (x,y,z) accelerometer (for tracking the device in 3D), temperature sensor, light sensor, 8 tri-colour LEDs (i.e. thats an 8x1 pixel screen with 3 colours - not much chop!), 6 analog inputs for other external sensor input, 2 switches/buttons. The processor is a 180MHz 32bit ARM with 512K RAM / 4M Flash. It is "Java on bare metal", is programmer-friendly (can use any standard Java IDE hence high-level debugging on your desktop Mac, Windows, Linux, Unix box), runs multiple programs (multiple 'isolates'), allows over-the-air deployment. Sun Microsystems sees markets in: Robotics, Art, Toys, Personal Electronics, programming the world (i.e. what researchers call ubiquitous and pervasive computing) ... mmm, I've got to get one of these integrated with a DigitalFriend, to program the individual's personal world, things around the home.
When asked about battery life, she said it has 3 modes: deep sleep, shallow sleep, and awake. In deep sleep it will last about 950 days(!), but in fully awake mode all day, its good for about one day. Wireless range is 90 to 30 Metres (variation must depend on obstacles?). Its not Bluetooth.
She mentioned several projects that are using sensor networks in useful ways - on the San Francisco bridge, where they measure structural parameters (e.g. stress and strain), environmental projects including one used to track the spread of cane toads (rampant introduced pests) in Australia... if they are putting SunSPOTs on the back of toads, it will kill em one way or the other - if the payload doesn't wear them down, at $550 US for two SunSPOTs, people will be tracking them down for the devices and removing the toad:)
SQL Engine is now standard in Java
Having an SQL engine, written in Java, embedded in Java is an interesting addition to the language. i.e. JDK 6 has the pure Java RDBMS 'Java DB' bundled with the standard JDK. It turns out being a Sun-badged version of Apache Derby, which is great as I can develop with Derby in JDK 4 (i.e. JDK 1.4) which is more broadly supported than JDK 5 and 6, before moving to JDK6.
Its interesting in the DBMS and language marketplace at so many levels: Sun has never owned/marketed a Relational DBMS (DataBase Management System) - they seemed to belong to the school of thought that believed that OODBMS was going to surplant RBMS in the mid-1990s popularised by the OOP people - which has just not happened; JDK5 and JDK6 - rapid-fire JDK updates - are related to Sun's effort in trying to keep up with Microsoft's offering on the C# language front, therefore free RDBMS capability 'in the language' is now standard fare - so you can see why Oracle Inc is diversifying rapidly through acquisition; Web 2.0 has started a fire in the broader interest in RDBMS; IBM (who donated Derby to the Apache project) clearly see this move as strategic in terms of their own DBMS (DB2) flagship on the server, against MySQL (which is written in the C language - therefore, more portability issues than a pure java engine) at the very least, and probably against Oracle too (which has Java embbed in their DBMS as an internal language these days); ...
Anyway, I ported over my simplest one-file example database in MySQL accessed from Java via JDBC, to Apache Derby accessed from Java via JDBC, to see what was involved, before any other commitment to Derby. The application is a GIFT LIST, whereby a birthday, wedding or similar event organiser, can put up a wishlist of gifts that invited guests can peruse and tick off, if they intend to buy one of them (to avoid duplication by other guests), independent of gift store.
Even in such a very small example, there's a few differences in the SQL between MySQL and Derby, as follows:
The following is the modified 'gifts.sql' which I did first in MySQL:
Heres the old MySQL version:
CREATE TABLE GIFT_LIST (
gift_id int AUTO_INCREMENT,
gift_name varchar(255) NOT NULL,
gift_comment varchar(255) NULL,
purchase_status ENUM('Available', 'Pending','Purchased'),
last_modification datetime NULL,
PRIMARY KEY (gift_id)
) TYPE = InnoDB;
* AUTO_INCREMENT becomes GENERATED ALWAYS AS IDENTITY (START WITH 1, INCREMENT BY 1)
* There is no ENUM type, so 'last_modification' was turned into a varchar(10)
* There is a NOT NULL, but no need for a NULL (i.e. its the opposite of NOT NULL).
* There is no DATETIME type (there is a DATE and a TIME), but there is a TIMESTAMP which
combines date and time in the one variable, so I made 'last_modification' a timestamp.
* I dropped the TYPE = InnoDB (this is an engine that gives 'referential integrity' to MySQL, the owning company of which, was recently bought by Oracle Inc - in their own strategic move against the MySQL people).
Here's the new version:
CREATE TABLE GIFT_LIST (
gift_id int not null GENERATED ALWAYS AS IDENTITY (START WITH 1, INCREMENT BY 1),
gift_name varchar(255) NOT NULL,
PRIMARY KEY (gift_id)
One of the great things that Derby adds to standard Java is that it gives you an interactive SQL tool (called simply 'ij') which therefore allows you to create tables and insert data into tables, independently of the java code. So, you can create the necessary 'jump start' data of certain Java applications, via SQL in 'ij'. Its a productivity boost, now gained without committing to anybody elses DBMS (i.e. MS SQL Server, Oracle, DB2, MySQL, etc). It means that POJOs (Plain Old Java Objects) are no longer the only game in town for such persistence in 100% java, in the standard JDK. The tool is in the frameworks dir, and on a Mac, it is started via a Unix batch file (there's an equivalent .bat file for MS Windows):
The 'ij' tool is an SQL interpreter command-line environment.
Its here in my case:
Its a script file, so to make it work, go to its dir in a command shell then enter: ./ij.ksh
Once within ij, you connect to a database called 'gifts' like this (this is equivalent of USE in MySQL):
ij> connect 'jdbc:derby:../../../db/gifts';
OR (in two parts) ...
ij> protocol 'jdbc:derby:';
ij> connect '../../../db/gifts';
I created the gifts database via a createGiftDB.java file, but it turns out I could have created one
within ij itself, as follows:
ij> connect 'gifts;create=true'; (this is equivalent of CREATE DATABASE GIFTS in MySQL)
The RUN command in ij, gives you access to SQL script files in its local dir. e.g.
ij> run 'gifts.sql';
To make the INSERT records within an .sql script file from MySQL, work in ij, I needed two small changes:
* Deleted the C-style comments from the top of the file. (Comments start with -- in ij)
* The TIMESTAMP variable needed data that included at least hour after the date, so
I added hr:mm:ss to yyyy:mm:dd.
The java code that accesses the gift database in Derby is little different from the way it was when accessing it within MySQL. i.e. Accessing SQL data via JDBC in Java, really makes things portable. As per above, any porting issues are largely between the different dialects of SQL - even though they are meant to be standard, things like data type do vary between DBMSs.