International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print),

ISSN 0976 - 6375(Online), Volume 5, Issue 7, July (2014), pp. 01-10 IAEME
1











ONTOLOGY BASED JAVA PLATFORM PERSONALIZATION TO HOST
ENVIRONMENT


Sinan Adnan Diwan Alwan
1, 4
, Dr. Enas Hadi Salih
2
, Ammar J.Fatah
3


1
Wasit University, College of Computer and Mathematics, Computer Science dept.,
Wasit, Republic of Iraq

2
Head of computer Technology Engineering, Alrafedain University College
3
Science Gate, Virtual Research Center, System security dept.
4
Limkokwing University of creative technology, information systems department, cyberjaya,
Selangor, Malaysia




ABSTRACT

This paper presents a personalization platform to adapt Java based applications to Host
Environment; this is to converge the performance and reliability toward platform dependant (e.g.,
like C++). Intelligent Java agent is designed to perceive Host Environment and embed Java Native
Interfaces (JNI) to Java program at Byte Code level. Intelligent Java agent scans host machines for
low level libraries; which are normally DLL (Dynamic Link Library) files, and list them in table.
The personalized program is executed at two performance levels, first level is the impersonalized
level (i.e., not handled by the agent) which is low performance and the second is the personalized
level which is the high level in term of performance due to injecting JNI interfaces

Keywords: JRE, JVM, JNI, Personalization, Ontology, Agent, Java Byte Code.

1. INTRODUCTION

The Java platform is a programming environment consisting of the Java virtual machine
(VM) and the Java Application Programming Interface (API).
Java applications are written in the Java programming language, and compiled into a
machine-independent binary class format. A class can be executed on any Java virtual machine
implementation. The Java API consists of a set of predened classes. Any implementation of the
Java platform is guaranteed to support the Java programming language, virtual machine, and API.[ 1]
INTERNATIONAL JOURNAL OF COMPUTER ENGINEERING &
TECHNOLOGY (IJCET)



ISSN 0976 6367(Print)
ISSN 0976 6375(Online)
Volume 5, Issue 7, July (2014), pp. 01-10
IAEME: www.iaeme.com/IJCET.asp
Journal Impact Factor (2014): 8.5328 (Calculated by GISI)
www.jifactor.com

IJCET
I A E M E
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print),
ISSN 0976 - 6375(Online), Volume 5, Issue 7, July (2014), pp. 01-10 IAEME
2

In this paper, the term host environment represents the host operating system, a set of native
libraries, and the CPU instruction set. Native applications are written in native programming
languages such as C and C++, compiled into host-specic binary code, and linked with native
libraries. Native applications and native libraries are typically dependent on a particular host
environment. A C application built for one operating system, for example, typically does not work on
other operating systems.[ 1][2]
Java platforms are commonly deployed on top of a host environment. For example, the Java
Runtime Environment (JRE) is a Sun product that supports the Java platform on existing operating
systems such as Solaris and Windows. The Java platform offers a set of features that applications can
rely on independent of the underlying host environment.[ 1]
The Java Native Interface (JNI) 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.[1][2][3]
The JNI is a powerful feature that allows you to take advantage of the Java platform, but still
utilize code written in other languages. 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. Figure 1
illustrates the role of the JNI.[1][2]
Personalization is the science of altering multi-user software product behaviors or attributes
according to the preferences of individual, yet maintaining the performance and the standards
according to the multi-user software product has been designed in the first place.
The act of personalizing platform; offering user-specific customization; the act of changing
an option of a multi-user software platform product to change the product's behavior or style for one
user
This paper will deploy personalization concepts to adapt Java platform (i.e. Java Runtime
Environment) to host platform, the outcome of this deployment will enhance the overall performance
of java programs and increase the accessibility of java programs to local host resources.

2. JAVA VIRTUAL MACHINE & JAVA RUNTIME ENVIRONMENT

Due to the fact that personalization is so related to destination architecture a deep knowledge
is required about internal java virtual machine architecture. This section is going to present the
internal architecture in bit of details to conceptualize later the proposal.
At the heart of the Java platform lays the Java Virtual Machine, or JVM. Most programming
languages compile source code directly into machine code, suitable for execution on particular
microprocessor architecture. The difference with Java is that it uses bytecode - a special type of
machine code. [4]
Java bytecode executes on a special type of microprocessor. Strangely enough, there wasn't a
hardware implementation of this microprocessor available when Java was first released. Instead, the
processor architecture is emulated by what is known as a "virtual machine". This virtual machine is
an emulation of a real Java processor - a machine within a machine Figure (1). The only difference is
that the virtual machine isn't running on a CPU - it is being emulated on the CPU of the host
machine. [4]
Java Runtime Environment (JRE) is a Sun product that supports the Java platform on existing
operating systems such as Solaris and Windows. The Java platform offers a set of features that
applications can rely on independent of the underlying host environment.[1 ]

International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print),
ISSN 0976 - 6375(Online), Volume 5, Issue 7, July (2014), pp. 01-10 IAEME
3

Figure 1: Java Virtual Machine is emulation within Physical Machine














The Java Virtual Machine is responsible for interpreting Java bytecode, and translating this
into actions or operating system calls, as in Figure 2, Java source code passes through two stages (
compile and interpret) before getting executed on physical CPU. The intermediate form is the
ByteCode which is a set of instructions known only by Java Virtual Machine (JVM). JVM is
executing ByteCode in the same manner as real CPU is executing instruction set through fetch-
execute cycle and the output will machine code that is executable by local host physical machine
For example, a request to establish a socket connection to a remote machine will involve an
operating system call. Different operating systems handle sockets in different ways - but the
programmer doesn't need to worry about such details. It is the responsibility of the JVM to handle
these translations, so that the operating system and CPU architecture on which Java software is
running is completely irrelevant to the developer.[4]

























Physical Machine

Java Virtual
Machine
Java
Application
s
Virtual
Instruction Set
Native
Applications
Physical
Instruction Set
Figure 2: Java source passing through java compiler and java interpreter
Java
compiler
(x86)
Java
compiler
(PowerPC)
Java
compiler
(SPARC)
.Class
Java
Interpreter
(x86)
Java
Interpreter
(PowerPC)
Java
Interpreter
(SPARC)
Javac.exe Javac.exe bytecode
Java source
code
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print),
ISSN 0976 - 6375(Online), Volume 5, Issue 7, July (2014), pp. 01-10 IAEME
4
The need for Java applications to interoperate with native code has been recognized since the
very early days of the Java platform. The rst release of the Java platform, Java Development Kit
(JDK) release 1.0, included a native method interface that allowed Java applications to call
functions written in other languages such as C and C++. Many third-party applications, as well as the
implementation of the Java class libraries (including, for example, java.lang, java.io, and java.net),
relied on the native method interface to access the features in the underlying host environment.[1]
Figure (3) depicts the interaction mechanism between java byte code and machine dependant
code generated from included third party. This figure is crucial to be understood in order to
determine place of action for the personalization.










































Create a class
that declares the
native method
Use javac to
compile the
program
Use javah to
generate
header file
Write the C
implementation
of the native
method
Compile C code
and generate
native library
Run the program
using the java
iterpreter
Application.java
Application.class
Application.h
Application.c
Application.dll
Native Application
Figure 3: building Java Native Interface Application
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print),
ISSN 0976 - 6375(Online), Volume 5, Issue 7, July (2014), pp. 01-10 IAEME
5

3. ONTOLOGY

Ontology is originally a philosophical discipline which deals with the study of being and
existence. The term is borrowed to computer science and defined as an explicit specication of
conceptualization [13], which specifies the set of concepts that will be used in a particular system as
a basis for communication or sharing of information. In particular, ontology is an important
component in the Semantic Web [2].
An ontology generally consists of a taxonomy of concepts, a set of relations, a set of
individuals (representing real objects), and possibly a set of inference rules for discovering of
implicit knowledge [2]. formally ontology O can be defined as a four-tuple O = (C,P,I,R), where C
is a set of concepts, P is a set of properties, I is a set of data instances, representing real objects in the
domain of interest, and lastly R is a set of rules, propositions or axioms that specify the relations
between concepts and properties.
The proposal of this paper has the following interpretation for the components of the
ontology:

C: is the basic concepts within the model and here it represents marked block of code, where
the program code can be treated as a series of marked block of code.

P: properties of the block of code for example its length in byte and addressing mode are
properties of code block.

I: Instances of code block for example functions can be instantiated many times in a program.

R: relationships between code blocks for example INVOKE relationship is assigned to code
block invoked by other code.

4. CHALLENGES

The challenges in implementing tasks in native or in standard java depends on the availability
of native libraries installed in the system

1- Mining java program at byte code level which needs dedicated ontologies to conceptualize

2- Mining system files at execute level (Portable Executable format)

5. THE PROPOSED PERSONALIZATION SYSTEM

The proposed technique is to build Java Agent that capable of perceiving concepts in Java
Byte code domain which is stored in separate class file (i.e., .jar or .class), the ontology used to
define these concepts will be specially designed to do this task.
Java Agent ultimate goal is to map perceived concepts in java byte code to its analogous in
native library (i.e., .dll, .exe, .ocx) as in figure (4)






International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print),
ISSN 0976 - 6375(Online), Volume 5, Issue 7, July (2014), pp. 01-10 IAEME
6




The proposed technique passes through two phases, the first phase is with no mapping entries
exist in the updated log file, this log file will serve as a direct mapping pointer, the agent will check
the validity of the code referred by this pointer to sustain the mapping.
Java Agent will start looking inside dll files to explore for analogous code that matches Java
byte code, the data will be isolated to keep it out of the mapping, in phase one a log file will be built
to enhance the mapping function and to not mining again for requested functions.
Figure (5) shows the architecture of personalization Java Byte code in phase one












When phase one is finished the personalization Agent will direct the dispatcher of the
operating system to the native code in dll rather than send it to Java Virtual Machine as in figure (6)
Figure 4: Java Agent Maps Java Byte code to binaries in dll file
Figure 5: Java Agent is building Mapping table in phase one
Log File
.Class
Native Libraries
( Binary images)
Network component
Java Agent
Byte code Ontology
Phase One
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print),
ISSN 0976 - 6375(Online), Volume 5, Issue 7, July (2014), pp. 01-10 IAEME
7



















Tc = Time to compile Java source code
Tp = Time to interpret Java Byte code
Tb = Time to execute binary code
Texe = Time to execute Java Program
Texe = Tc + Tp this is without personalization
due to the fact that binary code is executed directly, and the following equation is
describing the proposed system with personalization

It is obvious that when is small then the overall performance of the system is is going high. Figure
(7) presents the machine code corresponding 'printf' c language function compiled using visual studio
6.0.



















Central
execution unit
J
a
v
a

V
i
r
t
u
a
l

m
a
c
h
i
n
e

J
a
v
a

I
n
t
e
r
p
r
e
t
e
r

Native Libraries
(Binary images)
Personalization
Agent
.Class
Figure 6: Java Agent is mapping byte code to native in phase two

Figure 7: Java Agent perceived requested machine code
Phase Two
Agent check if requested
code is in native library or
not.
Call code from
native library
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print),
ISSN 0976 - 6375(Online), Volume 5, Issue 7, July (2014), pp. 01-10 IAEME
8
In the same manner corresponding byte code will be perceived in java class file, the example
taken by this paper is simple and contains only 'println' which is part of 'System.out' class. Figure (8)
presents a screen shot of bytecode viewer which has been used to reveal the byte code image of
'System.out.println' method.




















each found member function in java class file that has a analogous native representation will be
marked as comment and a method added with the name 'mXxx' where Xxx is the name of the
member function to be implemented as native code.
Figure (9) presented the resultant of applying personalization concepts on java class file
called 'Hello.class' built to be an example for the personalization.























Figure 8: Bytecode viewer presents java byte code of System.out.println
Figure 9: Hello.class has been personalized and native keyword has been added
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print),
ISSN 0976 - 6375(Online), Volume 5, Issue 7, July (2014), pp. 01-10 IAEME
9
Personalization ratio (personalized java / original java) is not fixed along different categories
of programming classes; this is shown in table-1 where different categories have been tested.

Table -1-
Personalization rate for different programming categories
I Java SLC Category Personalized rate
1 137 402 Consol 73% 331
2 214 309 Form Based 68% 290
3 180 553 Network 69% 440
4 167 506 Data base 37% 481
5 179 613 Graphics 53% 413
6 165 585 Multi-threading 76% 335

Figure (10) presents a discrimination graph between the performance of different
programming categories shown in table-1, which are implemented using java and c# programming
languages.




















The personalization of a java program can be represented by a cumulative function as logistic
function as figure (11) which presents the effect of increasing the source line of code (SLC) on the
overall performance of the personalization.

0
100
200
300
400
500
600
700
java
c#
Figure 10: Performance Chart due to personalization
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-6367(Print),
ISSN 0976 - 6375(Online), Volume 5, Issue 7, July (2014), pp. 01-10 IAEME
10




















6. CONCLUSIONS

1- Java program can be personalized to certain platform according to the interpretation of its
binary images, which represents executable format adopted by that platform. The personalized
java programs showed an increased performance level due to the low level linkages of binary
code; this binary code is hold by DLL ( dynamic link linbrary) files.
2- Java program can be personalized to open source operating systems like Unix and lunix more
easier that windows operating system due to its readability and matching to source code in Java
program.

7. REFERENCES

1- Sheng Liang, "The Java Native Interface, Programmer's Guide and Specification", ADDISON-
WESLEY, USA, 1999.
2- Fabio Bellifemine, Giovanni Caire, Tiziana Tucco and Giovanni Rimassa, "JADE Progammer's
Guide", TILab S.P.A, 2010.
3- Chris H.Pappas & William H. Murray, "The complete Reference visual studio 6.0", McGraw-
Hill, 1998.
4- David Reilly, "Inside Java: Java Virtual Machine", 2006.
5- Abhishek Singh, Identifying Malicious Code Through Reverse Engineering: Portable
Executable File Format, Advances in Information Security Volume 44, 2009.
6- David Reilly, Inside Java: The Java Virtual Machine, accessed at:
http://www.javacoffeebreak.com/articles/inside_java/insidejava-jan99.html.
7- P.Shvaiko, J.Euzenat., Ontology Matching : State of the art and Future Challenges, IEEE
Transactions on Knowledge and Data Engineering, 2013.
8- Pratibha S. Yalagi and Dr. Sulabha S. Apte, Exploiting Parallelism for a Java Code with an
Efficient Parallelization Technique, International Journal of Computer Engineering &
Technology (IJCET), Volume 3, Issue 3, 2012, pp. 484 - 489, ISSN Print: 0976 6367,
ISSN Online: 0976 6375.

0
0.5
1
1.5
2
2.5
3
3.5
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
p
e
r
s
o
n
a
l
i
z
e
d

j
a
v
a

/

j
a
v
a
Personalization Performance
Series1
Figure 10: Performance of personalization as it relates source line code