X

This Blog covers the latest Java technology for small devices and security in the IoT, mobile, ID and Payment

Recent Posts

Java Card

Unveiling Java Card 3.1: Applet Deployment Update

In anticipation to the upcoming Java Card 3.1 launch, Oracle will publish a series of blog articles outlining some of the key features introduced in this release, and their applications in traditional and new markets. This week, the focus is on the new CAP file format and applet deployment model.  Final touches are being made on version 3.1 of the Java Card Platform. This release brings an unprecedented level of new features, for existing markets but also to drive new IoT use cases. This post covers on one of key change in Java Card 3.1: the Applet deployment model. The base unit in the Java Card deployment model is the Java Card Converted Applet (CAP) file. A CAP file contains all of the classes and interfaces defined in a Java Card Applet or Library. CAP files are installed on a Java Card product either at manufacturing, or once deployed in the field by using a Trusted Service Manager (TSM). Until now, a CAP file contained only one Java package and was limited to 64Kb. In some cases this was leading to Applet design constraints, specifically for the deployment of large Applets where the remote management complexity increases. To circumvent those issues, Java Card 3.1 brings three changes to the CAP file format in order to facilitate Applet design and deployment: CAP file can now contain multiple Java packages, which can be: Applet packages only Library packages only a combination of Applet and Library packages. This brings a reduction in the number of CAP files that needs to be deployed by a TSM. It also eliminates the constraints and costs that were induced by having one Java package per CAP file, as in previous versions. Java packages visibility can now be declared as private, in addition to public and shared. It allows for a better design and for finer-grained access control and visibility, since a private package is private to a given Applet and therefore cannot be accessed by other Applets. Public and shared packages on the other hand can be accessed among the different Applets available on the platform. Large CAP file sizes (>64KB) can now be deployed. This is mainly a consequence of the two previous points, and the new extended CAP file can reach up to 8Mb. This covers the vast majority of usage scenarios on the resource - constrained chips used in Java Card products. Even in traditional markets such as payment, some Applets were sometimes getting close to the limit. If we take the example of an IoT Applet that is using two Libraries for a dedicated storage hierarchy, and a dedicated protocol to access a given IoT Cloud service: we have 3 Java packages. If we consider that those packages implementations require themselves utility packages such as asn.1 parsing and json parsing, that are generic and can be shared among different Applets on a same platform: we reach a total of 5 Java packages. Without using the extended CAP file format, this would lead to 5 CAP files needing to be deployed. However thanks to the new format, this number can be reduced to 1 CAP file or any other combination that makes sense. In the figure below, we took a combination of 2 CAP files. Deployment complexity is greatly reduced. Besides, access control is also better addressed since the Library packages (protocol and storage) dedicated to the IoT Applet are now only accessible by the IoT Applet itself. The following figure illustrates this. As we can see, the extended CAP file introduced in Java Card 3.1 brings much more than an increase in file size beyond 64KB of code and data. It allows for a better Applet design and deployment. Applet functionality can be split into different Java packages, making the development of a Java Card Applet a step closer to Java SE application programming. And since multiple Java packages can be part of the same CAP file, deployment logistic such are Library dependencies management are greatly simplified, with the related cost benefit. Java packages can now be deployed in an atomic manner, where the complete payload of an Applet is contained in a single CAP file avoiding versioning and deployment complexity. Extended CAP files are one of the exciting new features in Java Card 3.1. We will continue to detail the contents of this release in future posts. Stay tuned...

In anticipation to the upcoming Java Card 3.1 launch, Oracle will publish a series of blog articles outlining some of the key features introduced in this release, and their applications in traditional...

Java Card

Back to Basis: IoT needs Certification

I have been a little bit surprised to hear during travels and events, or even within private meetings, that security certification for IoT devices is too expensive and in a way not a strict business requirement. Such statements can be refuted by basic economics, and explained by simple sociological considerations.  At its very core, certification is a substitute or at least a complement for trust in business relationships. Certification brings trust so that an insurance company can pay the customer back when a credit card has been stolen. Certification brings trust so that an operator can allow a connection to its network through a SIM card. Without certification, there is no established and documented trust. Without trust no one wants to be liable for a given business risk. In the end, the cost of certification is far less than the volume of business it enables and the margins that are derived from it. IoT devices generally do not depart from this rule. There are low value applications for IoT devices and services: a T-shirt that flashes messages from your mobile phone may not need security or certification (although why not…). But as soon as IoT is considered a technology that unlocks insights for customers and enterprises - by connecting sensors to business applications - a certified root of trust is mandatory. Digital medicine, water networks, fleet management applications all rely on such insights, and IoT unlocks new value and tremendous business opportunities in those markets. If IoT sensors, devices and gateways do not come with certified security, then the chain of trust cannot be established to your applications. This is not an acceptable outcome for business operations today, and there is no reason to think that companies will lower the bar as they bring IoT data into their processes. Overall – there is a relevant and challenging discussion to be had about the ease and reusability of security certification for IoT products. The costs of certification need to be made clear and optimized – through the availability of protection profiles and security targets, through modular certification in particular. But the basic requirement for certification cannot be ignored unless one is ready to jeopardize the existing trust principles that hold businesses together. At the coming Global Platform Seminar in Beijing, Oracle will demonstrate how the Oracle Java Card™ platform powers certified secure elements and certified applications,  allows reuse across IoT Device Edge products,  and bringing trust to IoT.

I have been a little bit surprised to hear during travels and events, or even within private meetings, that security certification for IoT devices is too expensive and in a way not a strict business...

Java Card

Java Card Protection Profile 3.0.5 available

Announcing Java Card Protection Profile 3.0.5   (Updated 09/05/18 - Closed Configuration Available) The Java Card Protection Profile version 3.0.5 has been certified and published. As opposed to the previous versions of the Protection Profile which were certified and published under the French Scheme by Agence Nationale de la Sécurité des Systèmes d’Information (ANSSI), this version of the Protection Profile has been certified and published under the German Scheme by Bundesamt für Sicherheit in der Informationstechnik (BSI). The Java Card  Protection Profile can be used to certify Java Card platforms to Common Criteria EAL4+ level. It relies on CC version 3.1 revision 5. The Java Card Protection Profile version 3.0.5, is aligned with the latest Java Card specifications version 3.0.5, but can also be used to certify products based on versions 2.2, 2.2.1, 2.2.2, 3.0.1 and 3.0.4 of the Java Card specifications. It supersedes the previously released versions of the Protection Profile.  What is the Java Card Protection Profile ? The Java Card Protection Profile provides a modular set of security requirements designed specifically for the characteristics of the Java Card platform. It offers a precise description of the Java Card System, background and possible environments for risk analysis, and describes the division of duties and assignment of responsibilities among the involved actors (physical and IT components) required for definition of security policies. Furthermore it defines the risks and assets to enable creation of Security Targets.  Its goal is to reduce the time and cost for developers of Java Card-based products to complete security evaluations under the Common Criteria for IT Security Evaluation. This work is part of Oracle's Global Initiative on Common Criteria (CC).  The Java Card Protection Profile defines a set of security requirements for the Java Card Runtime Environment, the Java Card Virtual Machine, the Java Card API Framework, and the on-card Installer components. It provides guidelines to develop a secure Java Card platform and obtain high-level security certifications. The design strategy behind Java Card Protection Profiles represents a breakthrough in the world of security evaluations, as it specifically accommodates the flexible, modular, and open characteristics of Java Card technology. In particular, it is intended to complement existing protection profiles available for Java Card technology-based smart cards and secure elements. Protection Profile Configurations  The Java Card Protection Profile comes in two configurations:  The Open Configuration Protection Profile can be used to certify Java Card platforms that allow post-issuance downloading of applications. It has been certified by BSI under reference BSI-CC-PP-0099-2017. Access the Java Card Open Configuration Protection Profile Certification report from the BSI web site. The Closed Configuration Protection Profile can be used to certify products that do not support post-issuance downloading of applications. It has been certified by BSI under reference BSI-CC-PP-0101-2018.  Access the Java Card Closed Configuration Protection Profile Certification report from the BSI web site. More Information Download Java Card Protection Profile v3.0.5 Open Configuration from OTN Learn about the Common Criteria for Information Technology Security Evaluation 

Announcing Java Card Protection Profile 3.0.5   (Updated 09/05/18 - Closed Configuration Available) The Java Card Protection Profile version 3.0.5 has been certified and published. As opposed to the...

Java Card

Java Card Development Kit 3.0.5u2 available

We are pleased to announce the availability of the latest Java Card Development Kit update. Version 3.0.5u2 is a maintenance release of Oracle's environment for the development and testing of Java Card applications. In addition to a variety of optimisations and bug fixes, it contains new tool chain enhancements to enforce consistency between verified and loaded content. There are no changes to the Java Card Specification in this release. New Verification option The Off-Card Verifier provides functionality for verifying CAP files and export files. When applied to the set of CAP files that will reside on a Java Card-compliant smart card and the set of export files used to construct those CAP files, the Off-Card Verifier provides the means to assert that the content of the smart card has been verified. Verification determines whether CAP and export files conform to the Java Card Virtual Machine specification, performing structural checks and ensuring language conformance at the bytecode level. As such, it is an enforcer of the Java Card interoperability binary standard. The set of conformance checks provides that such files do not attempt to compromise the integrity of a Java Card virtual machine implementation, and hence other applets. In Java Card 3.0.5u2, the Off-Card Verifier has been enhanced to ensure the integrity of the CAP file until it is downloaded on a Java Card-based device. For that purpose, the Verifier can now compute and output hash values for each of the CAP file components. A CAP file Loader computing the hash values for each of the required components can then verify them against the hash values produced by the Verifier to assert the integrity of the CAP file being loaded on the card.  In Oracle's Java Card Development Kit, the scriptgen tool has also been modified to perform the hash computation and comparison before generating the download script for a CAP file. For more information on the verification process and the updated verifier tool in the Java Card Development Kit 3.0.5u2, please refer to the User Guide Other 3.0.5u2 changes. In addition to the verifier changes, Java Card Development Kit 3.0.5u2 (see Release Notes) includes additional improvements :  Maskgen tool can now include external CAP files in the mask (instead of only JCA files) Eclipse Neon/Oxygen compatibility has been added Misc bug fixes since the 3.0.5u1 release The Java Card Specification release notes have also been updated to include several clarifications and errata in the 3.0.5 specifications. The specifications themselves are unchanged. Finally, Oracle commercial customers will benefit from an updated version of the Java Card Technology Compatibility Kit (TCK). ​About the Java Card Development Kit The Java Card Development Kit includes a complete, standalone development environment in which applications written for the Java Card platform can be developed and tested. It provides support for the latest Java Card 3.0.5 specifications. Information about the Java Card Development Kit can be found on the OTN Java Card web site.

We are pleased to announce the availability of the latest Java Card Development Kit update. Version 3.0.5u2 is a maintenance release of Oracle's environment for the development and testing of Java...

Java Card

Java Card Forum 20 years anniversary

A few weeks ago, the Java Card Forum (JCF) held an event in Munich to celebrate the 20 years of its creation. Founding companies were joined by more recent members of the organisation in a celebration of two decades of technical and commercial achievement. It was also an opportunity to reflect on how far the technology had gone over this period.   Java Card was introduced in 1996. It was a pioneering concept for the time (the first very small Java framework—before Java ME was introduced), and was also very incomplete (no VM specification and only a basic cryptography framework). Subsequent versions would alter the architecture and augment the APIs, to the point that the modern Java Card framework would be unrecognizable to users of that first version.   A key contributor and promotor of that evolution has been the Java Card Forum. The JCF was formed shortly after the initial release of Java Card as "a collaboration of companies from the smart card, secure operating system, and secure silicon industry, working together to promote and develop Java as the preferred programming language for multi-application smart cards and secure devices”.   JCF provides recommendations to Oracle for the evolution of the Java Card specifications. It has been instrumental bringing key innovations to the platform. After version 2.0 started specifying the Java Card VM and Runtime conditions, version 2.1 brought in an interoperable file format. Version 2.2 brought in alignment with ETSI and enabled contactless smart cards to be supported. Version 3.0 introduced 2 variants of the specification (Classic and Connected), as well as broader cryptography support. More recent releases have continued to iteratively enhance the platform, up to the current version Java Card 3.0.5.   JCF is now working with Oracle toward the definition of a new version, 3.1, that will enable new use cases in the IoT space. It is slated for release in 2018.   More on that soon !  

A few weeks ago, the Java Card Forum (JCF) held an event in Munich to celebrate the 20 years of its creation. Founding companies were joined by more recent members of the organisation in a...

Java Card

Oracle Java Card and Java ME sessions at JavaOne 2017

Oracle will be having several sessions related to Java security and small devices at JavaOne this year (October 1-5, 2017 in San Francisco). See the details below. In addition, there will be a Hackergarten again this year, where several IoT projects will be showcased . Sign up for a slot if you have a project that you would like to present!   Oracle Java Card and Java ME Sessions at JavaOne Java Card: 20 Years of Security Innovation [CON4662] Monday, Oct 02, 11:00 a.m. - 11:45 a.m. | Moscone West - Room 2018 Java Card technology, entering its 20th year of existence, is available in billions of secure devices shipped each year. Oracle and Java Card Forum are working on the next iteration of the Java Card specification, bringing significant additions to address new security form factors in mobile and IoT. This session looks back at the history of Java Card adoption and introduces key features of the upcoming Java Card 3.1 release. Track:  Java and Devices Experience Level:  Intermediate Session Type:  Conference Session Speakers: Saqib Ahmad, Calinel Pasteanu (Oracle)   Securing the IoT Edge with Java Card [CON4643] Monday, Oct 02, 12:15 p.m. - 1:00 p.m. | Moscone West - Room 2018 This presentation looks at security risks introduced by new connected devices and highlights how Java Card solutions can help design secure IoT systems. It covers the following: Connected devices, security risks, and requirements Secure hardware options addressing IoT edge security challenges: established (TPM/TEE/Secure Element) and emerging solutions (integrated Secure Element) Impact of secure hardware introduction on the IoT infrastructure and ecosystem Java Card as an abstraction for new secure hardware solutions and driving cross-market adoption IoT edge security use cases (secure TLS, device attestation, secure I/O) and Java Card as an enabler of strong IoT security (certification, openness, verticals, ...) Track:  Java and Devices Experience Level:  Intermediate Session Type:  Conference Session Speakers:   Nicolas Ponsini, Calinel Pasteanu (Oracle)   Java ME for IoT: From Prototype to Product [CON5040] Tuesday, Oct 03, 3:00 p.m. - 3:45 p.m. | Moscone West - Room 2018 Bringing an IoT solution to market has many challenges: developing the software end to end; engineering, integrating, and field-testing the device hardware; and testing the solution and bringing it to deployment. The fast-paced IoT world mandates that all parts be developed in parallel, following the scrum model. Success requires proven end-to-end software frameworks and flexible, modular, pretested hardware components. Gemalto M2M was the first company to optimize Java for M2M wireless modules, in 2003, to address this challenge. This session presents an overview of the solution components and how they are used in IoT/M2M projects around the world. It explains how to start yourself and end with an outlook into the future. Track:  Java and Devices Experience Level:  Introductory Session Type:  Conference Session Speakers:   Rainer Eschrich (Oracle), Axel Hansmann  (Vice President Strategy & Marketing, Gemalto M2M GmbH)   See Also All sessions about IoT Java and Device Track Hackergarten Demos IoT: Caipirinha Bot IoT: Starting with Eclipse Kura IoT: Starting with Oracle IoTCS IoT: Device I/O.    

Oracle will be having several sessions related to Java security and small devices at JavaOne this year (October 1-5, 2017 in San Francisco). See the details below. In addition, there will be a Hackergar...

Java Card

Two clichés about Java Card

Prior to getting into more details about the evolution of Java Card technology in future posts, I would like to point out two common clichés about the platform : 1st cliché: "Java Card is just for smart cards." “Card” in Java Card is a misnomer. A more accurate name (but will less marketing appeal) may be “Java for resource-constrained devices to run securely Java technology-based applications”. While the Java Card framework and runtime are security oriented and designed to run on a Secure Element i.e a secure MCU with a few kilobytes of ROM, EEPROM and RAM and countermeasures against hardware attacks, it does not limit the scope to the Card form factor. There are already embedded and integrated Secure Elements on System on Chip in different markets: for IoT gateways, smart phones or in automotive area for instance. The aim here is not to deny the smart card history, the inheritance is strong anyway, but rather to express that Java Card is also running anywhere else and its evolution made it a security framework beyond the smart card world. 2nd cliché: "A knowledgeable Java developer is a Java Card developer." Actually, even skilled Java developers may be disconcerted by Java Card programming. Java Card is a Java subset but has a number of additional specificities like objet persistency and atomicity for instance. Historically, Java Card development has been a matter of specialists. Powerful virtual machine and object oriented language concepts are intrinsic to Java Card as a Java-based platform and make the development on a secure element by far easy compared to any other alternatives. On the other side, developing an applet that has to be formally proven for long lasting deployment and against software and hardware attacks (imagine payment and ID applets) requires additional strong security skills. Anyone can play with the Java Card Development Kit (and is encouraged to do so), but it takes time and experience to acquire the necessary expertise to deploy an applet in the field. The good news is that there is no shortage of resources available online (including on Oracle Technology Network) to start building that specific knowledge.

Prior to getting into more details about the evolution of Java Card technology in future posts, I would like to point out two common clichés about the platform : 1st cliché: "Java Card is just for...

Java Card

IoT: the TLS and Java Card story

I always hear that when the TLS protocol is used between a client and a server then everything is secure to exchange data in between the two ! I would like to stress a little bit this assumption in particular in the context of the IoT where billions of devices connect to the cloud. Indeed if we make abstraction of the way keys and sensitive secrets are generated and used on both sides the protocol is hopefully secure (version TLS 1.3 on the go though) but we obviously need to consider the handshake part of the TLS protocol during which authentication and secrets sharing are performed. Not to enter into too much details here, let's assume that the TLS version and the TLS ciphersuite used between both parties are state of the art for the purpose of this post.        IoT Device and IoT Cloud mutual authentication   1. Server/Cloud Authentication The TLS protocol performs a server authentication done by a client during the TLS handshake protocol. This is a mandatory part from which session keys are generated and shared by both sides. Then, session keys are used by the TLS record protocol that permits to exchange data securely. We may call this a secure channel. Data passing within this secure channel depends on this TLS server authentication step.   2. Client/Device Authentication The TLS protocol allows also for a client authentication done by the server during the TLS handshake protocol. This part is optional and rarely not to say never used in the context of IoT. To make it short: It implies too much management constraints and time processing. Consequently, other means are usually used to perform client authentication. Most of them are token based e.g OAUth2 tokens are used. Those tokens are passed from the client to the server throw the secure channel we just mentioned. In other words the passing of a genuine token is directly dependent on the TLS handshake protocol at the time of server authentication. This clearly makes the TLS server authentication processing on the critical path of the security of the solution.   Focusing on the server authentication side then: when you access the internet/cloud from a browser (to take a PC/mobile world example), your browser is equipped with a list of root certificates from vendors around the world which are used to authenticate the target server. The security of the process comes from the fact that you trust your browser. With IoT, you now have devices directly connected to the cloud you may not consider trusted. The whole TLS story in this context is at risk. Luckily solutions are possible.       Trusted Hardware   When you cannot trust a device on the whole, the solution is to reduce the scope of what you want to protect: you factorize your sensitive operations and assets and manage them within a dedicated trusted hardware that offers software and/or hardware protections from software and/or physical attacks. There are a few of such solutions for different use cases, with different specificity and different level of trust. We can mention TPM (Trusted Platform Module), TEE (Trusted Execution Environment), SE (Secure Element) as examples of such trusted hardware.   A first concern is that those are usually used to host a private key or a secret to perform device authentication but rarely used to host root certificates and process the TLS server authentication phase. TPM is not a run-time making it hard anyway but the two others are hosting run-time environment though.   A second concern is that those trusted hardware take different forms i.e for the SE case, some are discrete hardware (removable SE, embedded SE) or directly integrated on the device hardware platform (integrated SE). This does not help to provide a generic solution for the TLS server authentication.       Oracle Java Card as the unified framework for TLS authentication   Oracle Java Card framework is a security oriented framework running above a Secure Element and that successfully protects the most security demanding use cases since more that 20 years now: payment, Identity, Network access ... Its run-time capability and security oriented features make the development of a TLS server authentication application straight forward by guaranteeing its end to end security i.e. all phases of the TLS handshake protocol are secured and can be coupled also with the device authentication chosen mean. More than that, this is the only framework capable to adapt to the different family of trusted hardware avoiding fragmentation of the security solutions which is so critical in the IoT business.

I always hear that when the TLS protocol is used between a client and a server then everything is secure to exchange data in between the two ! I would like to stress a little bit this assumption in...

Java ME

Oracle Grows Java Capabilities for Internet of Things by releasing Java ME Embedded 8.3 and Java ME SDK 8.3

Companies of various industries have already benefited from Internet of Things (IoT) generated value.  As the number of IoT edge devices is growing dramatically and those appliances are becoming more and more intelligent, organizations are looking for horizontally scalable platforms which feed the needs of different verticals.  They are seeking a hardware agnostic standard based software stack which allows smooth movement across multiple architectures with the same codebase to rapidly enter new markets within a limited budget. The new Java ME Embedded 8.3 provides extensive support for market-leading embedded chip architectures and increases the range of supported OEM/partner platforms. With the new release, the Java ME Embedded 8 proofed security system has been enhanced to bring customers more capabilities and lower risks. Factory mass deployment and platform updatability are addressed by Java ME Embedded 8.3, giving customers confidence in the shortest time-to market and flawless evolution in future.   Oracle has announced today the latest releases to its Oracle Java Embedded product portfolio, Oracle Java ME Embedded 8.3 and Oracle Java ME Software Development Kit (SDK) 8.3, a complete client Java runtime and toolkit optimized for microcontrollers and other resource-constrained devices.   Release key features:   Oracle is extending its relationship with ST Microelectronics and adds improved support for the STM32F429I-EVAL evaluation platform within Java ME Embedded 8.3. A user now has the flexibility to configure peripherals and use custom hardware configurations without the need to rebuild or retest firmware. Oracle and ST Microelectronics are also adding support for Java in the STM32F7 series of microcontrollers based on modern Cortex-M7 cores, which enables embedded developers to take advantage of popular Java programming features, and a developer preview for the 32F746GDISCOVERY development platform. The new release reinforces the Java ME Embedded 8 Security system through the implementation of Secured File System supporting a number of HW Secured Elements to protect customer data from compromise. Java ME customers can encrypt application data (MIDlets, LIBlets), application meta-data and runtime configuration. Extended the application specific filesystem structure.  SHA256 for application signature Extending security API by adding HMAC support   The platform updatability mechanism is now an essential part of Java runtime and allows in-field platform updates, leaving untouched all user applications in order to conserve demands on wireless connectivity. As a follow-up to the Oracle and Intel joint announcement at JavaOne 2015, Java ME Embedded 8.3 has the capability to run on Intel Galileo gen 2 developers' board Feel free to download and evaluate Java ME Embedded 8.3 and Java ME SDK 8.3. Java ME Embedded 8.3 http://www.oracle.com/technetwork/java/embedded/javame/embed-me/overview/index.html   Java ME SDK 8.3 http://www.oracle.com/technetwork/java/embedded/javame/javame-sdk/overview/index.html   Give us your feedback at OTN community https://community.oracle.com/community/java/java_embedded/java_me_embedded    

Companies of various industries have already benefited from Internet of Things (IoT) generated value.  As the number of IoT edge devices is growing dramatically and those appliances are becoming more...

Java ME

Meet Java ME Embedded team at Embedded World in Nuermberg

Just in case you have recently jumped into an embedded industry the Embedded World is one of the biggest trade fairs of this kind. The event is absolutely a must-attend for embedded architects, developers, product and purchasing managers or anybody else who is passionate about the internals of an electronic appliance. The Embedded World trade fair in Nuremberg enables you to experience the whole world of embedded systems, including modern directions as distributed intelligence and the Internet of Things.  Oracle is extending its partnership with ST Microelectronics by developing Java ME Embedded ports to support two STM platforms based on ARM Cortex M4 and Cortex M7 MCUs. This should happen within the next release of our product, but you have a unique opportunity to see it in action next week. The Java ME Embedded team has a booth within the STM exhibition area at Embedded World Hall 4A / 4A-138 . We have prepared several impressive demo show cases for our booth. You will see how absolutely the same binary runs on both STM32429I-EVAL platform and Raspberry Pi. How particular software modules on ARM Cortex M4 platform update remotely with dependency resolution.   We prepared an absolutely awesome security feature which utilizes a brand new STM HW security module helping to keep Java binary protected in embedded devices. The brightest gem of our demo pod at Embedded World this year is a use case of Java ME Embedded platform integration with Oracle IoT Cloud Service. The demo is a prototype of a smart insurance system customizing an insurance plan based on driver behavior. The Java ME Embedded application gathers data from I2C accelerometer, processes it and as soon as the acceleration exceeds a predefined threshold, an alert message is generated and securely sent to Oracle IoT Cloud Service. The stream of messages is then processed in real time by an analytic engine, and based on the results of that analysis, an integrated external business application is notified about unusual driving actions for example rush driving. I am really happy to be at Embedded World with two exceptional Oracle engineers. Alexey Bakhtin, who is the security lead in our product, and Alexander Mironenko, the porting lead. They will be able to answer any platform related or deeply technical questions. Come to our booth and meet them in person. Also, if you want to catch up with me in person in Nuremberg, feel free to reach out via this blog or my twitter @gigabel.

Just in case you have recently jumped into an embedded industry the Embedded World is one of the biggest trade fairs of this kind. The event is absolutely a must-attend for embedded...

Java ME

Lightweight web server for Java ME Embedded 8

  To help programmers quickly start with Java ME Embedded 8 development, we have released a new bundle with demo applications. It is now available for download on OTN: http://www.oracle.com/technetwork/java/embedded/javame/embed-me/downloads The package includes two applications: a Web Services with JAX-RS client sample and a Lightweight Web Server for Java ME Embedded. This software is dual-licensed to you under the MIT License (MIT) and the Universal Permissive License (UPL). So it is easy to re-use the demo source code within your projects. For a full license text please read the license.txt file of the archive.     The IoT concept implies that field devices use a polling approach to connect to IoT cloud service. However, there are still a number of cases when direct access to the edge device is required, such as an initial appliance setup. The most convenient and user friendly way to configure system parameters remotely is via web access.   The Java ME Embedded development team have implemented a lightweight web server which is capable of handling HTTP requests and sending back HTTP responses. One of the key benefits of Java ME Embedded is the ability to run the same binary on different hardware, so that you can run this web server on any Java ME Embedded 8.2 device including Emulator.     The feature set of the server is really limited by basic functionality. The Web Server supports HTTP protocol of 1.1 and 1.0 with some limitations, explained in the webserver_readme.txt document. However, those limitations can be eliminated by extending the demo server, the demo distribution license is MIT so you can change the source code, or partly reuse it, within your projects.   If you have any questions or suggestions, feel free to reach us at the Java ME Embedded forum:  https://community.oracle.com/community/java/java_embedded/java_me_embedded

  To help programmers quickly start with Java ME Embedded 8 development, we have released a new bundle with demo applications. It is now available for download on OTN: http://www.oracle.com/technetwork/...

Java ME

Oracle Java ME Embedded 8.2 and Oracle Java ME SDK 8.2 have just been unveiled.

A new release of Oracle Java ME Embedded 8 is now available for download on OTN: http://www.oracle.com/technetwork/java/embedded/javame/embed-me/downloads/index.html This product is an evolving release of Java ME Embedded 8 platform specifically built to address the embedded developers’ requirements and shorten go-to-market time for the products on the edge of Internet of Things solutions. Java ME Embedded 8.2 expands security functionality and robustness of the runtime, enables new and improved connectivity features, enhances deployment options and brings several highly effective optimizations to the Virtual Machine and core libraries. Oracle Java ME SDK 8.2 is also delivering the embedded development experience to Linux users.       Application deployment and update capabilities of Java ME Runtime have been improved in the release. Device manufacturers and solution providers are able now to pre-provision software components with Java ME Embedded Runtime. Required applications will be installed and configured in unattended mode on the first Virtual Machine start. Updating runtime is getting really simple in a new version of the product. Standard approach in classical solutions to renew embedded OS is just complete re-flashing of a runtime and all applications on a device, which in some cases might be unacceptable due to expensive or slow connections. Java ME Embedded 8.2 allows you to keep all installed software unchanged after runtime update. Security and communication functionality have been extended by supporting DTLS client feature and providing an API to use Pre-Shared Keys. Crypto hardware acceleration is now supported on platforms which are capable of this functionality. The Device Access API (a dedicated Oracle API to enable access to device peripherals) has evolved to version 1.1, which includes several improvements to make access to peripheral hardware even easier and more reliable. The Java ME Embedded VM team has been working hard on a set of runtime optimizations which have been honed and applied in the Java ME Embedded 8.2 release. The results are really impressive. With previous release on Freescale K64-FRDM board with 256KB of RAM developers had approx. 60KB of free heap for their Java applications. In Java ME Embedded 8.2 the free application memory has been increased to around 150KB, which is more than double compared to before and allows developers to create even more advanced Java applications for micro-controller platforms. And, last but not least, Linux desktop users are welcome now to develop Java ME Embedded applications with Java ME SDK 8.2. Netbeans and Eclipse IDEs are supported as well as Device Manager with a new functionality. To simplify on-device development Device Manager offers an updated device flashing tool to make Raspberry Pi or Freescale K64-FRDM Java-enabled devices with only a few mouse clicks.     Download Oracle Java ME Embedded 8.2 and Java ME SDK 8.2 to experience Java development on resource-constrained embedded devices. Java ME Embedded 8.2: http://www.oracle.com/technetwork/java/embedded/javame/embed-me/overview/index.html Java ME SDK 8.2: http://www.oracle.com/technetwork/java/embedded/javame/javame-sdk/overview/index.html Java ME Embedded 8.2 and Java ME SDK 8.2 Documentation: http://docs.oracle.com/javame/8.2/index.html Please give us your feedback on the new release on Java ME Embedded forum: https://community.oracle.com/community/java/java_embedded/java_me_embedded

A new release of Oracle Java ME Embedded 8 is now available for download on OTN: http://www.oracle.com/technetwork/java/embedded/javame/embed-me/downloads/index.html This product is an evolving...

Java ME

Smart Solar Panel Control system source package available at Java ME SDK update centre

If you have Java ME SDK 8.1 installed already, you can check that a new update can be installed from Java ME SDK Update Centre. The update package includes documentation, binaries, and sources to build Smart Solar Panel Control system. By releasing this update we intended to demonstrate how reasonably complicated application can be built using Java ME Embedded 8.1 platform.  The demo guide allows to create a hardware platform which is capable to find the position for the solar panel with the maximum luminosity and report the data to an enterprise application.      Within this project the same binary is running on 3 completely different HW platforms: Raspberry Pi, STM32429I-EVAL and Freescale Kinetis K70 (binary is not available on OTN for public use)   After the update installation a demo/ folder will be created in the Java ME SDK 8.1 directory. Inside it you will find folders with binaries, documentation and  projects for Netbeans and Eclipse.    SolarPanelApplication/    source code, NetBeans and Eclipse projects  of ME Embedded application  SolarPanelShare/     source code of  the  demo part shared between ME Embedded   and Java FX applications   binaries/   folder with executable, library and configuration files  docs/           folder with documentation     If you have any issue or question related to Java ME Embedded feel free to ask at our forum: https://community.oracle.com/community/java/java_embedded/java_me_embedded  

If you have Java ME SDK 8.1 installed already, you can check that a new update can be installed from Java ME SDK Update Centre. The update package includes documentation, binaries, and sources...

Java Card

Java Card 3.0.5 is now available

We have just released a new version of Java Card, Classic Edition. Java Card 3.0.5 specifications and development kit are now available for download. What's new in this release?  This release includes a lot of new features for Java Card developers, as well as a new IDE plug-in that works with Eclipse. Here is a short summary of the new features: PIN extensions for banking. The OwnerPIN class has been an issue for EMV application developers for a long time, and the new PIN extensions address these issues, for instance allowing the update of the number of PIN presentation attempts after the allocation of the PIN object. Secure variables and arrays. This new API allows developers to protect the integrity of data against external attacks by using a specific API. It has the potential to greatly simplify the development of some sensitive applications. Secure basic operations. This new API allows developers to protect the integrity of sensitive operations against external attacks without having to perform the operation twice. Static cryptography. This new API simplifies and optimizes the use of cryptographic engines when they are needed for a single operation. Elliptic curve domain conservation. This new features simplifies the initialization of elliptic domain key sets by conserving the domain definition between operations. Diffie-Hellman support. Improved key agreement coverage. Support of Java language improvements. Java Card can now be compiled with Java 7 or Java 8, and the language improvements defined in Java 7 that can apply to Java Card are now supported, for instance binary literals. One-to-many biometry support. The biometry API has been extended to support one-to-many biometry, where a biometric sample can be compared to several templates. Utilities for analyzing an APDU. Utilities have been added to perform simple APDU analysis tasks that are commonly performed by applications. In addition to these new features, new cryptographic algorithms are now supported, including AES-CMAC, PACE, SHA-3, AEAD_CCM, and AEAD_GCM.   What's next?  Some of these new features can have a significant impact on the development of applications, and you can take a look at it today: Download and read the Java Card 3.0.5 specification. Download the Java Card 3.0.5 Development Kit, and start using the new features in Java Card applets. We will also describe the new features in greater details in further blog posts, so stay tuned.

We have just released a new version of Java Card, Classic Edition. Java Card 3.0.5 specifications and development kit are now available for download. What's new in this release?  This release includes a...

Java Card

What is Java Card ?

Here is an answer, which also includes the answer to a few ancillary questions...   Java Card was designed as a subset of Java targeting smart cards Java Card technology is a specific Java platform that targets smart cards and related systems, which typically run on specific hardware known as Secure MCUs. The Java Card platform has a very small footprint, and it explicitly targets security applications, with dedicated APIs to manage authentication credentials (PIN) and cryptography.   When and why did this idea come? The first version of Java Card was created in 1996, and it took a few iterations to design Java Card 2.1.1, in 1998. The most important design decisions taken then remain in use today. In 2015, we expect Java Card to be deployed on over 3 billion smart cards, and this number has been growing steadily since the first deployments around 2000.   At the end of the 1990's, smart cards, and in particular SIM cards, were a booming market. Some specifications had been defined that allowed mobile operators (who issue SIM cards) to load scripts/applications on their SIM cards. The industry was looking for a standard to support these applications. Every vendor was working on a proprietary solution, and Java Card rapidly emerged as a "neutral" solution that could satisfy all parties.   Why a specific platform? In 1997, the specification for a smart card that would support was to have at least 64k of ROM, 16k of EEPROM, and 256 bytes of RAM. Even then, this was several orders of magnitude smaller than Java's requirements. Even beyond memory, smart card hardware and basic software is quite specific, and led to Java Card design decisions: Power is external, but the persistent memory exhibits good atomicity properties. Smart cards process commands and communicate through a single serial channel. Smart cards are tamper-resistant and their security is often certified. Smart cards have even more strange characteristics, but this is definitely enough to justify a specific platform.   Java Card does not run on PCs or servers This is a consequence of the first answers: Java Card is made to run on cards, not "big" computers. The Java Card specification does not define how a computer can access a smart card, even from Java.   How can we access a Java Card card from a PC? A card that includes Java Card is accessed like any other smart card, through a card reader, and using the ISO7816 standard (if a contact interface is used), or the ISO14443 standard (if a contactless interface is used). Most computers today support PC/SC, which is a standard interface that supports many kind of smart card readers.   In Java, an API to access smart cards is defined in JSR-268, which is supported in all recent Java releases from Oracle.   Java Card is pervasive Java Card is pervasive in the sense that it is everywhere although it is mostly invisible. Here are a few places where Java Card technology can be found: On SIM cards, in particular if you live in Europe, America, Japan, or South Korea, or if you have a NFC-enabled SIM card. The main use cases are SIM Toolkit applications (the original use case), as well as NFC applications. On payment smart cards, in particular if you card supports both a contact and a contactless interface. With smart card deployments in China and USA, the volumes are still growing fast in 2015. On identity cards and electronic passports, depending on the country. National ID programs with several applications are typically good candidates for Java Card. In 2015, roughly 1 smart card out of 3 deployed will include Java Card. These are mostly the high-end cards, in all vertical application domains.   Java Card developers are specialists Java Card technology is mostly used by specialists from the smart card industry, because smart card development is a bit specific: Smart cards are deployed in large numbers (millions for most deployments) with no possibility for update in most cases. In such a context, there is a great emphasis on quality, and strong compliance requirements. Smart cards protect sensitive assets and are potential attack targets. They are often subject to strict security certifications, requiring specific development procedures and even secure development premises. There are no statistics on the number of Java Card developers, but we can estimate them to be in the thousands, with only a few highly-skilled specialists in every company that develops Java Card applications. Can I develop a Java Card application? Yes. Anybody can download our development kit and start developing a Java Card application. Java Cad is routinely used in classrooms, and a number of startups have developed their own Java card application. Java Card is a rather simple subset of Java, and it is by far the easiest way to develop an application for smart cards. Yet, before you start developing, there are at least two things to consider:  Smart cards are for security. The hard part of developing a Java Card application is the security part. The application must have a clear security purpose, and it must be developed following strict security standards. This is where expertise is required, even if Java Card makes the development of applications easier. Smart card applications need to be deployed. Smart cards typically belong to their issuers (governments, banks, MNOs, etc.). Deploying an application typically requires getting in touch with issuers and convincing them to deploy, which is a hard task. Unless of course your plan is to design a device that includes a smart card core and deploy it yourself.

Here is an answer, which also includes the answer to a few ancillary questions...   Java Card was designed as a subset of Java targeting smart cards Java Card technology is a specific Java platform...

Java ME

Using Line User Interface with Oracle Java ME Embedded 8.1 on STMicroelectronics Evaluation board

Oracle Java ME Embedded 8.1 Developers Preview for ST Micro Evaluation board has been recently released.  As I mentioned in my previous post, one of the release additions is a Line User Interface (LUI) API hardware implementation. LUI is an optional API of MEEP (JSR 361), which enables rendering text information on a display. In Java ME Embedded 8.0 this functionality was supported only by Java ME SDK Emulator and now it is possible to use a hardware display to implement a simple user interaction in Java ME Embedded applications.  Java ME SDK 8.1 update includes a very good LUI sample. The sample is an on-screen text menu navigated by a built-in joystick. The menu has 12 items, several nested items, and a status line reflecting a current user choice.  Code of the sample is accompanied very detailed comments, which can definitely helps start developing interactive applications very fast. Below is a basic example that demonstrates the use of the built-in screen on STM32429I-EVAL board with Java ME Embedded and LUI API.  Happy Java coding for embedded. import java.util.Iterator; import javax.microedition.lui.Display; import javax.microedition.lui.DisplayColor; import javax.microedition.lui.DisplayListener; import javax.microedition.midlet.MIDlet; public class LUIDemo extends MIDlet implements DisplayListener {@Overridepublic void startApp() {// Get Display instance and configure it Iterator<Display> displays = Display.getDisplays(false); Display myDisplay = displays.next();// Assign a state change listner to Display instance myDisplay.addDisplayListener((DisplayListener) this);//as soon as the hardware display will be assigned to myDisplay instance//hardwareStateChanged method will be invoked with newState = true synchronized (myDisplay) {try {// Assign hadware display to myDisplay myDisplay.setHardwareAssigned(true);// Assigning display may take some time,// so that we need to wait the operation acomplishement myDisplay.wait();// Now myDisplay has HW display assigned and we can use it} catch (InterruptedException ex) { ex.printStackTrace();}}//Display.setText is overloaded method. //In the example below the text "Hello world" is blinking. myDisplay.setText(0, "Hello world", true, false); myDisplay.setText(1, "I love programming Java ME Embedded on STM32429EVAL");}@Overridepublic void destroyApp(boolean unconditional) {}@Override// hardwareStateChanged method is invoked as the hardware display is assigned or unassignedpublic void hardwareStateChanged(Display d, boolean newState) {//Setting up assigned hardware display d.setLightingColor(new DisplayColor(0xFF, 0, 0)); d.setCurrentTextColor(new DisplayColor(0, 0, 0xFF)); d.setBackgroundColor(new DisplayColor(0, 0, 0));// notify all threads are waiting for Display Objectsynchronized (d) { d.notifyAll();}}@Overridepublic void displayAdded(Display d) {}@Overridepublic void displayRemoved(Display d) {} }

Oracle Java ME Embedded 8.1 Developers Preview for ST Micro Evaluation board has been recently released.  As I mentioned in my previous post, one of the release additions isa Line User Interface...

Java ME

Oracle Java ME Embedded 8.1 released with support of STMicroelectronics STM32F4 micro controller

Oracle Java ME Embedded 8.1 Developer Preview for STM32429I-EVAL has been released today. With this release, the STM32F4 series of micro controllers is joining the family of platforms supported by Java ME Embedded.  Product page: http://www.oracle.com/technetwork/java/embedded/javame/embed-me/downloads/index.html ST Micro produces widely used and very popular high-performance MCUs with the STM32F4 core, which is based on the ARM Cortex-M4 architecture. The detailed information can be founded at STM web.  The Java ME 8.1 Embedded STM port release enables developers to run feature-rich Java ME Embedded applications on the STMicroelectronics STM32429I-EVAL developer evaluation board.  The Java ME 8.1 follow-up release for STM has full CLDC 8 support, networking, storage, and peripheral I/O support, including GPIO, I2C, SPI, ADC, UART, and other interfaces. The interesting particularity of the release is the implementation of this port on top of ARM Cortex Microcontroller Software Interface Standard (CMSIS), which will allow Oracle and its partners to make feature porting easier and faster.   With this release, developers are able to access on-board screen with the simple Line User Interface (LUI) API. Java ME SDK Update center is distributing an update package with a great example of developing a text menu operated by on-board joystick. After its installation, a LUI sample can be found at your local drive:  /Java_ME_platform_SDK_8.1/apps/SimpleLUISample   Do not forget to update Java ME 8.1 SDK by navigating to NetBeans or Eclipse menu Tools -> Java ME -> Java ME SDK Update Center and installing the STM32429I-EVAL SDK Update. After applying this update, you will be able to work with STM32429I-EVAL as with any other ME SDK supported board.   Feel free to ask any questions and provide your feedback at our forum: https://community.oracle.com/community/java/java_embedded/java_me_embedded    

Oracle Java ME Embedded 8.1 Developer Preview for STM32429I-EVAL has been released today. With this release, the STM32F4 series of micro controllers is joining the family of platforms supported by...

Java ME

Java ME Embedded 8.1 brings Java to ARM Cortex M4 and provides Eclipse users with tools for embedded development

A couple days ago, Java ME Embedded 8.1 was released. The new version of the Java ME Embedded platform has two significant enhancements. First, it works on ARM Cortex M4 with very limited RAM size by delivering a port for Freescale K64F. Second, it provides Eclipse IDE support in Java ME SDK. The link to the release page: http://www.oracle.com/technetwork/java/embedded/javame/embed-me/overview/index.html   FRDM-K64F is based on  MK64FN1M0VLL12 MCU (120 MHz, 1 MB flash memory, 256 KB RAM, low-power, crystal-less USB, and 100 Low profile Quad Flat Package (LQFP)). It is has a form-factor of Arduino™ R3 pin layout. The FRDM-K64F goes with a lot of peripherals to enable rapid prototyping. In addition to UART, I2C, SPI, and GPIO interfaces on board, it has 3 LEDs and 2 switches which are accessible from Java Runtime. Another helpful device that is integrated into K64F is accelerometer-magnetometer with I2C interface (FXOS8700Q). You can easily access it from your Java application and create a compass application, for instance. Find the code example below the post..   Java ME SDK 8.1 brings smooth experience of Java Embedded developers to the Eclipse world. Java ME SDK plugin for Eclipse is based on the recently released Mobile Tools for Java TM (MTJ) 2.0 which had been done with significant efforts of Oracle's engineers. Now, all impressive features of Java ME SDK, such as on-device debugging, memory and network monitors, CPU profiling, and memory profiling are available in Eclipse. To install it, you need just to go the OTN web, download and install Java ME SDK with Eclipse plugin http://www.oracle.com/technetwork/java/embedded/javame/javame-sdk/downloads     If you have any questions or suggestions, please speak up at our forum: https://community.oracle.com/community/java/java_embedded/java_me_embedded The best source of information about Java ME Embedded is Java ME Documentation portal: http://docs.oracle.com/javame     How to get a device ID from FXOS78700Q on K64F: public class FXOS8700Q extends MIDlet {private I2CDevice fxos8700q;final int FXOS8700Q_STATUS = 0x00;final int FXOS8700Q_OUT_X_MSB = 0x01;final int FXOS8700Q_OUT_Y_MSB = 0x03;final int FXOS8700Q_OUT_Z_MSB = 0x05;final int FXOS8700Q_M_OUT_X_MSB = 0x33;final int FXOS8700Q_M_OUT_Y_MSB = 0x35;final int FXOS8700Q_M_OUT_Z_MSB = 0x37;final int FXOS8700Q_WHOAMI = 0x0D;final int FXOS8700Q_XYZ_DATA_CFG = 0x0E;final int FXOS8700Q_CTRL_REG1 = 0x2A;final int FXOS8700Q_M_CTRL_REG1 = 0x5B;final int FXOS8700Q_M_CTRL_REG2 = 0x5C;final int FXOS8700Q_WHOAMI_VAL = 0xC7;final int UINT14_MAX = 16383;@Overridepublic void startApp() { ByteBuffer buffer = ByteBuffer.allocateDirect(1);try { fxos8700q = DeviceManager.open(300, I2CDevice.class); buffer = read(FXOS8700Q_WHOAMI, 1, 1);} catch (IOException ex) { ex.printStackTrace();} String id = String.format("%8s", Integer.toBinaryString(buffer.get(0) & 0xFF)).replace(' ', '0'); System.out.println(id);}@Overridepublic void destroyApp(boolean unconditional) {}void write(int address, int addressSize, ByteBuffer data) throws IOException { fxos8700q.begin(); fxos8700q.write(address, addressSize, data); fxos8700q.end();} ByteBuffer read(int address, int addressSize, int bytesToRead) throws IOException { ByteBuffer buffer = ByteBuffer.allocateDirect(bytesToRead); fxos8700q.begin(); fxos8700q.read(address, addressSize, buffer); fxos8700q.end();return buffer;} }

A couple days ago, Java ME Embedded 8.1 was released. The new version of the Java ME Embedded platform has two significant enhancements. First, it works on ARM Cortex M4 with very limited RAM size by...

Java ME

Java ME Embedded is able to run with 256Kb of RAM only

Around a JavaOne conference timeframe we announced Java ME Embedded 8.1 Developer Preview release.  This release is bringing Java ME Embedded to a microcontrollers with ARM Cortex M architecture with mbed RTOS. Java ME Embedded is now capable to run on Freescale K64F board. The FRDM-K64F is an ultra-low-cost development platform for Kinetis K64.  The K64F board has a form-factor which compatible with the Arduino™ R3 pin layout, providing a wide range of expansion board options. FRDM-K64F based on  MK64FN1M0VLL12 MCU (120 MHz, 1 MB flash memory, 256 KB RAM, low-power, crystal-less USB, and 100 Low profile Quad Flat Package (LQFP)) The FRDM-K64F is feature packed with a lot of peripherals to enable rapid prototyping.    As always the best way to start with Java ME on any new platform is our Getting Started Guide, which can be found at Java ME Documentation page http://docs.oracle.com/javame/8.0/index.html   What I would like to emphasize is a new Flasher capabilities of Java ME SDK. If you have a new K64 you can make it Java-enabled by just clicking "Flash" button in Device Connection Manager. I will explain you how to do it.   Firstly, if you have not installed mbed Serial Driver and USB Serial it is better do it using detailed instruction from K64 GSG http://docs.oracle.com/javame/8.1/get-started-freescale-k64/toc.htm.   Then obviously you need a Java ME SDK 8.1 EA3 with new NetBeans plugins, which can be downloaded at OTN http://www.oracle.com/technetwork/java/embedded/javame/javame-sdk/downloads/index.html   Now you can check new flashing capabilities. 1. Go to t the Windows tray and click on Device Connection Manager 8.1 2. Click "Flash" button and pick your connected K64 board from the list following. 3. Say: "Wow, how cool it is to enable mbed device with Java capabilities!"     As I said before, K64 is a very convenient platform for prototyping. It has multicolor LED, switches and other peripherals on board. Let's make LEDs blinking. Do not forget to set API permissions as described in one of my previous post  https://blogs.oracle.com/javame/entry/measuring_temperature_with_raspberry_pi. If you have any question it is my pleasure to answer here or at Javas ME Embedded forum https://community.oracle.com/community/java/java_embedded/java_me_embedded   Create a new MidLet and copy code below instead of generated. Do not forget to rename the class import java.io.IOException; import java.util.logging.Level; import java.util.logging.Logger; import javax.microedition.midlet.MIDlet; import javax.microedition.midlet.MIDletStateChangeException; import jdk.dio.DeviceManager; import jdk.dio.gpio.GPIOPin; import jdk.dio.gpio.GPIOPinConfig; /** * * @author abelokry */ public class JavaMEOnK64 extends MIDlet { @Overridepublic void startApp() {try { String platform = System.getProperty("microedition.platform"); // Get Platform name it might be useful to identify the platform your midlet running and configure accordingly String productVersion = System.getProperty("com.oracle.product.version"); // Get product version System.out.println("platform = " + platform + " version = " + productVersion); GPIOPin orangeLED = (GPIOPin)DeviceManager.open(1); //Open Yellow LED see Getting Started Guide for details GPIOPin yellowLED = (GPIOPin)DeviceManager.open(2); //Open Green LED, see Getting Started Guide for detailsfor (int i = 0; i < 10; i++) { orangeLED.setValue(true); Thread.sleep(500); orangeLED.setValue(false); yellowLED.setValue(true); Thread.sleep(500); yellowLED.setValue(false);}} catch (Exception ex) { ex.printStackTrace();} notifyDestroyed();}@Overrideprotected void destroyApp(boolean unconditional) throws MIDletStateChangeException {throw new UnsupportedOperationException("Not supported yet."); //To change body of generated methods, choose Tools | Templates.} }

Around a JavaOne conference timeframe we announced Java ME Embedded 8.1 Developer Preview release.  This release is bringing Java ME Embedded to a microcontrollers with ARM Cortex M architecture with...

Java ME

Measuring temperature with Raspberry Pi, I2C sensor and Java ME 8

  Nowadays, developers reveal their growing interest to the microcontrollers, devices based on ARM processors, and other non-traditional hardware. To satisfy the increasing demand, the market introduced  Arduino, Beagle Board, Raspberry Pi, and many other devices. Oracle provides two Java platforms for ARM-based devices. Whereas Java SE Embedded is aimed for powerful hardware,  Java ME Embedded works better for resource-constrained devices.   Oracle Java ME Embedded is a Java Runtime optimized for constrained ARM based devices. Minimally acceptable requirements for Java ME embedded are 128Kb of RAM and 1Mb of ROM. Using Java ME Embedded in your projects can bring several benefits. First of all,  "write once, run everywhere" principle, now with some restrictions can be applied to embedded world. Second, AMS (Application Management System), integrated into the platform. enables deploying, updating, starting, stopping, and destroying applications. Third, you have an API to access peripheral, such as SPI, I2C, URAT, and GPIO pins (DAAPI - Device Access API). Forth,, you will get a free and powerful developer tools as well as a set of standard services: File I/O (JSR 75), Wireless Messaging (JSR 120), Web Services (JSR 172), Security and Trust Services Subset (SATSA – JSR 177), Location (JSR 179), and XML (JSR 280). As you can see, Oracle Java ME Embedded is a cross-platform product, which supports a set of ARM based devices. The current version is Oracle Java ME 8. The platform is ported to ARM11/Linux (Raspberry Pi Model B), ARM9/BREW MP (Qualcomm IoE development), and X86/Windows (emulator). These are reference implementations developed by Oracle engineers. If there is customer’s need, the platform can be ported to other devices.   Smart home Personally, I would really like to see my home automated. It is always a true pleasure to communicate with smart people and a real delight to live in a smart home. The first idea that usually strikes my mind when I’ve got a small piece of hardware is to automate something at my house. A typical task is a temperature monitoring. To monitor temperature you can use UART, SPI, or I2C sensors. Usually, I2C ones are a bit cheaper, so that I will use Dallas Semiconductor DS1621 in DIP8 form factor to make a digital thermometer with Raspberry Pi and Java ME Embedded. Raspberry Pi hardware setup First of all, we need to physically connect the sensor and a RPi pin1 - SDL pin2 - SCL pin4 - GND pin8 - Vdd If you read a datasheet of DS1621, you know that the sensor address at the I2C bus can be configured by pins 5-6-7. For our sensor, let's turn them all to 1 by closing contacts to the power.   Setup software at Raspberry Pi Install Raspbian and update it. To enable I2C interface on Raspberry Pi it is necessary to upload the relevant module add 2 lines to /etc/modules i2c-bcm2708 i2c-dev Reboot RPi Install Linux tools to operate with I2C sudo apt-get install i2c-tools Detect an address of our sensor sudo  i2cdetect -y 1 address is 4f (remember it) Download Oracle Java ME Embedded 8  for Raspberry Pi Model B. Accept a license agreements http://www.oracle.com/technetwork/java/embedded/javame/embed-me/downloads/index.html Copy Runtime to Raspberry Pi to your favorite location and unpack it for instance ~/JavaME/ Start Runtime with AMS (Application Management System) under the root privileges sudo ~/JavaME/bin/usertest.sh We have just  finished with the RPi setup   Developer tools setup If you have not yet played with Oracle Java ME SDK 8, set it up for Netbeans. http://www.oracle.com/technetwork/java/embedded/javame/javame-sdk/downloads/index.html Add our RPi as a deploying device In NetBeans choose: Tools -> Java ME -> Device selector The most probably your Raspberry already autodetected by Java ME SDK and exists in the list of connected devices. If it is not, you can find the Device Connection Manager in your Windows tray and add RPi manually.  To do it, just click add and write the IP address of your RPi and define a debug level you need. Create a new project in Netbeans:  New Project -> Java ME -> Embedded application IDE creates a skeleton of Java ME application, which extends a MIDlet class  and consists of 3 methods: startApp(), pauseApp(), anddestroyApp(boolean unconditional) Java ME Embedded provides us with an API to communicate with peripherals – DIO API (Device Input/Output API). To operate with I2C, we need to create a configuration of the device, pass it to the factory DeviceManager.open(), and if everything is alright, we will get an instance of the I2CDevice class required to communicate with the sensor. To allow your application to use a specific API on the device you need to set up API Permissions. In Netbeans click right button on your project in Project Properties go to tab Application Descriptor and to access I2C device add 2 lines:   Permission Protected Resource Name Action Requested jdk.dio.DeviceMgmtPermission *:* open jdk.dio.i2cbus.I2CPinPermission *:* open To run a code below on your RPi, right-click  on your device in Device Selector window, and under "Run project" menu click on the project you would like to run on Raspberry. Alternatively,  you can use the project properties in Platform tab to define a Device. In that’s the case, NetBeans always uses RPi as a target device for deployment. Now you should know the temperature in room. The best collection of docs about Java ME Embedded 8 can be found here: http://docs.oracle.com/javame/8.0/ Have fun! /* * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved. * ORACLE PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. */ import javax.microedition.midlet.MIDlet; import java.io.IOException; import java.nio.ByteBuffer; import jdk.dio.DeviceManager; import jdk.dio.i2cbus.I2CDevice; import jdk.dio.i2cbus.I2CDeviceConfig; public class JavaMEThermometer extends MIDlet {private final int CFG_ADDRESS = 0x4f; //Sensor addressprivate final int FREQ = 100000; //Bus frequency from Datasheetprivate final int ADDRESS_SIZE = 7; //Address size from Datasheetprivate final int BUS_ID = 1; // Internal bus ID in Java ME Embedded from Getting Started Guide// Registers addresses and definitions of configuration parameters of DS1621 from Datasheetprivate final int REG_READ_TEMP = 0xAA;private final int RT_ADDR_SIZE = 0x01;private final int READ_TEMP_SIZE = 0x02;private final int READ_TEMP_VAL = 0x00;private final int REG_ACC_CONF = 0xAC;private final int ACC_CONF_VAL = 0x00;private final int REG_START_CONV = 0xEE;private final int REG_STOP_CONV = 0x22;public void startApp() {// Create a configuration I2CDeviceConfig config = new I2CDeviceConfig(BUS_ID, CFG_ADDRESS, ADDRESS_SIZE, FREQ); I2CDevice device = null;try {// Open device using configuration device = (I2CDevice) DeviceManager.open(config);// Config sensor to continuous temperature measuring according to Datasheet write(device, new byte[]{(byte) REG_ACC_CONF, (byte) ACC_CONF_VAL}); write(device, new byte[]{(byte) REG_START_CONV});// Read temperature ByteBuffer tempBuf = ByteBuffer.allocateDirect(READ_TEMP_SIZE); device.read(REG_READ_TEMP, RT_ADDR_SIZE,tempBuf);// Profit! System.out.println("Temperature is:" + tempBuf.get(0));} catch (Exception ex) { // Bad practice. Only for consiceness ex.printStackTrace();} finally {// Close deviceif (device != null) {try { device.close();} catch (IOException ex) { ex.printStackTrace();}// Destroy application notifyDestroyed();}}}public void pauseApp() {}public void destroyApp(boolean unconditional) {}private void write(I2CDevice i2c, byte[] buffer) {try { i2c.begin(); i2c.write(ByteBuffer.wrap(buffer)); i2c.end();} catch (IOException ex) { System.out.println("[I2CThermometerTest] configure exception: " + ex.getMessage());} catch (Exception ex) { System.out.println("[I2CThermometerTest] Peripherial not available exception: " + ex.getMessage());}} }

  Nowadays, developers reveal their growing interest to the microcontrollers, devices based on ARM processors, and other non-traditional hardware. To satisfy the increasing demand, the market...

Oracle

Integrated Cloud Applications & Platform Services