Update 715/13: Added a note on target platforms.
A key feature of Java ME Embedded is the ability for developers to access peripheral devices directly from Java application code. This significantly simplifies development effort because the device-related code is much easier to write, portable across platforms, and there is no need for complicated native code development and integration.
The latest Device Access API is available in Java ME Embedded 3.3, and already supports a host of features, interfaces, and peripherals such as GPIO pins, I2C and SPI busses, serial communication and modems, ADC and DAC converters, pulse counters, and more.
For Java ME 8, we plan to enhance the Device Access API even further by including support for the new Java ME 8 language features aligned with Java SE 8 (such as Generics, Annotations, Try-with-Resources, and so on), adding a few more popular functions (pulse-width-modulation (PWM) output and more), and making the API available as a standard for Java ME and Java SE.
Because hardware integration is such a broad and potentially complex topic we would like to hear from developers: Does the Device Access API meet your needs? Do you see any potential pitfalls and shortcomings? To this effect, we just published the javadocs for the “Device Access API Proposal for Java ME 8”. Please have a look and give us your feedback, either as a comment to this blog entry, or via email.
Cheers,
— Terrence
Across the Universe 
23 comments
Comments feed for this article
07/14/2013 at 16:28
Davide
I was a JavaME addicted when JavaME was used on mobile phones.
Now I don’t have understood where JavaME will be used, but I continue to follow you to try to see how this platform will evolve.
07/14/2013 at 16:36
terrencebarr
Java ME is an ideal platform for a range of small to mid-size embedded devices, and we have been adding a range of dedicated features for that – such as the Device Access API. Stay tuned for more at JavaOne SF in Sept.
07/14/2013 at 17:55
ove nordstrom
I was also JavaME addicted when JavaME was used on mobile phones. Now I waiting and waiting, I hope for some good news and yes I am going to this years JavaOne it would be great if something happen!
07/14/2013 at 20:32
terrencebarr
Hi Ove,
A lot of things have already happened in the last 12 months. Java ME Embedded has shipped several releases, commercial devices are appearing, and the embedded space is heating up. Check my past blog postings and watch this space.
Cheers,
— Terrence
07/15/2013 at 09:16
Ove Nordström
ok I will do that, I have last to years more fokus on Android developing, before that it was JavaMe and Qt. Now I have plan to focus more on developing for Sailfish OS ( Jhttps://sailfishos.org/ ) from Jolla. It would be great to also works more with JavaME, when you talk about commercial devices is it phones also?
07/15/2013 at 17:24
Patrick
I can see where Java SE could use such an interface. I work with systems that use many native interfaces, which introduces many problems. This ‘Device Access API’ might have utility where the ’embedded system’ is a server-class machine. For instance, RTU (Remote Terminal Unit) in electrical substations are being replaced with larger computers running Java SE for other needs. Native interfaces have to be created when direct device access is needed…
07/15/2013 at 18:38
m1k0
” new Java ME 8 language features aligned with Java SE 8 (such as Generics, Annotations, Try-with-Resources, and so on)” … Lamda?
07/16/2013 at 05:30
terrencebarr
Hi,
Java ME 8 will not contain direct support for Lambda expressions – typical use cases for Lambdas are outside the scope of a small embedded platform like ME 8. You can follow along the CLDC 8 JSR for more details: http://jcp.org/en/jsr/detail?id=360
07/15/2013 at 20:49
pjmlp
We used to do J2ME when it mattered in the mobile space, mainly on Symbian mobiles. Now we are back to C++, with a look on how Go, Rust and D will evolve on this space.
07/16/2013 at 05:34
terrencebarr
With Java ME you get much more than a language. You get an application platform that addresses key pain points of embedded development, such as platform dependencies, cross-compilation, architecture differences, lack of security model, and proprietary tools and libraries. Java enables you to deliver feature-rich, robust applications with less effort and a shorter time-to-market.
07/16/2013 at 10:53
pjmlp
Sorry but that reads like enterprise marketing speak to me.
09/02/2013 at 14:51
Hank Bruning
Is the “Device API” going to be available with Java SE ? We need to talk to the I2C in servers, network switches, RAID arrays etc that are used in Data Centers.
09/02/2013 at 14:58
terrencebarr
Yes, the plan is to make it available for Java SE as well. Would be interested to understand more of your use cases.
09/02/2013 at 15:29
Hank Bruning
Would it be possible to add a new Exception to the I2CDevice.write methods. The Exception should be thrown when the I2C slave device being written to does not response to write of the bytes as documented in the
e I2C-bus specification http://www.nxp.com/documents/user_manual/UM10204.pdf section 3.1.6 Acknowledge (ACK) and Not Acknowledge (NACK). Each of the numbered items in that section should be available as a java enum.
The use case is the IPMI and ATCA implementations cited in the I2C spec and implemented by our Java IPMI library Hemi.
http://www.jblade.com/products/hemi/HemiOverview.jsf.
http://www.jblade.com/JbDoc2/products/retuli/ipmiDC/doc/programmers/RetuliIpmiCXProgrammersGuideOverview.html
09/02/2013 at 21:29
terrencebarr
Hank,
I will forward your comment to the spec leads for consideration.
Thanks,
— Terrence
10/13/2013 at 10:16
Thierry
Hello Hank,
Sorry for the delayed reply. Thanks for the input. Currently we are not making any particular distinction between these different conditions. Those that constitute an error are currently reported as an IOException. As per your proposal, we may introduce a new exception (subclass of IOException) to account for these conditions. Note though that in certain environments some drivers may not propagate these conditions and the generic IOException will be thrown instead.
10/20/2013 at 19:54
Thierry
Hank,
As it turns out , It is impossible to distinguish between the following conditions: receiver not ready, receiver full or receiver not understanding the data/command. Finally the 5th reason does not apply as we are only supporting the master mode. So basically if we were to define such an exception, it would have only 2 reason codes: notReadyOrNotUnderstandingOrFull and NotFound…. Unless I’m missing something it does not provide a lot of additional value…
04/26/2014 at 10:43
RampantBadger
Looking forward to Java SE embedded having Device Access API as
not sure how i would make my own Nest type embedded device easily that needs a JavaFX Interface and peripheral interaction without rolling my own peripheral libraries.
04/27/2014 at 23:13
terrencebarr
Right, talking to peripherals like that is a key use case for Device I/O (as it is now renamed) on Java SE.
05/15/2014 at 08:01
RampantBadger
Cool, looking forward to it, does anyone have a hint of when device I/O will be available in SE on Linux?
05/17/2014 at 14:20
terrencebarr
The Device I/O project in OpenJDK has been approved, and I expect code to be available soon. Please monitor the Device I/O project to stay on top.
05/18/2014 at 08:29
RampantBadger
many thanks 🙂
05/18/2014 at 06:38
RampantBadger
many thanks 🙂