NesJ: a translator for Java to NesC

Transcription

1 NesJ: a translator for Java to NesC Jiannan Zhai, Luyao Cheng School of Computing, Clemson University {jzhai, luyaoc}@clemson.edu Abstract Most sensor network research is based on how to program applications which can run efficiently on restraint resource restrained motes. Without a doubt, TinyOS [6], the most widely used platform, is outstanding in doing this. It balances between performance and system resources. However, programming in NesC [4], which is the language used in TinyOS, results in fragile systems that are hard to learn, program, debug and manage. Meanwhile, Java is a popular Object-Oriented programming language, widely used by a large number of programmers. In this paper, we present NesJ, a source-to-source translation system that translates constrained Java code to NesC code. This makes even large scale sensor networks easy to program, debug and maintain with lowest performance loss. NesJ allows users to organize their software systems with OO programming characteristics. It provides a pre-defined set of interfaces and classes libraries, with the help of it, users can do their job in a easier way. NesJ converts any Java source code to NesC source code and compile it using TinyOS compiler. Index Terms NesC, Java, source-to-source translator, objectorientednesc, Java, source-to-source translator, object-orientedn I. INTRODUCTION TinyOS is an open source operating system designed specifically for embedded wireless sensor networks(wsn). The component-based architecture, TinyOS makes it possible to reduce the code size which is limited by the memory constraints of wireless sensors [9]. Good scalability, small code size and well managed power consumption make TinyOS the most important operating system in WSN research. While we cannot give up the benefits of TinyOS, meanwhile the shortcomings of NesC are obvious, it is hard to learn, to program though, and inconvenient to debug because of its split-phase language structure. A good way to overcome these downsides is to allow programmers to program in a popular language and then translate the code to NesC code. This would make it easier for programmers to code for WSNs even if they are not familiar with NesC. In this paper, we present NesJ, a translator that is capable of translating Java code to NesC code. It is structurally similar to a compiler, but instead of resulting in a compiled binary, it generates valid NesC source code from Java code. NesJ makes considerable use of important compiler theory concepts. Java and NesC have different grammar structure and being able to translate from one language to another could save development time and save money. Additionally, if such translation is done by hand, it may be error prone. NesJ is a console application that as input the names of Java files to translate along with a few command line parameters. NesJ is written in Java, and all its data structures Java Java Fig. 1. NesJ Fig. 2. Java to bytecode Compiler system overview NesC to bytecode NesJ system overview bytecode bytecode are implemented as Java objects. As shown in Fig. 2, a compiler system should directly translate from source code to binary code. But in a system that contains NesJ, as in Fig. 1, NesJ plays an intermedia translation layer in the whole process, translating from Java source code to NesC source code. Some challenges faced with providing the intermedia translating function are 1) how to map all the language features in NesC to unique Java features. 2) How to convert Java source code that is written under our framework to NesC source code. We overcome these challenges by using some helpful Java features. Across the board, the following were regarded as good points of Java that could be exploited in translation: Strong typing Isolated memory management and garbage collection Java dynamic method dispatch Interfaces Exceptions A third-party library named Eclipse Java Development Tools(JDT) is used to analyze our structured Java source code, so that we can accurately construct the NesC data structure to generate corresponding NesC code. About JDT, we will discuss in the rest of the paper. In order to be confident that NesJ works, multiple levels of testing have been implemented. These levels include unit tests for the data structures and translation steps, end-to-end system tests that are tested against standard Java and NesC compilers, and finally a real world test of translation against the code for the translator itself. Currently NesJ is able to convert only a subset of the NesC language construct from Java. These limitations are acceptable due to NesJs scope as a thesis project. With

2 Class Parser If Parser For Parser DoWhile Parser Java Class Container Class Table Makefile Builder Block Parser Method Parser While Parser Java Code AST Constructor Abstract Syntax Tree AST Parser Intermediate Data Structure Header file Builder Configuration ImplementationBuilder Fig. 3. NesC Builder NesC Code NesC Interfaces Used Class Table Configuration Builder Statement Parser Variable Parser Expression Parser Method Invocation Parser Assignment Parser Module Builder Module Implementation Builder System Overview further development, NesJ could support a large number of NesC constructs and provide more sophisticated levels of code translation. II. RELATED WORK David and Levis et al. [4] introduce a totally new programming language, NesC, which is responsible for embodying Tinyos architecture. NesC is an extension to the C programming language. It is also a component-based programming language, making it possible to reduce the code size limited by the memory limitation of wireless sensor motes. Jason Hill et al. [6] summarize some important features that a future wireless sensor network should have, including, low-power consumption, low-cost, small physical size and a short development cycle. They introduce TinyOS, an eventdriven operating system. In their paper, they also introduce a hardware chip that they designed. The hardware with TinyOS installed is driven by task, if there is no active task, the chip should keep on sleeping. This can largely save energy for wireless motes. They predicated that future wireless sensor network will be occupied by this low-power motes and these techniques are evaluated by several cases. The reality has proved that Jason Hill is right. Tinyos has occupied almost the whole field of wireless sensor network research. But as we can see, NesC which is an event-driven language to embody Tinyos architecture, while object-oriented programming language is becoming a main stream. So we want to find a OO programming way to make it easier do the work on Tinyos. Loveman and David B. [7] present some theories in sourceto-source translation process. They claimed they can use turing machine to manipulate translator to change a programming language code to another language code, and the new language code can be more convenient accepted by human beings. They predicated that their system can save developers up to 30% time to finish the programming with their system and they gave a description of the application of these ideas to an existing programming language. Before Loveman and David, Buddrus et al. [3] designed and implemented an automatic translator from C++ source code to Java source code. This translator not only performs lexical, syntactic and limited forms of semantic analyses on the source code, but it also recovers from any errors encountered. It was implemented in C programming language and can be treated as a compiler-like translator. Banbara et al. [2] present the Prolog Cafe system that translate Prolog into Java via the WAM. Because A Prolog Cafe thread seems like conceptually an independent Prolog evaluator and communicates with each other. This behavior makes Prolog Cafe very similar to Java. They claim that Prolog Cafe also has the advantages of portability, extensibility, smooth interoperation with Java, and modularity. Gnawali et al. [5] find that it is so difficult to program with nesc, because nesc s event driven programming feature makes fragile system that is difficult to code and manage. So they present a system named tenet to simplify the development process. The tenet system has a library that allows users to compose their program with simple commands. Each single line command represents a functionality in nesc, like Leds toggle or send message through radio. It is a good way to simplify development process, but gives little free space to users. Like the work above, our work concentrates on an sourceto-source system to improve the programming process on Tinyos. III. SYSTEM DESIGN AND IMPLEMENTATION Before delving into the design details, we briefly present translation principle that we consider. The most important and difficult issue of this project is how to map Java features to NesC features. Because Java has a relatively complex programming rules, we select a subset of its features by

3 Java Primitive short int long boolean boolean true false true false synchronized NesC Primitive uint8 t uint16 t uint32 t bool error t TRUE FALSE SUCCESS FAIL atomic TABLE I PRIMITIVE VARIABLES MAPPING Boot Leds Timer Milli Boot MainC Leds LedsC Timer<TMilli> TimerMilliC Interface Translator Boot Translator booted event command event command Leds Translator led0toggle... Timer<TMilli> Translator fired event introducing a set of constraints to users. Table I presents a mapping from Java primitive variable type to NesC primitive variable type. Fig. 3 shows the overview of the whole NesJ system design and we can see that the whole system is seperated into several layers. We will discuss each of them in the details in the following subsection. The full name of AST is Abstract Syntax Tree, it is one parsing function within JDT. We are using it in our program as the first layer parser. A. Translation Priciples (1) Primitive Mapping: We map the primitive types in NesC to primitive types in Java. As show in Table. I (2) NesC Interface Mapping NesC has a big interface library. When programmers write code in NesC, they need to choose the right interfaces, wire them with components and build them together to make the program work. We still need to provide the same flexibility to users to choose their own components in Java. Hence, we create a library of pre-defined Java interfaces and classes, each of which corresponds to a NesC interface. The library structure can be seen in Fig. 4. The library structure consists with a table and a set of interface translators. The table stores all the mapping relations from Java Interface to NesC interface and a translator is responsible for each relation handling. We classify the interfaces into three seperated parts as we see in the following subsection. NesC interfaces that only have events. We map Java interfaces to this kind of interfaces. Because in NesC if we use an interface we should implement all of its events. And in Java, if we implements an interface, we should implement all the methods in this interface, just the same with NesC events handler.for example, the NesC interface Boot has only one event, booted. Modules using NesC Boot interface should implement the booted event. We create a Java interface Boot which has one method, booted, so the classes that implement the Java Boot interface or implement the booted method. NesC interfaces that only have commands. We map Java classes to this kind of interfaces, because using a command of Fig. 4. command startoneshoot... Interface Library Structure Overview an NesC interface is similar to calling a method of an instance of a Java class. For example, the NesC interface Leds has eleven commands to control the leds. We create a Java class Leds which has eleven methods, each of which corresponds to a command in the NesC interface Leds. NesC interfaces that have both events and commands. If the methods in Java interfaces and classes respectively correspond to events and commands in NesC interfaces, it is not possible to just map Java interfaces or classes to this kind of interfaces. For each NesC interface having both events and commands, we map one Java interface and one class to it by using the listener pattern [1]. The Java interface contains methods corresponding to the events in that NesC interface. The Java class has methods corresponding to commands in that NesC interface. For example, NesC interface Timer has nine commands and one event, fired. We create a Java interface TimerListener having one method named fired. As shown in Fig. 5, we create a Java class Timer. It has nine methods corresponding to the nine commands in interface Timer and one more method called settimerlistener which accepts a class that implements TimerListener interface. In order to use the interface Timer, the user must implement a Java class containing the Java interface TimerListener and the method fired; Next, the user must create an instance of the class Timer, to use the methods in class. Finally the user should call settimerlistener and pass the class which implements TimerListener. (3) Interface providing: To provide a NesC interface, user

4 Timer Milli Fig. 5. Interface Mapping for Timer Timer<TMilli> TimerMilliC should implement a Java interface Providable. There are also three cases. NesC interfaces that only have events: Create an interface which extends Providable. Each method in this interface will be treated as a NesC event. Then create a class implements this interface and implements the methods in it. NesC interfaces that only have commands: Create a class which implements Providable. Each public method in the class will be treated as a NesC command provided to the user. NesC interfaces that have both events and commands: This is similar to the case that only have event. The only difference is that all the other public methods other than the implemented ones will be treated as commands. (4) Tasks Mapping : A NesC task is very similar to a Java method. However, in NesC the reserved word post is used to insert a task into the task queue. So the task methods should act in a different way compared to the other methods. In NesJ, we create a Java class, TaskManager. This class has one method, settasklist, which accepts a list of strings indicating the name of the methods that will be translated into NesC tasks. In order to use tasks, the user creates an instance of TaskManager and calls the method settasklist, passing the name of methods which the user wants to use as tasks. After the AST constructor constucts the whole data structure of the first layer, NesJ will extract all the methods that have called settasklist method and add the key word post to the beginning of the methods. B. Data Structure Design There are three primary kinds of data structures used in the system. Abstract Syntax Tree (AST) is generated by Eclipse JDT and represents the structure of the Java source code. Intermediate Data Structure (IDS) is the product after extracting tokens from the AST. It contains all the tokens information to build NesC code. Class Tree is an abstraction of a Java class, reflecting the structure of that class. Fig. 6 shows how we implement the Class Tree. All the classes are implemented following Java Bean standard, so we ignore the getter and setter methods here. The Root of a Class Tree instance is a Class instance, which has a list of Statement, containing Variable instances (the fields of this class), and Method instances. Because each Method instance is a BlockedStatement instance, a Class Tree is recursively structured. Java Class Container maintains a tree for each class in the program. Each tree is built from the AST of this class using the AST Parser to discard information is not need, leaving everything useful to build NesC code. NesC Interface Container maintains a list of Java objects for each class in the program. Each Java object in the list represents a NesC interface this class uses. NesC Interface Library is a hash table used to mapping Java interfaces and classes to NesC interfaces. Each key of the hash table is an object containing the name and the argument of a Java Interface or class. Each value of the hash table is an object containing the name of a NesC interface, the name of the module this interface lies in and a pointer to an interface translator in the interface translator table. Each interface translator in the table knows how to translator a Java method invocation to NesC code. For example, the Boot Translator can translate booted method in Java to a NesC event Boot.booted. Variable Table (VT) includes Global Variable Table which stores global variables (fields of classes) and Local Variable Table which stores local variables in methods. The NesJ System consists of three layers: AST Constructor, AST Parser, NesC Builder. These three layers are loosely coupled. Once one layer finishes processing the data, it passes the data it generates to the next layer and will never be called again. Therefore, a very important job is to design the data structures which flow through the layers, as we shall see later. AST Constructor accepts a Java source file, (typically contains one Java Class, but this class may contain one or more inner classes). Next the AST Constructor uses a third party library, the Eclipse Java Development Tools (JDT), to access the Java Source Code and construct its Abstract Syntax Tree (AST). Each node in AST is represented by a class in JDT. AST Parser accepts the AST generated by AST Constructor and builds the IDS by extracting and formatting all the information it need from the AST. AST parser has two primary components, Blocked Structure Parser and Statement Parser. Block Structure parser parses the Java structures which have blocks, for example, a while structure. It contains different parsers for different structures, for example, the while parser is used to parse Java while structures. JDT uses the visitor pattern [8], providing an easy way to access the nodes in AST. It visits special nodes in the sub tree of a specific parent node. Since the parent node is a method declaration node, we can just visit the variable declaration nodes that are in the sub tree of the parent node. The purposes of the AST Parser Layer are: parse an AST, build a Class Tree based on the information extracted from the AST; extract the NesC interfaces the program uses, insert the interfaces into NesC Interface Container. The parsing process is a recursive process. The first node we visit is a class node for it is the root of an AST. So, we start with the Block Parser. A block contains several statements and blocks. When encounter a statement, parse this statement with Statement Parser and go back to the beginning of the parsing process. When encounter a block, parse the information of this block and recursively go to the Block Parsing Process.

5 Fig. 6. Class Tree Structure 1. Statement Parser can be devided into four kinds. Variable Parser checks the variable type (primitive, array or class instance), creates a Variable instance based on the type and stores this instance into the Variable Table. Assignment Parser finds Variable instance from the Variable Table using the name of the variable and sets the value of this variable. Method Invocation Parser parses the instance which invocates the method, the name of the method, the arguments passed to the method and stores them into a MethodInvocation instance. Expression Parser parses the operands and the operator of the expression and stores them into an Expression instance. 2. Block Parser. The main idea of the Block parser is recursion. It parses the information of the block (for example, While Parser parses the condition of a while loop) then calls the Block Parsing Process to parse the body of this block. The input of the AST parser is an AST generated by Eclipse JDT. This AST provides a visit pattern interface to access all the nodes. To visit the nodes in this AST, user should use a visit pattern, which is not comfortable to use and the structure of the data is not suitable for the translation. For example, a very common Java assignment statement: int a = 10; We should use the Variable Declaration Visitor to visit this statement node, and from this node we need to use the Simple Type Visitor to visit int, a, = and 10 separately. Therefore, we define our own data structure to store the program information. For the example above, we define a class PrimitiveVariable to primitive variables. An instance of PrimitiveVariable would have type int, name a and value 10. Statement Parser parsers the Java structures which have no blocks, for example, a class instance creation statement. It contains different parsers for different statements, for example, the Class Instance Creation parser is used to parse Java class instance creation statements. C. Target Code Builder The end result of the parsing process yields, the IDS layer with all the information of the Java program has been built. The only thing we need to do now is assembling the data into a valid NesC source code, which is achieved by Builder layer. The Builder layer is responsible to assemble target code. This layer consists with three kinds of builders. Aaa The table that can translate Java function to nesc function. NesC Builder accepts the Intermediate Data Structure as input and translates the data into NesC code. It contains six components. Makefile Builder scans all classes in the NesC Interfaces Used class table, find the class which implements the Boot interface. The Makefile Builder treats that class as the entrance of the NesC program and generates the Makefile based on that class. Header file Builder scans all classes in the NesC Interfaces Used class table, find each class (this class should follow Java Bean standard) which implements the Message interface. a.the Header file Builder extracts all the fields in this class and translates these fields into N version using the statement translator. The translated fields then will be encapsulated into a nx struct definition. b.the inner should implements setamradiomsgid method and return an integer which will be encapsulated into enum structure of nesc.

6 Configuration Builder checks the implemented interfaces of a class. If this class implements the interface Providable, or the interfaces this class implements implement the interface Providable, this class will be translated as a module providing an interface. The builder builds the NesC configuration using the class name as the interface name. Configuration Implementation Builder builds an implementation of configuration for each Java class. It scans all classes in the NesC Interfaces Used class table. For each class, the builder gets the Java interface object (This object contains the name of the class it uses or the interface it implements, the arguments for of the class it uses to create an instance of that class.) list of this class. Each Java Interface Object corresponds to an interface in nesc library. For one Java Interface Object, the builder looks up the corresponding nesc interface object (This object contains the name of the interface, name of the module this interface lies in and the alias name of this interface if it has one) from the Nesc Interface Library Table. Then the builder could do the wiring using the two objects. For example, The Java Interface Object with name Timer and argument Milli corresponds to the nesc interface Timer TMilli in module TimerMilliC. Module Builder checks the NesC interfaces used in a class by scanning the NesC Interfaces Used class table and builds the uses interface part. Then it checks if this class or its interfaces implement the interface Providable, and builds the provides interface part. Module Implementation Builder builds the NesC module implementation by translating the Java Statements into NesC code. The module implementation is also a recursive process. It scans all the Class Trees in Java Class Container. For each Class Tree, it sans all the statements this Class Tree has. For a SingleStatement, it builds NesC code based on the Translation Principles described in section x and find the translation in the library. For a BlockedStatement, it recursively calls the process. IV. CASE STUDY In this section, we present two programs, Blink and Sensor, written with our Java framework. We will present how to program using NesJ framework step by step. And then we will translate them into corresponding NesC code and compile them into binary. Finally we will give a comparation of development efficiency between nesc code and nesj code. All the code was written in Java Eclipse and compiled by 1.6. A. Blink (1) As we can see in figure 7, first we create a class called BlinkC.java, since we need Boot interface, we implements Boot. And within the global field, we declare three Timer Fig. 7. Fig. 8. Blink Class Definition Blink Field Declaration objects with parameter Timer.TimerType.MILLI. This parameter means the interface should be wired with component TimerMilli (Of course, NesJ system will do the wiring for the users). A Leds object is also being declared within the field. (2) Then in figure 8, we can see that method booted, which is the member function of interface Boot, is implemented. This step corresponds with event method definition in NesC. Within the method, the three Timer objects call their member functions, just like in NesC. One step that NesC code does not have is timer0.setfiredeventhandler(new Timer0Handler()), this tells NesJ system to find an inner class called Timer0Handler to set up timer0 s events. (3) Finally in figure 9, three inner classese are defined. They all implement FiredEventHandler interface, and have defined method fired(). The method will be taken by NesJ system to replace corresponding object. For example, when NesJ system gets the information in booted() method that the user sets timer0.setfiredeventhandler(new Timer0Handler()). NesJ replaces the inner class with all the member functions of inner class, adds object s name to the methods and output to the users. figure 10 is the nesc code generated by NesJ system. B. Sensor Next, we will see another program which is a little more complicated than the former one. (1) As in figure 11, a class named Read.java is created, since we need Boot interface, we implements Boot. And within the global field, we declare a Timer object, a TemperatureRead object which is responsible for temprature sensor component on tinyos and a Les object. The data array is declared in order to store all the temperature data from temperature reader and iterator is the pointer to current position in the array. (2) Then in figure 12, we can see that in booted(), the

7 Fig. 11. Sensor Class Definition Fig. 9. Blink Event Handler Definition Fig. 12. Sensor Field Declaration Fig. 10. BlinkC.nc Generated by NesJ V. CONCLUSION NesJ optimizes the process of developing for Tinyos. In this paper, We described the data structure, system design and implementation and provide two case studies of the NesJ. Althogh there are many differences between Java and NesC, the former one is object-oriented language while the later one is phase-slitted language, we still can find the unique mapping between each feature of these two languages. Future work is now proceeding on adding all the interfaces of NesC into NesJ s interface library. We need to do some effort on allowing users to use their own defined class objects. Now NesC supports providing an interface whose commands and events are implemented by the module. Providing an interface whose implementation of commands and events are wired to other modules is including in future work. And now, our project supports for the users to provide only one interface within a single module. Future work will work on this. methods of the objects are being called. Now we should write the body of each event handler class. (3) In figure 13, fired() and readdone() events are implemented. In fired(), the temperature reader is being called in for loop for ten times every trigger and in readdone, the result of the temperature data is stored into the array and start the next time cycle. The Java primitive type is transformed to NesC primitive type. Figure 11 shows corresponding source code generated by NesJ. We next evaluate the improvement of NesJ framework code. After comparing with NesC source code, we find that all the components are being treated as objects in NesJ framework code. The event functions are no longer treated as a common function, instead, they appeared in the form of interface methods. Users are constrained to implement event methods of a component. Also, users do not need to care about the wiring, which can save developer s time and money. Fig. 13. Sensor Event Handler Definition

8 Fig. 14. SensorC.nc Generated by NesJ REFERENCES [1] Observer pattern. [2] M. Banbara, N. Tamura, and K. Inoue. lt;span style= font-family:sansserif gt;prolog cafelt;/spangt;: A prolog to java translator system. In M. Umeda, A. Wolf, O. Bartenstein, U. Geske, D. Seipel, and O. Takata, editors, Declarative Programming for Knowledge Management, volume 4369 of Lecture Notes in Computer Science, pages Springer Berlin / Heidelberg, / [3] F. Buddrus and J. Schödel. Cappuccino a c++ to java translator. In Proceedings of the 1998 ACM symposium on Applied Computing, SAC 98, pages , New York, NY, USA, ACM. [4] D. Gay, P. Levis, R. von Behren, M. Welsh, E. Brewer, and D. Culler. The nesc language: A holistic approach to networked embedded systems. SIGPLAN Not., 38:1 11, May [5] O. Gnawali, K.-Y. Jang, J. Paek, M. Vieira, R. Govindan, B. Greenstein, A. Joki, D. Estrin, and E. Kohler. The tenet architecture for tiered sensor networks. In Proceedings of the 4th international conference on Embedded networked sensor systems, SenSys 06, pages , New York, NY, USA, ACM. [6] J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. Culler, and K. Pister. System architecture directions for networked sensors. SIGPLAN Not., 35:93 104, November [7] D. B. Loveman. Program improvement by source to source transformation. In Proceedings of the 3rd ACM SIGACT-SIGPLAN symposium on Principles on programming languages, POPL 76, pages , New York, NY, USA, ACM. [8] B. C. Oliveira, M. Wang, and J. Gibbons. The visitor pattern as a reusable, generic, type-safe component. SIGPLAN Not., 43: , October [9] C.-Y. Wan, S. B. Eisenman, and A. T. Campbell. Energy-efficient congestion detection and avoidance in sensor networks. ACM Trans. Sen. Netw., 7:32:1 32:31, February 2011.