OpenJDK currently does not have support for a JRE on MIPS processors (there's a port in progress, but who knows how long that will take).
I'm trying to understand how the JRE works, and what is standing in the way of using OpenJDK on our embedded system running Linux on a MIPS processor. If I have a custom JVM that is capable of running on MIPS designed to work with OpenJDK (in this case, I'm referring to JamVM 2.0), is there anything else preventing the JRE from running on the MIPS board? Are any other parts of the JRE platform-dependent?
My understanding is that the JRE is (mostly) composed of two units: the virtual machine, which abstracts the hardware and which is platform-dependent, and the collection of Java libraries which run on the virtual machine and which are not platform-dependent.
To be clear, my questions is: aside from the JVM, is any part of the Java Runtime Environment platform-dependent?
"aside from the JVM, is any part of the Java Runtime Environment platform-dependent?"
That depends on where you place the boundary where the VM ends and the JRE begins. I would consider memory management and code execution as 'the VM', everything more specific part of the JRE.
Thats means every binding to the operating system, be it I/O, Graphics etc. is part of the JRE. Thus the JRE has many platform dependent parts; you usually just don't notice them because your code uses their abstractions (e.g. File, Socket, Window).
So when you say "a port to MIPS" it doesn't mean anything without specifying an OS (ok, your link says Linux); a VM ported to a processor architecture by itself does not make a working java environment. It also requires a port of the native parts of the JRE that allow the java program to actually communicate with things outside the VM; thats where the OS platform comes in.
Since Linux is already supported for x64, the MIPS port should be able to reuse most of the JRE to platform bindings from that.
Related
Is there a boot loader written for booting Java virtual machine without an operating system? As far as I know Java virtual machine can run on a machine by itself, without help of an operating system.
Java defines the guest language, not the host / JVM.
You'd need a JVM written to run on bare-metal of whatever machine you want to run it on. (i.e. to be an OS kernel as well as a JVM, handling interrupts and so on). So there isn't something generic called "Java" that a bootloader could load.
The mainstream JVMs like OpenJDK / HotSpot are not written to work as kernels, only to run under some existing mainstream OSes. But as you found, there are some: Can you run JVM on a computer with no operating system?
Even for a specific platform, the things a kernel needs a bootloader to do may depend on the kernel. There are a few standards, like multiboot for x86, that define a kernel file format that bootloaders like GRUB know how to recognize and load, but otherwise you'd probably expect a bare-metal JVM to come with its own custom bootloader, especially if it's for a platform other than an x86 PC. Or perhaps be bootable as an "EFI application".
I am working on the development of a Java application that loads native library files to perform some calculations. The application uses JNI to load the libraries. This application should work on Windows and Linux environments (on both 32-bit and 64-bit).
During the compilation process, we compile C code to library files (32-bit and 64-bit dlls for Windows, and 32-bit and 64-bit .so files for Linux environments). These .dlls and .so files are included in the distribution file, and are referenced when Java is called by using the -Djava.library.path parameter.
I am now testing the application on a few different machines. I am initially focused on 64-bit Windows environments. The strange thing that I have encountered is that on some 64-bit machines the application loads the correct .dll files successfully, but on some other machines it does not load the .dlls.
I thought that the problem might because of a difference in the processor type between the machines (ie. that the dlls were compiled for one processor type and other processors types cannot use them).
However, it works on one machine, and does not work on another machine that has the SAME processor:
It works on a HP laptop running Windows 7 64-bit, with this processor:
PROCESSOR_ARCHITECTURE=AMD64
PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 37 Stepping 5, GenuineIntel
It does not work on a Lenovo laptop running Window 7 64-bit, with this processor:
PROCESSOR_ARCHITECTURE=AMD64
PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 58 Stepping 9, GenuineIntel
My question is: apart from the bitness are .dlls machine/processor type specific in some other way? (I know that the .dll files have to match the bitness of the machine, and that the JVM must also match the bitness of the .dll files)
Or in theory, if a .dll is 64-bit should it run on EVERY 64-bit machine that is using a 64-bit JVM?
apart from the bitness are .dlls machine/processor type specific in some other way?
Very much so. Any compiled binary meant to run under an operating system is both processor and operating system specific, sometimes even down to specific versions of each.
Different processors - even in the same family, such as "x86" - can offer different instruction sets and capabilities. See https://en.wikipedia.org/wiki/X86_instruction_listings for the listing of different variations of just x86 instruction sets and capabilities. If a compiled binary uses a specific instruction, it won't run on a processor that doesn't implement that instruction. For example, if a binary is compiled to use SSE3 instructions, it won't run on processors that don't implement SSE3.
And it's not just limited to hardware, either. Operating system specifics matter, too, literally for starters because the operating system is what starts the running process. So the binary needs to work under the conditions and in the environment of the operating system that started it. A binary designed to work under an operating system will also need to make calls to that operating system to interact with data, devices, or other processes. Different operating systems provide these capabilities in vastly different ways, even to the point of different versions of the same basic operating system doing so in incompatible ways.
And binaries that aren't designed to run under an operating system have to provide very hardware-specific capabilities - ever notice how many device drivers any operating system has? And this excludes any shared object or DLL because by definition they are already designed to run under an operating system.
Or in theory, if a .dll is 64-bit should it run on EVERY 64-bit
machine that is using a 64-bit JVM?
It should be clear by now that the answer is "Not even close".
I am getting following error while running /tmp/jprofiler8/bin/jpenable
No suitable Java Virtual Machine could be found on your system.
The version of the JVM must be at least 1.6 and at most 1.7.
Please define INSTALL4J_JAVA_HOME to point to a suitable JVM.
You can also try to delete the JVM cache file
I have also set INSTALL4J_JAVA_HOME to point to suitable JVM.
Java version on my machine is 1.4.2.
Can anyone please suggest what might be wrong or missing?
Unfortunately you did not mention details about your environment, so I don't know which Linux distribution you use.
There are some options though:
install a current JRE alongside the installer for JProfiler
As you can't install or update Java, you could provide a JRE in a kind of "portable application" setup. Simply unzip the server jre Oracle provides or (if you are not on an x64 architecture) unzip the jdk you also can download from Oracle.
But if the code you want to profile is limited to your pre-installed Java 1.4 you will run into another problem, because as far as I know Java 1.5 is the minimum JProfiler expects
use a different machine for profiling
Unless your code depends heavily on the environment you run it in you can even take a Windows 8.1 machine and profile the code there. Code that is slow is slow on any operating system. Or make use of a different Linux computer.
Is it possible to run an application on a 64 bit Weblogic 10.3.2 Server instance with a 32 bit JDK?
The reason for me to doing this is getting an exceptions while running my program using 64 bit JDK.
UCFWin32JNI.dll: Can't load IA 32-bit .dll on a AMD 64-bit platform
The error is gone when using 32 bit JDK.
If it is possible, then how?
Thanks!
A 32-bit version of a library cannot be loaded and used by a 64-bit JVM, and vice versa.
Moreover, UCFWin32JNI.dll does not appear to be a WebLogic library at all. In fact, it appears to be a library from Documentum. You ought to be looking for a 64-bit version of that library (if it is available) as it appears to be a 32-bit version going by the name and the error message produced. Finally, you'll need to place the 64-bit version in one of the directories constituting java.library.path.
No problems at all running a 32bit JVM on a 64bit platform. In fact, for some applications it can actually be more efficient, due to the fact that certain data types are innately larger on a 64bit JVM (ints I think are an example of this from memory)
A 64bit JVM provides all sorts of advantages for an application requiring access to a larger heap, but there's no harm at all in running a 32bit JVM.
As i know java programs are able to run on any Operating System.
and there are JVM's for any kind of machines.
I need a JVM that runs on my PC stand alone, and not on my OS (windows or any thing else).
I mean a JVM that acts like a boot, instead of the OS boot
i searched for all versions of JVM on "www.java.com/en/download/manual.jsp", but i did not get the suitable JVM.
the following link helped me a little but that was not enough
http://java-virtual-machine.net/other.html#jvm
my PC CPU is AMD Athlon(tm) 64X2 Dual Core Processor 5200 + 2.69 GHz
any body can help me to find the suitable jvm version ?!
Sure, have a look at JRockit Virtual Edition. As I understand it it's basically a micro kernel especially tailored for the JRockit VM.
From this page:
Java without the OS: JRockit Virtual Edition (VE)
Am I the only one that's never heard of this before? The Oracle JRockit team is looking at eliminating the OS from the stack required to run Java. This product will be called JRockit VE (not out yet)
JavaOS
Good lucking getting hold of it, though, it's nothing more than a historical curiosity.
There are two JVMs that I am aware of, which have this property:
The Fiji WM: http://www.fiji-systems.com/index.html
According to http://rtjava.blogspot.com/2009/11/new-real-time-vm-was-born-fiji-vm.html it also runs on bare metal.
The next possibility is JNode: an open source operating system where most parts are written in Java (the rest in assembly): http://www.jnode.org/
JNode is still beta, though.
No.
There was an idea of making a machine that could run a JVM as an actual machine (non virtualized), similiar to LISP machines, but that idea never took off...
You need a host OS to run a JVM.
Googling "java real machine" might give you some interesting articles.
I've found two: one from 2004, talking about how such a machine could be built and another one, talking about how JVM runs as a real machine on hardware such as mobile devices.
Still, no dice with a plain PC.