Building Flexible Connected Devices Using JavaTM

1
Building Flexible Connected Devices Using Java(TM)
Chris Gray /K/ Embedded Java Solutions http//www
.k-embedded-java.com
2

• Introduction
• Not just a pretty face
• Java suitability for connected embedded devices
• Embedded Java pitfalls, and how to avoid them

3
Introducing /K/

• Founded 2003 by Chris Gray
• "Putting Java where it wants to be"
• Consulting services
• Mika(TM) platform for Java, based on the Wonka
  code-base
• Wonka is open-source (BSD licence), Mika
  contains code proprietary to /k/

4
Chris Gray

• Working with embedded software since 1978
• Bradford University, Plessey, Alcatel, Acunia
• Leader of Wonka project at Acunia, 1998-2003

5
Java - not just for GUIs

• Java often comes into the discussion when a
  device has a bitmapped display / GUI - but Java
  has other uses, also in "headless" devices
• Remote ("web") UI and/or device management
• Device customisation, programmability
• Portable components, "plug-ins"
• Intelligent networking

6
Remote UI

• Run Java web server on embedded device
• Send applet to server, applet communicates with
  servlet
• Applet does all the visualisation, embedded
  device only does the 0's and 1's

7
Remote UI Example

• Embedded Java web server running on ARM7 SoC
  (NetSilicon 7520)
• Communication applet lt-gt servlet via XML-RPC
• Applet/servlet automatically generated using
  ErgoVU visual tool

8
Remote Device Management

• Overlaps with remote UI ("administrator mode")
• Also extends to software component management
  (install/update/uninstall, start/stop)
• Java has right blend of safety and convenience
  (scripting languages are unsafe, traditional
  compiled languages are inconvenient)
• Available frameworks such as Xlet, OSGi

9
Device Customisation

• Customers are awkward - they want things doing
  their way
• Telecomms provider wants own features in
  handset/PABX
• WiFi hot spot requirements for hotel chain,
  airport, TelCo
• Automotive, etc. -service branding
• Core device API can be in native code,
  applications in Java

10
Device Programmability

• Let the user (or middleman/installer) add or
  adapt functionality
• Java's type safety, fine-grained access control,
  automatic garbage collection are there to save
  the user from herself
• Combine with remote management

11
Portable apps, plug-ins

• Can develop applications which work on a range of
  products, despite different hardware/OS/etc.
• Possibility of 3rd-party/aftermarket apps
• Java strengths
• Type safety via "class implements interface"
• Application-defined class loaders, access control
• Availability of frameworks e.g. OSGi

12
Intelligent Networking

• Devices which "discover" each other can exchange
  not only data but also code
• Applet/servlet is simple example (embedded web
  server "discovers" browser), more is possible
  when bidirectional/peer-to-peer
• Some techniques already established (e.g. JINI),
  more emerging as wireless and self-configuring
  networks become more common

13
Java suitability (1)

• Safety (security, reliability) managed code, no
  free pointers, end-to-end type/access safety,
  automatic garbage collection, fine-grained access
  control
• Good facilities for abstraction, e.g.
  interface/class distinction
• Built-in threading, synchronisation
• Rich libraries, no more own-rolled hashtables

14
Java suitability (2)

• User-defined class loaders facilitate downloading
  and namespace management
• Bytecode tends to be rather small compared to
  native apps
• Mature, well-known language
• Downside VM is a biggish piece of software,
  mostly-interpreted apps will run slower than
  native. No free lunch!

15
Interfaces are cool

• Class C implements interface I if it has an
  implementation for each abstract method in I
  (e.g. any class which has a method run()
  implements java.lang.Runnable)
• I can be an industry-wide standard, C could be
  one vendor's implementation, fetched from e.g.
  Web-site
• Can be used to implement plug play, dynamically
  configurable systems, ...

16
Class loaders are cool

• Can upload code just as easily as data, without
  compromising security
• Code could be auto-generated (cf. ErgoVU)
• Can be used to unload classes and load new ones
  with same name (use with caution!)
• Combine with interfaces, reflection to make
  powerful frameworks, e.g. OSGi

17
Java pitfalls - 1

• No magic bullet - Java will not solve all your
  problems
• Problem 1 is the gulf between embedded designers
  (who know nothing about Java) and Java
  programmers who don't understand embedded
• Embedded design houses need to recruit / train
  Java programmers
• Get help from a specialist firm (such as /k/).

18
Java pitfalls - 2

• Don't write 200 KLOC for Java 1.7 and only then
  ask how it's going to run on an 8051. Get
  something working, take measurements, make
  experiments. Use Java well, so you can easily try
  different representations / algorithms for
  specific components.

19
Java pitfalls - 3

• Avoid excessive object creation -it's seductively
  easy, but eats up CPU time.
• Use the standard libraries - probably they're
  already (somewhat) optimised.
• Real-life example - an application-defined class
  loader was creating JarFile objects each time
  (open the file, read the index ...). Changing to
  use java.net.URLClassLoader was 20x faster.

20
Java pitfalls - 4

• Use reflection wisely - cache result of class /
  method / field lookups.
• Excessive synchronisation not only imposes
  overhead, it can and will cause lock-ups.
• Write idiomatic Java, not badly-translated C.
• Don't use 1-element arrays as call-by-location
• Don't use java.lang.reflect.Method as a function
  pointer

21
Compatibility issues

• Compatibility across hardware platforms is the
  essence of Java, BUT class libraries on embedded
  device will not be identical to those on server.
• J2ME CDC is effectively a subset of J2SE (desktop
  JDK). J2ME CLDC is a lot different, need special
  development environment.
• Different vendor implementations mostly work well
  together, but serialisation / RMI is a PITA.

22
Contact Infok-info_at_kiffer.be. /k/ Embedded
Java SolutionsBredestraat 42000
AntwerpenBelgium Tel. [phone]Fax. 32
3216 2123 Mobile [phone]http//www.k-e
mbedded-java.com