An experience in developing embedded software using JNI

- Preliminary data of the biodiversity in the area VNU Journal of Science, Natural Sciences and Technology .
- VNU Journal of Science, Natural Sciences and Technology An experience in developing embedded software using JNI.
- Embedded software grows more and more rapidly and complicatedly.
- This paper proposes a new structure and a comprehensible process to develop embedded software in JNI, a new programming framework allowing Java code running in a JVM to call or be called by native application and library written in C/C.
- Therefore, programmer can develop application that benefit the simplicity and reusability features of Java and can always reuse legacy code for controlling device effectively written in C/C++ for embedded applications.
- Putting aside its complexity, the C++ approach simply cannot guarantee the long-term support, product development and pool of qualified programmers that will be critical to the successful development of very large real-time systems and development projects that span decades, as NASA and military projects do [3].
- JNI is a programming framework that allows Java code running in the Java Virtual Machine (JVM) to call and be called by native applications and libraries written in other languages, such as C, C++ and assembly.
- The JNI is used to write native methods to handle situations when an application can not be written entirely in the Java.
- It is also used to modify an existing application, written in another programming language, to be accessible to Java applications.
- This paper exposes some experiences in developing embedded software using JNI technology.
- We present a structure for embedded software which includes two parts: upper stream written in Java and lower stream written in C.
- If embedded system is a real-time system, RTSJ (Real-Time Specification for Java) is used for upper stream to implement real-time aspects.
- In this paper, we present our process to develop embedded software using JNI through two case studies.
- The remainder of this paper is organized as follows: In section 2 we give an overview of the JNI and RTSJ technologies.
- Section 4 introduces the process we used to develop embedded software.
- JNI The Java™ Native Interface (JNI) [7] is a powerful feature of the Java platform.
- Applications that use the JNI can incorporate native code written in programming languages such as C and C.
- as well as code written in the Java programming language.
- The JNI allows programmers to take advantage of the power of the Java platform, without having to abandon their investments in legacy code.
- Because the JNI is a part of the Java platform, programmers can address interoperability issues once, and expect their solution to work with all implementations of the Java platform.
- As a part of the Java virtual machine implementation, the JNI is a two-way interface that allows Java applications to invoke native code and vice versa which is illustrated in.
- Java applications call native methods in the same way that they call methods implemented in the Java programming language.
- Native applications can link with a native library that implements the Java virtual machine, and then use the invocation interface to execute software components written in the Java programming language.
- For example, a web browser written in C can execute downloaded applets in an embedded Java virtual machine implementation.
- RTSJ Real-Time Specification for Java (RTSJ) [3] is one of technologies in Project Mackinac - the first commercial implementation by Sun Microsystems of JSR-1.
- Its purpose is to provide a real-time implementation that meets the stringent needs of real-time developers while continuing to offer all of the other advantages of the Java programming language.
- RTSJ supports both hard real-time and non-real-time functionality in a single system based on the Java Hotspot platform.
- The RTSJ makes several modifications to the Java specification in order to make true real-time processing possible.
- The RTSJ represents important technological advances in the following six areas.
- Scheduling · Memory Management · Synchronization · Asynchronous Event Mechanism · Asynchronous Transfer of Control · Physical Memory Access The sixth is the one that real-time developers expect and demand in a real-time system.
- 1) Memory management The trends in real-time development suggest that in the future, real-time applications will, in fact, become mixed applications, with various threads running in the hard real- time (HRT), soft real-time (SRT), and non-real-time (NRT) zones, depending on the degree of temporal control needed in each case.
- In the C/C++ world, memory management is done manually.
- The Java garbage collector handles this task on behalf of the application.
- Developers of non-real-time applications derive a great benefit from the garbage collector, which saves programming time and makes applications more reliable.
- The entire contents of the application-defined heap goes out of scope as soon as the application completes the run() method.
- As soon as it goes out of scope, all of the memory objects in the application-defined heap are destroyed instantaneously.
- unlike scoped memory, however, memory objects created in immortal memory remain in memory for the duration of the application, even if there are no references to them.
- What makes SRT “soft real-time” is that threads in this zone do take advantage of automatic garbage collection? However, the SRT garbage collector must be able to interact with the application in order to avoid interfering with the predictability of the real- time applications running in the SRT zone.
- 2) Physical memory access The PhysicalMemoryManager is available for use by the various physical memory accessor objects to create objects of the correct type that are bound to areas of physical memory with the appropriate characteristics – or with appropriate accessor behavior.
- In this case, the implementation of memory filters may detect conflicts and throw a MemoryTypeConflictException, but since filters are not part of the normative RTSJ, this exception is at best advisory.
- As a result, we propose a structure for embedded software which integrates advantage of C, C++ and Java languages.
- This structure includes two parts: lower stream written in C and upper stream written in Java.
- Upper stream written in Java native interface native interface.
- written in C.
- written in C Lower.
- The structure for embedded software.
- The upper stream is written in Java so it is platform independence.
- The architecture of the upper stream is very important, because it affects reusability and easy maintenance.
- JNI technology is used to connect these two parts of the structure.
- If embedded system is a real-time system, RTSJ is used for upper stream – written in Java.
- This structure is better than classic embedded software structure where using only C/C++ languages.
- In the structure we propose, upper stream is platform portable while lower stream is not.
- The lower stream written in C/C++ calls the APIs to control the device.
- We only have to search the SDK of the device and write the native functions that do the same tasks, called by JNI.
- The process to develop embedded software The process to develop embedded software we proposed in this paper follows the above structure for embedded software.
- The process to develop embedded software..
- Most of embedded software is still written in C/C++ so this is the store of legacy software source codes which have features controlling the device.
- We can search them in the device manufactory home page, or in other developer pages.
- Step 2: Analyze source code and find out the Bottom APIs of this program.
- The important task of this step is to find out the APIs in the lower layer of this program which access the device or Operating System (OS.
- These Bottom APIs are written in native code (C/C.
- It is not necessary to use all the Bottom APIs in the lower stream.
- To grasp the structure of the program, we should wade through the program documents or developer site of this program.
- We can use the function called graph of the program to do this task other than walking through the source code.
- We have found one called luvcview in the open source site http://developer.berlios.de.
- Based on proposed approach, we analyzed source code and found the Bottom APIs of this program.
- Case Study 2: In the beginning, we have suggested to choose MPlayer or Gnash for our implementation.
- Controller class defines the functions that init, turn on/off, and adjust volume of the sound card.
- AVIPlayer class has a WAVPlayer to play the audio in the video file.
- Another difficulty in the constructing step is the synchronization of the audio and video player as garbage collector in Java is called automatically.
- Table 1 shows the comparison in size of source code (in Line Of Codes – LOCs) for some main modules between Luvcview – source device control program written in C and QCamUvc – target program we have developed based on our supposed structure and process.
- Table 2 shows the comparison in size of source code between XAnim – source movie player program written in C and JNIXAnim – JNI version for XAnim.
- Comparison in size of source code between XANIM and JNIXANIM.
- Some definitions of Java for embedded and real-time systems do exist.
- Furthermore, as Java 2D and JMF are written in only Java, they are not as effective and high performance as using native code to access the devices.
- However, our solution for this problem here is using RTSJ for real-time aspect.
- The report [14] proposes some techniques for integrating native code, typically written in C or C.
- JNI allows Java code that runs inside a Java Virtual Machine to interoperate with applications and libraries written in other programming languages.
- We can reuse effectively legacy code written in languages such as C or C++ and the result programs have both advantages of C/C++ and Java.
- We have proposed the structure and the process to develop embedded software.
- In the structure we have proposed, upper stream is platform portable while lower stream is not.
- The proposed structure separates the dependent and independent part of embedded software and rejects the large part of platform independence.
- Therefore, the embedded software is partial platform portable.
- In this paper, we have made some comparisons in size of source code between source programs written in C and our implemented programs written in Java and JNI based on the proposed structure and development process of embedded software.
- Size of source code of target implemented programs is much smaller than source program because of reusability of the upper stream written in Java..
- Our implementations obviously use less memory than others because of the efficiency of C source code to control program in lower stream of our structure.
- One of the most important tasks in the proposed process is the separation of the Bottom APIs from C/C++ source code.
- In the future, we expect to do further optimization of the process that is responsible for translation from native code to the Java application using some technical optimizing performance of JNI.
- We also continue researching embedded real-time systems with RTSJ technology.
- Lee, “Embedded Software”.
- [2] Alberto Sangiovanni-Vincentelli, Grant Edmund Martin, “A Vision for Embedded Software”.
- [3] Project Mackinac, “The Real-Time Java Platform”.
- In Real-Time Magazine .
- [7] Sheng Liang, “The Java Native Interface - Programmer’s Guide and Specification”.
- Beebee, Jr., Martin Rinard, “An Implementation of Scoped Memory for Real-Time Java”.
- [13] Stephan Korsholm, Philippe Jean, “The Java Legacy”.
- In Proceedings of the 5th international workshop on Java technologies for real-time and embedded systems, Vienna, Austria, 2007, p187.
- [15] Martin Schoeberl, “Restrictions of Java for Embedded Real-time Systems”.
- In Proceedings of the Seventh IEEE International Symposium on Object-Oriented Real-Time Distributed Computing (ISORC’04), May, (2004) 93.
- Real-Time Magazine