This paper presents a personalization platform that adapts Java-based applications to their host environments to improve performance and reliability. It introduces an intelligent Java agent that utilizes Java Native Interfaces (JNI) at the bytecode level to integrate low-level libraries, resulting in enhanced execution efficiency. The proposed system emphasizes the importance of mapping Java bytecode to local native code to optimize application interoperability and resource usage.

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
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
1
IJCET
© I A E M E
ONTOLOGY BASED JAVA PLATFORM PERSONALIZATION TO HOST
ENVIRONMENT
Sinan Adnan Diwan Alwan1, 4, Dr. Enas Hadi Salih2, Ammar J.Fatah3
1Wasit University, College of Computer and Mathematics, Computer Science dept.,
Wasit, Republic of Iraq
2Head of computer Technology Engineering, Alrafedain University College
3Science Gate, Virtual Research Center, System security dept.
4Limkokwing 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 predefined classes. Any implementation of the
Java platform is guaranteed to support the Java programming language, virtual machine, and API.[ 1]

2. 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
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-specific 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
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 ]

3. 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
Instruction Set
Javac.exe bytecode Javac.exe
3
Physical Machine
Java Virtual
Machine

4. Java
Application
s
Physical
Virtual
Instruction Set
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]

5. Java source
code
Figure 2: Java source passing through java compiler and java interpreter

6. 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
The need for Java applications to interoperate with native code has been recognized since the
very early days of the Java platform. The first 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.
4

7. !

8. !

9. #
$

10. #