More than a month ago, Java 8 has announced its General Availability, where other products such as Java Platform, Standard Edition (SE 8), Java Platform, Micro Edition 8 (ME 8) were included in its webcast. In April 30, Oracle has officially publicized Java ME Embedded 8 release, it’s a week after its specifications has been approved.
Java Micro Edition Embedded 8 is a Java Micro Edition (ME) 8 runtime whose specifications are aimed to have more functionalities, portability, flexibility, and security.
This release is based on Java ME Connected Limited Device Configuration (CLDC) 8 or JSR 360 and Java ME Embedded Profile (MEEP) 8 or JSR 361; it also offers the following:
- • Alignment with Java SE 8 language features and API
- • Updated “services-enabled” application platform
- • Support to customize and “right-size” the platform
- • Access from Java to a range of devices via GPIO, I2C, SPI, UART and more
- • Application development is supported through the Oracle Java ME SDK 8
Oracle also listed the following key features of Java ME Embedded 8:
- • Implementation of the Java ME 8 specification
- • Versatile and flexible networking and connectivity, including wireless support (3GPP, CDMA, WiFi)
- • Improved access to peripheral devices through Device I/O API
- • Improved tooling support (Developer Agent, On-device Debugging, Memory Monitor, Network Monitor, CPU Profiler, Logging)
- • New APIs for RESTful programming
- • JSON API
- • Async HTTP API
- • OAuth 2.0 API
- • Implementation of the following JSRs:
- o JSR 75 (File Connection API)
- o JSR 120 (Wireless Messaging API)
- o JSR 172 (Web Services API)
JSONB, a structured format for storing JSON has been introduced in a message by Andrew Dunstan posted on PostgreSQL’s website. Andrew Dunstan authored JSONB together with Oleg Bartunov, Teodor Sigaev, and Peter Geoghegan; and reviewed by Andres Freund. Andrew described that this new format accepts the same data as the JSON type yet it is stored in a format that does not need reparsing the original text in order to process it. This process makes it more ideal for indexing and other operations wherein irrelevant whitespace is removed and order of object keys is not kept. Also, duplicate objects keys are not kept – the only one stored is the later value for a given key.
He also mentioned that this features was created out of the previous work by Oleg Bartunov and Teodor Sigaev which aimed to offer similar facilities to a nested HStore type, however, it was later on verified to have some major compatibility issues.
Meanwhile, Peter Geoghegan wrote in his blog that jsonb_hash_ops alternate GIN operator class by Alexander Korotkov, one of the contributor of JSONB not credited in the JSONB commit message, deserves an honorable mention. “By combining GIN with hashing of either key/value pairs, or array elements, resulting indexes can give great performance for sophisticated “containment” type queries against JSON documents. Indexes are a fraction of the size of the data indexed, index scans are incredibly fast, and yet these GIN indexes make indexable very complex nested “containment” queries. The results are so impressive that at last November's pgConf.EU conference, an EXPLAIN ANALYZE comparative example in a presentation given by Oleg and Teodor was greeted with sustained applause.” Peter mentioned.
JSONB has made in the upcoming 9.4 release of PostgreSQL, an open source Object-Relational Database Management System (ORDBMS) known for its reliability, data integrity and correctness.
The most awaited JCACHE also known as JSR 107 – Java Temporary Caching API has finally been released in March 18, 2014. This specification request has been started way back in 2001, nevertheless, over 80% voted for its inclusion in the platform on a 2012 Java EE 7 survey.
In the original proposal posted in the Java Community Process' website, JCACHE has been described as a specification that standardize process caching of Java objects in a way that allows an efficient implementation, and removes from the programmer the burden of implementing cache expiration, mutual exclusion, spooling, and cache consistency. Objects whose type is not known until runtime can be cached, but only those which implement the serializable interface can be spooled.
The main purpose of JCACHE is to let developers solve usual problems by only writing little code as possible. This will work on any Java platform and will be beneficial to server platforms like servlet container.
It is also said that there are no specifications yet that handle automatic creation and refresh of temporary, in-process data shared across threads. The following are mentioned issues with existing specifications that can be addressed through JCACHE:
- Java Naming Directory Interface (JNDI) is used for searching objects by name and an interface for caching implementation. But this application requires checking expiration of retrieved objects after each look up, and synchronizing creation and binding of a new object. Per object cache attributes (e.g., expiration time) would require introduction of an additional level of indirection: the application would look up a cache handle and use one of its methods to access the associated object.